Please provide instructions how this can be tested. Perhaps provide a
sample plugin to help testing.

Allowing deep integration of third-party extensions into the internal structure of a core component is, in my opinion, the wrong way to go. It might fix your immediate problem, but it does so at the expense of creating tight coupling between components through the database. This would be bad for future development.

The better path to follow is to define a component-level API that allows extensions to extend functionality without exposing details of the component's internal operation. To take an extreme example, it shouldn't make any difference to your extension if we one day refactor com_content to not use a database at all!

There are already a lot of extensions that are using articles for different purposes and in different ways.
The only thing missing is integrating a more complex search that would just filter the items presented in the current com_content layout.
A requirement to develop another component just for a search seem to be a big waste of time to me.
The current com_search and com_filter are helping, but require a lot of work on the layout.

I've added instructions on testing the code and a small demo plugin in the first message of the PR.

I'm just going to leave this here... #10668 (comment)

The context should be different if the plugin is triggered from the model of another component.
The developer of the plugins should control if the query is changed or not.

Regarding this:

It's been brought up before and usually shot down adding plugin events which allow query manipulation.

I don't understand why. Why force the development of another component instead of completing com_content?

The context should be different if the plugin is triggered from the model of another component.

You don't have a way of setting the context and frankly if there were it would break a lot more stuff (JModelList has a context property already). The context you have coded in is the context of the model that is being executed. It doesn't have any other context about the caller or the model state which DOES affect whether the plugin should or should not alter the query.

Why force the development of another component instead of completing com_content?

Improve the model by improving the model state, utilizing other types of plugin events, or adding parameters to define things. But in general opening the API for query manipulation is a really bad idea as it can and will result in unwanted changes, especially as you've implemented this. Using your example plugin, this query will ALWAYS be manipulated to only return article IDs 4 and 5; regardless of whether I am using the model to load all articles, load articles in a given category, matching a specific tag, author, etc. There is not enough information passed forward to make the plugin truly useful. THAT is part of the reason why any plugin event suggesting query manipulation is bad in general; anything manipulating a query is going to assume an intent and break use cases that do not follow that intent.

If the model has a context it can be implemented in the call to the plugins (I will investigate and modify the suggested code).

Regarding the plugin that was JUST an example, as I mentioned. Different situations will require different modifications of the query, sometimes even no modification will be the result.

If the query can't be changed no search can be properly implemented and another component will have to be used.
I think this is the reason so many CCK extensions were developed, even though there are good ways of adding custom fields to com_content.
More then that, writing a plugin for com_search or com_finder would require more of less query manipulation. Why is that good for those components but not for com_content?

What are you trying to do that would require query manipulation in com_finder?

What are you trying to do that would require query manipulation in com_finder?

Write the code that would retrieve records of another component or modify the ones for com_content.

btw, previous discussion #8031 about same topic
and in Google Group https://groups.google.com/forum/#!msg/joomla-dev-cms/KkGuhBYvoyo/_Az2f4ozgLwJ

More then that, writing a plugin for com_search or com_finder would require more of less query manipulation. Why is that good for those components but not for com_content?

The search components aren't using the component models or manipulating queries. They're writing their own queries via data acquired from their own plugin groups based on their own use cases (com_search basically doing SELECT queries with more generalized LIKE statements and com_finder using its own database structure).

Different situations will require different modifications of the query, sometimes even no modification will be the result.

And a two argument event with a model context and a query doesn't give enough data to anyone to decide whether they should or should not touch it. It basically requires someone to get into debug_backtrace() and find the call stack to determine if the event was actually triggered in a context they should manipulate (why should a plugin always manipulate every query that comes out of a model when said manipulation can break one of the article modules as an example?).

They're writing their own queries via data acquired from their own plugin groups based on their own use cases

So only queries from the native code are off limits? Why?

And a two argument event with a model context and a query doesn't give enough data to anyone to decide whether they should or should not touch it.

In the plugin you have access to the full joomla's parameters and environment, not just the two sent directly to the event.

So only queries from the native code are off limits? Why?

The search components are NOT doing any form of query manipulation. They aren't even using the core models. Comparing how the search components behave in this context isn't applicable by any measure.

In the plugin you have access to the full joomla's parameters and environment, not just the two sent directly to the event.

Again, not enough. If I have to rely on debug_backtrace() to determine that my plugin should actually manipulate a query, then the API implementation has failed massively. If I only want to manipulate the queries specifically when a com_content view is rendered, how do I differentiate that query from a query created by an article module being loaded, potentially on the same page? Your implementation has created an all or nothing effect unless I dig into PHP internals to make my decisions.

Moreover, why do I need to manipulate the query to achieve my desired result when there are already a bajillion and seven options that can be set to alter how the data is pulled either at the user interface level or through setting the model state before calling the getItems() method? If you start applying additional WHERE clauses to the query, you're adding additional filters that the user may not be aware are active to the result set. If you try to "optimize" the SELECT clause to only return partial data, anything relying on the full data object breaks or has to do a separate query to load the now missing data. If you rewrite the query completely, then honestly why on earth are you using the model to begin with?

So you are saying that the context is exactly the same for reading the articles from the component com_content as it is for reading the articles for any of the modules related to the articles?

The way you have it structured right now, the plugin listener would only receive two arguments: a model context, and the query you want to manipulate. The plugin does not receive any additional context information (who initiated the call to the model, the model state which specifies different filtering and ordering conditions, etc.). Without any additional information, the plugin cannot adequately decide whether it should do anything and will blindly apply whatever manipulation it decides to EVERY query going through that model. Using your plugin as an example, if I have it enabled, then EVERYWHERE using that com_content model on the frontend will ONLY ever display article IDs 4 and 5 if they match the rest of the criteria that's already been established through the built query and the injected model state. This might be acceptable on some com_content view for you, but if you're showing the latest articles or popular articles modules, this will cause them to incorrectly display data.

I've added the application scope and the model state into the parameters.
I've also modified the example plugin to use the scope to generate the modification of the query only for the component.
Thank you for your suggestions.

Setting to Needs Review so that the CMS maintainers can make a decision on this PR

I am closing this, it is the wrong place for manipulation. Thanks for the discussion and thanks @algisinfo for working on this.