User tests: Successful: Unsuccessful:
-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.
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;
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 .
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.
https://docs.joomla.org/Plugin/Events/Content
https://docs.joomla.org/J3.x:Creating_a_content_plugin
Status | New | ⇒ | Pending |
Category | ⇒ | Front End com_content |
Labels |
Added:
?
|
Title |
|
- 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?
@HLeithner Hello, in this PR I fixed the CMS Joomla errors that you told me about. please transfer this PR to J5.
@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.
This pull request has been automatically rebased to 4.3-dev.
@HLeithner Is it possible to transfer this PR to Joomla 5 ?
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?
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.
This pull request has been automatically rebased to 5.2-dev.
Title |
|
This pull request has been automatically rebased to 5.3-dev.
Title |
|
Labels |
Added:
Feature
RMDQ
PR-5.0-dev
b/c break
PR-5.3-dev
Removed: ? |
This pull request has been automatically rebased to 6.0-dev.
Title |
|
Labels |
Added:
PR-6.0-dev
Removed: PR-5.0-dev |
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?
Now that maintainers have a reply can you please make a decision. There is no point in leaving it open forever and continually rebasing the branch.
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?
Now that maintainers have a reply can you please make a decision. There is no point in leaving it open forever and continually rebasing the branch.
Well, first of all, I cleaned up the code and moved the plugin call from the template to the view. This is a big part of the fix. By adding a generic plugin method call. I could use a module.
But I was writing a plugin that does not solve the problem of one customer, I was writing a plugin for sale in general for a large number of customers. Customers should have no problems when they install the plugin themselves. That is, I made a plugin that performs the function of a store, i.e. the entire store in one plugin. Of course, this is my personal problem.
BUT! BUT! BUT!. This allowed me to understand that the site materials can be used as a product, without components, without copying data, without converting data. publications that are already on the site become an order item. With the sales components, you need to synchronize the product description with the article description. In the case when articles are like a product: you can use modules: popular, recent, sliders. There is no need to look for something special when existing modules work with articles. And you don't need to redo the site at all. You don't need to customize new components to fit the site's style. Everything has already been checked, we need the order form or the shopping cart form to be displayed at the bottom of the page. BUT if you use articles only as articles, then of course my idea is too intrusive. And of course, my request is easier to solve on the module. If I were doing this for only one client, I would solve the problem only using the module. Using the module, everyone does this, they insert entire components into the module, the module of which is inserted into the middle of the article. Frequent occurrence. But I was making a free plugin for everyone.
allowing people not to worry about the site in principle. By installing the plugin,
PlugInPlay, In the case of a new store component, this will not work.
Thank you for your PR.
There are some challenges with the code: