As is, this shouldn't be accepted. At a minimum, it lacks context detection, so any plugins subscribed to it wouldn't know the difference between a com_content or com_banners list.

We have a lot of pull requests adding random event triggers to random places for query manipulation. Truthfully, I'm still not sold on what folks are trying to accomplish with it. Nor am I convinced that adding these random triggers in different places for the sake of adding triggers is the way to do it if we are going to start adding events to manipulate query objects.

Is it needed? Perhaps. Not in the way it's triggered though. The way you are proposing to trigger this event does nothing to improve developer experience; you are triggering an event with only a JDatabaseQuery object as a parameter. Event listeners could not account for the model state (as an example) when deciding to manipulate the object, something that is built in part based on the request. Likewise, without a context (like what is used in onContentPrepare), we have no distinction of what extension and list view is building this query. If my plugin is only manipulating something for com_content or my own extension, I basically have to rip apart the JDatabaseQuery object just to figure out if the event was triggered in those cases. Lastly, this trigger only affects queries built by models using JModelList, so this trigger for query manipulation adds a major inconsistency to our API.

IF we are going to add event triggers for query manipulation, it needs a lot more thought than what any of the pull requests have proposed thus far. We should not be building a system where only one or two queries can be manipulated by plugin events.

I agree with @mbabker this is far from a state I would press the merge button

ok, but you will agree that such an event would not hurt, you can add it to the other models, to override the db query, which can be used in the system plugins

could on my part that I did incorrectly pull request, but I just wanted to draw attention to the need for this event

@saharin88 I am sorry but I disagree, just because you can doesn't mean you should. I still don't see a good reason for adding this.

you do not see, but I see, I develop extensions, and often necessary as the impact on request (most sample data), that will not work without the customization of expansion

Now, even banal task - alphabet filter for material, tell me how to implement it?

I'm not saying that it should be added in such a way as it is now, but I think this similar event need

If you're developing your own extensions you would add these filters into your extension's configuration and use it (see some of the filtering options for com_content and the modules that read data from it as an example).

This type of event trigger implies you are trying to manipulate the queries for other extensions or you are developing extensions in which you provide an API for third parties to manipulate the queries your extensions build.

I am also not fun of such changes,
such changes open the door for more dirty hack by plugins, that could lead to unexpected behaviour when a couple plugins tries to modify the same $query

@saharin88 if you want to make the filter by alphabet or any other, more safe will be add one more view to com_content and the model that extend the articles model, where you can safely modify the query (as example, take a look on the featured model) ... if I right remember, Joomla do not destroy it while upgrade process

Федя, да я согласен что это откроет больше возможностей для людей со злыми намерениями. Но владелец сайта сам несет ответственность за те расширения которые он ставит себе, можно и без этого события написать что угодно...

По второй части вашего комментария: добавлять модель и вьювер это уже кастомизация, а с этим событием я могу просто из плагина откорректировать запрос.

@saharin88 please keep the discussion on English.
Not all site owners is developers, and not all know how the thing work ...
When people want some feature => they search some extension and install it (hundreds different plugins and other extensions) .. they do not care how thing works, but for them it should work ... and if it do not work, first who will be blamed it is Joomla.

Setting to needs review so a maintainer can make a decision on this

I actually quite like query triggers after playing with them in FOF. But they have to be done the right way and done consistently across all components. This approach is neither of those things.

I also ref: to a google discussion a long while back https://groups.google.com/forum/#!msg/joomla-dev-cms/KkGuhBYvoyo/_Az2f4ozgLwJ where having plugin events across all database queries was also discussed. I'm going to close this for now for this specific PR - but I'm personally interested in maybe reviving this when we get the performance improvements in the frameworks event system and we do this consistently across all components.