User tests: Successful: Unsuccessful:
This loop is for displaying articles in a category -- for a category blog page, for instance. If the context for the contentPrepare callback isn't set to com_content.article, there is no way for the contentPrepare() plugin callback to distinguish the category description from the articles below it. This fix is necessary to allow extension code to handle contentPrepare() callbacks correctly for category blog pages.
Bug:http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=29534
I haven't fully tested it and I think that there might be side effects in the existing plug-ins because of the change (both good and bad).
But I do agree that when the content comes from the article, also the context should be set to article to be able to pick up the right filters.
That said: what if you need to know that the content is an article introtext inside the category view (vs full article or category description)?
Although it may be remotely possible that other plugins might be affected, I think it is unlikely for the following reasons:
This fix only affects category displays. Standard frontpage, featured, article views, etc, will not be affected.
Since there is currently no way to distinguish between the callbacks for category description and for the articles in the category, the best that current plugins can do is to treat them all the same. So they must actually be ignoring the $context anyway. So I think the proposed fix will not affect any current plugins out there. By the way, the only logical way this can be done currently is to count the callbacks (first is the category description, the rest are articles --- but is probably not robust anyway because the admin may chose to not display the category description...
Regarding: "That said: what if you need to know that the content is an article introtext inside the category view (vs full article or category description)?" This fix only applies to category views. The way things currently are, the plugin cannot distinguish the two and is forced to actually check for the presence of the 'text' vs 'introtext' fields anyway. My plugins routinely do this because they have no choice!
I will withdraw this pull request and work with Peter van Westen to get something fix into the fix that he is working on in http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=27699 and #589
-Jonathan
Looks good to me.