FUNCTIONS

1. If 2 articles are marked with the same tag, but are in different categories. Then one tag will be shown in the display 2 times. Since both are the same, but differ by reference to different categories. Which is quite logical to show 2 times.
2. If tags are displayed in tree mode and display category names , then category names will be displayed only for parent tags. This will allow you to show groups of tags by different group categories, since in any case there will be tags of only one category in one branch.
3. If you want the tags to be displayed without grouping by category, then you should not specify more than one category in the settings, which is also quite logical.
4. List mode, nothing special. Everything is intuitive, works like a list.

Accordingly, it is necessary to test 1-3 items.

I really appreciate your efforts, but this module would be a perfect fit for the extension directory.

I really appreciate your efforts, but this module would be a perfect fit for the extension directory.

99% of developers need the functions of this module. But as in any other module, all the functions of each module are used by 20%. We can make the default values simple, disable the tree mode by default. Would you personally use such a module?

In any case, opening tags in the form of a blog is a very useful feature. Otherwise, working with tags is not convenient in principle.

Even in the blog category component there is a tag selection setting. Thus, the module works similarly to the function of the Blog Category component.

We can simplify the selection of a category to the selection of a single category. In this case, there will be no more duplicate identical tags.

I fixed the module. Now you can select only one category in the settings.

There will be no duplicate tags now. So everything will be unambiguous for tags output.

@laoneo

i'm with @laoneo here, this is a good fit for an extension, not sure for core, but not my call, only my personal opinion

@korenevskiy As I said, this should be published in the Joomla extension directory (JED) and not be added to the core.

@laoneo
I understand that you are expressing the opinion of several leaders. But I will try to describe a few usage scenarios. After that, you will remember for yourself your last 3 projects on Joomla and if this module would be useful for 2 projects out of 3, then this module is good for the core. Think about it, it would be better to group you in your article projects not by categories, but by tags?.
I think it is convenient to group by categories only when it is necessary to separate information from publications. Suppose a category module is displayed on the site. Do you personally think it would be better for you to place a module with a list of tags working as categories instead of this module?

I recall the evolution of the development of mail programs. 1. In the beginning, there were Inbox, Outgoing, Spam, Trash folders in the mail. 2. Next, a category tree appeared for the placement of folders. 3. Tags appeared so that emails could correspond to several groupings at the same time.

Working with tags is a continuation of the idea of categories. It is normal.

I propose a scenario.
You are mistaken if you think that this module is an extended version of the tag cloud/list. You misunderstood. I suggest using tags as a more perfect form of categories. Imagine that you get on a website to be able to use categories for an article in the plural. You can choose several categories for each article at the same time. But at the same time, this possibility does not create confusion of links. Do you think this is a useful feature for modern websites?
I remember a few blogs, forums that came to mind, and I understand that this function is in all the sites.

I write about my projects. Scenarios: 1.A product store, an article on the site is a product. Goods are located simultaneously in several categories at once, - Bonuses, promotions or just a product, -Type (type) of goods, - for children, for adults, for pensioners. 2. News blog for the museum, with the publication of exhibitions. There are exhibitions, future, past, present, As well as exhibitions for different age groups.

As you can see, using multiple categories for articles is very useful for 99% of sites. It is for these purposes that tags are intended. I suggest you consider tags not just as a signature under articles. And do not think that this module is just an extended module for working with signatures to articles. I suggest using tags as a more perfect form of categories. Working with tags to our fact is already implemented in the kernel. But the core lacks a module to have tags as an improved option instead of categories.

I wrote this long text, I'm sorry. But I think there are developers who don't understand the value of tags. They think that tags are the same as tags on YouTube for videos. And they don't understand that tags are a continuation of the idea of categories. Natural evolution.

Any other module in the kernel that works with tags is more useless, since the existing modules have only one narrow scenario. This module that I propose has very extensive application scenarios.

If you agree with this text, then put a smiley face here (We will count.).

All leaders should read this.

If after that, you say that it's not for the core, then I won't argue.

Could you please illustrate the uses of this module with screenshots.

Could you please illustrate the uses of this module with screenshots.

@brianteeman
Yes, Of course, Easy. There are a lot of such modules.
https://gesor.ru/products?filter_tag%5B0%5D=#new#

The same thing but in the form of cards

Mobile version:

Sorry - you misunderstood me

Please show screenshots of how this module is displayed (not a customised version)

Trying to understand its use case and if it would not perhaps be better as a menu item type and not a module

@brianteeman

Is that what you meant?

This seems to me to be a perfectly sensible addition to the core. Tags is intended as a means of managing content in multiple categories and this module appears to be the direct equivalent to the existing core module for categories.

(I have not had time to test it but at least I now understand its purpose)

I made various comments about the code style of the xml in the previous pull request - not typing them again but they still need to be corrected.

I made various comments about the code style of the xml in the previous pull request - not typing them again but they still need to be corrected.

I thought I fixed everything. You could we poke my nose again. It seems to me that I might have misunderstood something.

@brianteeman
I have a few questions. For example, a question. In the category selection module (first setting) do multiple or single? Who will help you decide how best?

I made various comments about the code style of the xml in the previous pull request - not typing them again but they still need to be corrected.

I thought I fixed everything. You could we poke my nose again. It seems to me that I might have misunderstood something.

ok I posted comments - but please use the comments as an example and check all the files for the same correction

@korenevskiy I don't know where you have your numbers from that 99% need this feature. I just made a big site with over hundreds of tags and they are not hierarchical. I would just go for the opposite and say that the times of hierarchy is over and we work more with unstructured data. Anyway, this is really about personal opinions and experiences, so both of us can't say who and where needs this. I see it more from the point that we don't need to bloat the core more and instead of pushing the Joomla extension directory. So this should go into the JED.

@laoneo Maybe you don't use it. But I see how on the sites:
https://www.php.net/manual/en/
https://extensions.joomla.org
As for example on the website https://extensions.joomla.org
The categories are grouped into groups.
Categories Slideshow,Galleries,Images,Rotators,Panorama,eCards, grouped into the group "Photos & Images"
And there are 20 such groups of categories.

We can make simple websites without grouping tags. But after a while, we will need to enter groups, Do you think we need to search for the module again and to make up the site again?
But that's not the only question here. The case concerns the components to which links are opened. In this module, tag links belong to the Content/Category/Blog component. If we have a blog section with materials having tags. Then this module will open the same blog component with filtered materials by tag. But at the same time it will be the same menu item, and it will be the same blog.

You make tags on the site. Don't you need to open them as a blog? If tags are an improved version of a category, then we can not limit ourselves to anything at any time. Today we have 20 items of goods, this is one level of tags, and after a while there will be 200 or 2000 of them, we will simply add 1-2 levels to the hierarchy of tags.

By opening any category on the site https://extensions.joomla.org We will see a list of applications in the form of a blog. Each product has a picture, description, name, tags, and so on. What's wrong is that the module that opens tags like a blog will be in the core.

Size folder module 21Kb

I definitely see this as a useful extension, but you can publish it in the extension directory and then can the users install it when they want. No need to bloat the core...

We've got to stop saying that for things that provide a missing feature, like this.

In a way it 's not even a new feature, but solving the "bug" of giving an example "output interface" to the core nested tags.
What is the point of nested tags? Why were they made?
Don't make anything fancy or really beautiful but just a bare minimum to expose the nested tags solving in a way the really old "multicategory" problem.
Do it as an extension? But the role of an extension shouldn 't be implementing core features output in the basic way but in a more beautiful or enhanced way.
It's basic for templates demos also. They usually have blog list, category blog, tag list, override and style. It would be awesome for them to have a standard joomla way to make the multicategory view with tags. They shouldn't rely on a 10 kb extension from a developer that may attend to it or not. You all know a very famous extension that many used in the past for its multicategory feature. And now some don't even upgrade their templates due to it. All from scratch.
I can see very strong opinion from one maintainer here but i believe it's something that other maintainers should check also.
(Sorry for my english i hope it will make sense)

i agree 100% @peteruoi

@peteruoi
I read it through a translator, I think I agree with you, . I will describe the tasks based on the problems you write about.

• This extension also requires a similar mode of the CONTENT component. I.e. we need to create it. By the way, the new mode is supposed to be inherited from Category-Blog. This requires that all links of materials have a single address, regardless of which of the tags is open.
• Do you also suggest we updating the already basic modules so that they support the tag tree?

They shouldn't rely on a 10 kb extension from a developer that may attend to it or not. You all know a very famous extension that many used in the past for its multicategory feature. And now some don't even upgrade their templates due to it. All from scratch.

Relying on an extension and then suffering because of it is a stupid idea. But this extension does not violate backward compatibility. Links are SEO and similar to the menu item, The blog template when opening tags is compatible with the Blog Category template. It's hard to imagine how this can be limited for a developer. But I completely agree that it is necessary that there be a component mode similar to the module.

Question to everyone.
So what to do?

• Are we going to develop the CATEGORY-TAGS component mode in the new PR or push it into this PR?
• Will we add the tree mode to other tag display modules in the same way in the new PR or within this PR?

I will tell you about the principle of the module. After click the link tag, open the blog. I will talk about what display settings this blog has.
The blog is displayed according to the settings of the component for displaying the blog.

1. We create a separate menu item CATEGORY BLOG.
2. We create the CATEGORY-TAGS module and select the previously created menu item in the settings.

After that, all links of articles will be equivalent to links to articles from the created menu item of the CATEGORY-BLOG component.
As well as the blog display settings will correspond to the settings of the selected component of the menu item.

All links module will be relevant and working, even after removing the module from the CMS altogether. Even if you delete the module files, the tag links from the module will be relevant.

If you copy the link from the module and forward it via WhatsApp. Then we will delete the module and its files. After that, our WhatsApp interlocutor will open the link, it will be working according to the tags.
We do not bind to the module in any way.

Hello @korenevskiy
If I understand correctly, this is interesting, because it gives the utility to the parent/child tags.
Could this be useful for synonym search as well?
It would allow to answer a query with any term of the parent tag? Currently I have to multiply the number of tags :-(

Could this be useful for synonym search as well?
It would allow to answer a query with any term of the parent tag? Currently I have to multiply the number of tags :-(

If an article has a tag assigned, what do you want to open the parent tag of the assigned article tag so that the article is also automatically displayed for the parent tag? I don't think that's possible. But having answered this question, I will also add that it does not depend on the module at all. I may have misunderstood your question. Also explain what a synonym means?

But in principle, if you modify the module. then it is probably possible by opening the parent tag to display articles of child tags. But it will be an unusual situation.
To implement this, when displaying the parent tag to for user in the link, it is necessary to register, separated by commas, all tags. It will be a long link. This alteration has not been planned yet. If you asked something else, then describe your question in more detail.

Could this be useful for synonym search as well?
It would allow to answer a query with any term of the parent tag? Currently I have to multiply the number of tags :-(

If an article has a tag assigned, what do you want to open the parent tag of the assigned article tag so that the article is also automatically displayed for the parent tag? I don't think that's possible. But having answered this question, I will also add that it does not depend on the module at all. I may have misunderstood your question. Also explain what a synonym means?

A synonym is a word, morpheme, or phrase that means exactly or nearly the same as another word, morpheme, or phrase in a given language. For example, in the English language, the words begin, start, commence, and initiate are all synonyms of one another: they are synonymous.
=> https://en.wikipedia.org/wiki/Synonym
First of all, thank you for taking the time to answer me.
Unfortunately, I think it's a different request that certainly required changes to the core joomla and I can not propose a solution.

First of all, thank you for taking the time to answer me.
Unfortunately, I think it's a different request that certainly required changes to the core joomla and I can not propose a solution.

What is synonym I know. I did not understand what it means in the context of tags. But now I understand.
I think this doesn't work at Joomla at all.
You probably add a lot of tags that are synonymous with each other to the article. That is how it can work at this time.maybe in 10 years it will appear. Joomla has a lot of other very important problems, and the backward compatibility and number of development participants shows what prospects will be in the coming years. While this is not possible.
I think it’s possible to implement with a plugin. Such a plugin will catch the events of the request, get the tag from there, personally search for synonyms for him and put synonyms back into the request. A comparison of synonyms should be stored in the plugin. The plugin can download these comparisons from INI .
But even if, you suppose you want to write such a plugin. He will not be accepted into the nucleus. Therefore, you can implement it and put it in JET .
I think creating such a plugin can take 4 hours. Try it out.

What is synonym I know. I did not understand what it means in the context of tags. But now I understand. I think this doesn't work at Joomla at all. You probably add a lot of tags that are synonymous with each other to the article. That is how it can work at this time.maybe in 10 years it will appear. Joomla has a lot of other very important problems, and the backward compatibility and number of development participants shows what prospects will be in the coming years. While this is not possible. I think it’s possible to implement with a plugin. Such a plugin will catch the events of the request, get the tag from there, personally search for synonyms for him and put synonyms back into the request. A comparison of synonyms should be stored in the plugin. The plugin can download these comparisons from INI . But even if, you suppose you want to write such a plugin. He will not be accepted into the nucleus. Therefore, you can implement it and put it in JET . I think creating such a plugin can take 4 hours. Try it out.

Thanks for this plugin idea.
I'm not a developer, but I'm writing it down to suggest it to a developer

Fixed the last possible SEO error. Previously, this module generated a block with links of materials for any menu item. Even when the menu item was not a blog. This could cause duplicate links. This is bad for SEO. But the new fix requires having a blog menu item, otherwise the module cannot be created, and now the blog materials will have links to the blog of the menu item. I.e., the links of the materials will fully correspond to the blog of the menu item.
The links are still backward compatible. And as before, if you delete the module, the links will be relevant. Since the module only extends the functionality of the Blog component.

In the main top description, I added a survey to the end. Please colleagues make a choice.

This looks like a very useful addition to the core.

This pull request has been automatically rebased to 5.0-dev. No new features will be merged into Joomla! 4.3 series. Joomla! 4.4 series is a bridge release to make migration from Joomla! 4 to 5 as smooth as possible.

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

And now with the advent of the new version, will this functionality be added?

I have tested this item ? unsuccessfully on f95b0da

After enabling this new module, the Front-End crashes and is displaying the rror message:
«call_user_func_array(): Argument #1 ($callback) must be a valid callback, class "Joomla\Module\CategoryTags\Site\Helper\CategoryTagsHelper" not found»

I have tested this item ? unsuccessfully on f95b0da

when I activate image tags I have this error. Other options works fine.

( ! ) Warning: Undefined property: stdClass::$image_intro in /var/www/clients/client2/web11/web/modules/mod_category_tags/tmpl/_items.php on line 43

I have tested this item ? unsuccessfully on f95b0daAfter enabling this new module, the Front-End crashes and is displaying the rror message: «call_user_func_array(): Argument #1 ($callback) must be a valid callback, class "Joomla\Module\CategoryTags\Site\Helper\CategoryTagsHelper" not found»
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/38752.

You can show a screenshot and the URL of the error page
we need to find out where the error is being caused
The full stack of errors. Please enable developer mode with all errors displayed.

@dorisdreher
I have fixed this file with the specified error. Please test it and give your expert opinion.

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

Hey @korenevskiy we had a long discussion in the maintainer team and would like to see something like your module in the core. But as we currently go the way "one module for all" could you do the same and integrate the mod_tags_popular and your model to a new one?

For consistency with other modules shouldnt this be called "Tags - Categories" and the files renamed accordingly to mod_tags_categories.

Also as these are new files then the copyright should be 2024 (now - sorry its taken so long that this needs to be changed)

As this is a new module then it needs to be added to the install sql and the update sql

It also needs to be added to the list of core modules here

oops cross posted with @bembelimen

I have tested this item ? unsuccessfully on f95b0da

Hello tested it but unsuccessfully. Tested in multilanguage environment FR/ENG.
Used Casiopeia, affected tag1, tag2, tag3 to 3 different articles, in different categories (Typography & Blog default Joomla categories after fresh install). When displaying my article n°1 with tag1 (category Typography), the side module does NOT display the others categories which have different articles with the same tag (tag1 in blog category for example).
Moreover the module is missing the language ENG file, I'm having all the texts in MOD_CATEGORY_TAGS_FIELD_DISPLAY_TREE_LABEL format. Not easy to understand different options.

Please provide a precise walkthrough to install and configure module for successful replication.
Best
Philippe

Hello tested it but unsuccessfully. Tested in multilanguage environment FR/ENG.
Used Casiopeia, affected tag1, tag2, tag3 to 3 different articles, in different categories (Typography & Blog default Joomla categories after fresh install). When displaying my article n°1 with tag1 (category Typography), the side module does NOT display the others categories which have different articles with the same tag (tag1 in blog category for example).
Moreover the module is missing the language ENG file, I'm having all the texts in MOD_CATEGORY_TAGS_FIELD_DISPLAY_TREE_LABEL format. Not easy to understand different options.

Please provide a precise walkthrough to install and configure module for successful replication.
Best
Philippe

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

Hello tested it but unsuccessfully. Tested in multilanguage environment FR/ENG. Used Casiopeia, affected tag1, tag2, tag3 to 3 different articles, in different categories (Typography & Blog default Joomla categories after fresh install). When displaying my article n°1 with tag1 (category Typography), the side module does NOT display the others categories which have different articles with the same tag (tag1 in blog category for example). Moreover the module is missing the language ENG file, I'm having all the texts in MOD_CATEGORY_TAGS_FIELD_DISPLAY_TREE_LABEL format. Not easy to understand different options.

Please provide a precise walkthrough to install and configure module for successful replication. Best Philippe
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/38752.

Understand that the module does not affect multilingualism in any way.
There is a basic component of Articles and a blog. By creating a blog or articles menu item, you can specify the article display tag.
The menu item of this component is formed by the item for this component.
This new module forms exactly the same component reference. The module does not affect the component in any way.
If you do not display the articles of the component, it means that the component itself is not configured, or the tags are not configured.

Please tell me more precisely in which folder and which file is missing for the language.

Hey @korenevskiy we had a long discussion in the maintainer team and would like to see something like your module in the core. But as we currently go the way "one module for all" could you do the same and integrate the mod_tags_popular and your model to a new one?

@brianteeman
The fact is that the module externally shows only tags in the form of a tree or list. But the fact is that the link addresses of these tags point to the Category component. Therefore, in fact, this module still applies more to the Category component than to the tag component.
@pcombet-adosis I do not know what to call him correctly. Tell me please. But I wrote categories in the title only because the module opens the categories component.
And since links open another component, this should not confuse the user so that he does not confuse with standard tag modules. We must explicitly indicate that these are links to another component.

The team's decision was correct, that it is impossible to produce unnecessary modules. But this module is superficially similar to mod_popular_tags, but completely different in targets.