[5.3] Call events move to View and add one position for category

[korenevskiy]

Summary of Changes

-Moved the Event call for the Category Blog from the TMPL to the VIEW. The call has been moved to where it should be initially.
-Added position in the lists of articles of categories, archives selected. This position is displayed after this list of articles.

This additional event call is necessary for the subsequent withdrawal of information about this list of articles.
It will be convenient to use the list of category articles to create a form of ordering goods. Each material may have a selection field. And at the very end you can place an order form with delivery fields and contact details. And all this will be able to perform one field.

This PR is based on 37789 but additionally corrects the placement of event calls in the Categories Blog.

Testing Instructions

You need to create the onContentAfterItems($context, $item, $params) method in any content plugin
Then in this method return additional text.
This text will be inserted into the list of articles of the Blog or other list of articles .

public function onContentAfterItems($context, $item, $params) : string{
	return "<h3>This insert text in list articles</h3>";
}

The event of a trigger is caused by this code inserted at the end of the category blog.

$results = $app->triggerEvent('onContentAfterItems', array($this->category->extension . '.categories', &$this, &$this->params));
$afterDisplayItems = trim(implode("\n", $results));
echo $afterDisplayItems;

Actual result BEFORE applying this Pull Request

Before all positions allowed to add and process text before to location position the list of articles.
This approach is convenient for the output of ordinary material, but not for categories and lists of articles .

Expected result AFTER applying this Pull Request

But when displaying a list of articles, the list itself is important, so you need to display data before the list and after the list of articles.

Documentation Changes Required

https://docs.joomla.org/Plugin/Events/Content
https://docs.joomla.org/J3.x:Creating_a_content_plugin

[bembelimen]

Thank you for your PR.

There are some challenges with the code:

• Having an old override in place will trigger the events twice, so we can most likely earliest go with Joomla 5 with this
• New events should follow the new event format

[korenevskiy]

• New events should follow the new event format

If I redo it to a new format, My PR in J5 will be accepted?
What I need to do to make changes?

[korenevskiy]

@HLeithner Hello, in this PR I fixed the CMS Joomla errors that you told me about. please transfer this PR to J5.

[HLeithner]

@korenevskiy as I already said somewhere I'm not convinced to add events for this kind of template manipulation.
I would like to have something more generic but didn't thought about it yet, I will try to get some people together and see if something more sustainable can be created.

[korenevskiy]

as I already said somewhere

You said it here 37789 .
But, I corrected your wishes.
Before, the call was in the template. I corrected, and now the challenge is in the View.

[HLeithner]

This pull request has been automatically rebased to 4.3-dev.

[Hackwar]

Hello @korenevskiy, we discussed this PR in the maintainer meeting today and we don't see the usecase for this. It sounds like a VERY specific circumstance for you. Could you explain why this should be part of Joomla? Why do you need an additional event like this and can't just use a module placed below the content?

[korenevskiy]

Hello @korenevskiy, we discussed this PR in the maintainer meeting today and we don't see the usecase for this. It sounds like a VERY specific circumstance for you. Could you explain why this should be part of Joomla? Why do you need an additional event like this and can't just use a module placed below the content?

I've seen a lot of potential in custom fields for articles before. I don't think of creating a single website for a client in space, but I think of creating a plugin for users with a target audience in space.
The plugin must take into account the data fields of each blog article, and then show the final result. For example, blog categories are goods in stock displayed as a list with pictures, then you need to display the total amount and the total number of goods under the list. I also had the idea to create a custom field plugin that would contain a module. It would be very convenient to attach a picture or a table with data to the articles. And then, in the lower position of the category, display a carousel or a basket of goods, data from articles.
But I'm already disappointed to do it. Since this PR and other prs that have a one-line change make great opportunities for developers canceled.

Because I consider Joomla Not as a website builder, but as a framework for creating complex applications. I wanted to avoid having to rewrite the component if desired, as if you were reinventing the wheel and the bicycle. And it was possible to add your controller to the articles component, which will automatically start working as in J3, now there is no such possibility. I'm thinking more and more about using a CMS on Laravel or another option, so that there are more features in the framework, so that you can create a plugin or module to get new features in a bare CMS. The custom field is intended only to display another text field in articles, And something dynamic in custom fields will not work, or with great difficulty, that it is better not to do this.
The future trend that is happening in modules scares me very much. Providers and dispatchers in modules are a bad tone for CMS. Not because it's bad to use, but because the implementation method is not much worse. Dispatchers and providers should be outside the module and not inside. That is, the creator of the site should not think about dispatchers and providers when creating the module.

[HLeithner]

This pull request has been automatically rebased to 5.2-dev.

[HLeithner]

This pull request has been automatically rebased to 5.3-dev.