if you do a template override and you remove the introtext from articles in the Category View, this should stop the plugin from getting the data even when you set Article Display options to a certain number (not 0), because the Introtext is not actually loaded, so how can a plugin get to the text of the article and load whatever it is that it loads?

That's not exactly how things work. The data gets loaded first by the view class, then the resulting dataset is processed through the plugin events, then the view renders that data object. So just because something is not displayed in the view does not mean that it is inherently removed from the query's field list or available fields in plugins.

@mbabker Oh I understand. Although, did it work like that in older Joomlas too? I'm pretty sure for example in Joomla 1.5, if I were to remove the introtext from the Blog View this problem wasn't happening and plugins couldn't get to it. I think this would be a behavior that would make sense. Also I'm wondering, does this impact performance? Why load and require data that it's not going to be displayed or needed? I assume the plugin has to go through the text of all the articles displayed on that page despite the text not being shown. Would this render the fact that I'm not showing the text "useless" performance-wise?

Also I tried something else, I tried to completely erase the content of the "blog.php" page just to see what would happen, and despite that, the plugin STILL can get to the data. How?

Anyways, apart from that, the issue when 0 articles are set is still valid.
Because when the number of articles is specified, it only loads data from the number of articles specified (say, if you set 6 articles per page, it loads data from 6 articles per page).
But when all articles option are set to 0, it loads data from ALL articles in that category. This can't be the expected behavior, it should surely NOT load data in this scenario, right?

Thanks for the support.

old trick set it to -1 ?

@Fedik Well, assuming that works, I don't think I should be having to do that... 0 means 0.
It shows 0 articles, but it loads the data from All of them? That's not consistent.

The models that query the information aren't aware of what data is or is not displayed in your layout. Remember the models are supposed to be reusable so locking them to a layout's fields wouldn't be a good behavior. Likewise, to render a view it would mean we'd have to parse the layout files, figure out what variable represents the data object the model is supposed to use, extract all the field names from that, and build the appropriate SELECT clause for the query (with no information on relations or field aliases); not efficient by any means.

The order is data is queried, plugins are triggered, THEN the layout is assembled. Nothing before the layout step is aware of what's in the layout, so the plugins run solely based on the data object returned by the query and a given context. If the logic were something like layout built then plugins run what you're saying would make sense but at that point the plugins would be manipulating your assembled HTML versus a raw object with the data readily available.

As for the 0 thing, honestly my suggestion is there is something in the model to disallow a 0 query and it converts it to a query with no limit. I'd also suggest allowing a 0 limit might break stuff so I don't know if I'd make a change for that use case.

@mbabker Thanks for the thorough explanation. Everything is clear now.
However, I do believe the occurrence where 0 articles are set to be displayed should be addressed, isn't it weird that the query does allow to display 0 articles if you set that, but not to load 0 data in that scenario?
I don't envision how it could break stuff as it would apply only to this specific scenario.

Btw, I tried the -1 trick suggested above by @Fedik and it worked.

.. there is something in the model to disallow a 0 query and it converts it to a query with no limit..

I think 0 made for allow to reset the pagination limit, to allow to display "All" (unlimited)

After further testing, this should really be addressed. Even when no plugin needs to load anything, it's clear that Joomla still loads ALL the articles data when the option is set to 0, because if we're talking about a category which contains hundreds of articles, the loading of the category blog page (with 0 articles set to display) is VERY SLOW. It takes dozens of seconds. This literally makes no sense.
How can the loading of a category blog page be slower when you display ZERO articles (because it loads data for all of them, even hundreds, or thousands, all of them in the background, but you're displaying zero) then when you're displaying 20 articles (because it correctly loads just those 20).
This can't be intended behavior.
I understand the "-1" solution and I guess I will adopt that, but it sounds/looks like a workaround and I don't think you should be having to work around such an issue... Actually it's pretty strange that nobody noticed it before. I guess it might be because not many people display 0 articles (I do it because sometimes I load articles by other means (plugin/modules) by loading them in the category description), but I don't think that means it shouldn't be supported correctly. I'm 100% sure this wasn't an issue in Joomla 1.5.

set Status on "Needs Review" in Issue Tracker.

After further testing, this should really be addressed. Even when no plugin needs to load anything, it's clear that Joomla still loads ALL the articles data when the option is set to 0, because if we're talking about a category which contains hundreds of articles, the loading of the category blog page (with 0 articles set to display) is VERY SLOW. It takes dozens of seconds. This literally makes no sense.
How can the loading of a category blog page be slower when you display ZERO articles (because it loads data for all of them, even hundreds, or thousands, all of them in the background, but you're displaying zero) then when you're displaying 20 articles (because it correctly loads just those 20).
This can't be intended behavior.
I understand the "-1" solution and I guess I will adopt that, but it sounds/looks like a workaround and I don't think you should be having to work around such an issue... Actually it's pretty strange that nobody noticed it before. I guess it might be because not many people display 0 articles (I do it because sometimes I load articles by other means (plugin/modules) by loading them in the category description), but I don't think that means it shouldn't be supported correctly. I'm 100% sure this wasn't an issue in Joomla 1.5.

Hello, has this issue been considered?