[4.0] Rewrite Tagging System #24551
[4.0] Rewrite Tagging System #24551
Conversation
ghost
added
…4tagsfixes # Conflicts: # components/com_contact/tmpl/contact/default.php
…4tagsfixes # Conflicts: # administrator/components/com_content/Model/ArticleModel.php # components/com_contact/Model/ContactModel.php # installation/sql/mysql/joomla.sql
Co-Authored-By: Quy <quy@fluxbb.org>
…4tagsfixes # Conflicts: # plugins/behaviour/taggable/taggable.php
| $query = $db->getQuery(true); | ||
| $query->select('t.*') | ||
| ->from($query->qn('#__tags', 't')) | ||
| ->leftJoin('#__tag_content_map m ON t.id = m.tag_id') |
There was a problem hiding this comment.
quotename and quote plase on this query
more changes to the rest
…4tagsfixes # Conflicts: # libraries/src/Helper/TagsHelper.php
|
Unfortunately, there seems to be no decision yet on how to proceed with this topic in Joomla 4? |
|
I would love to have this in 4.0, but there are arguments against this right now. I don't think this will be part of 4.0. Maybe we can find a way to add this to 4.1 or something similar... Worst case it will be 5.0 |
|
Do we have a final decision here? This goes for 4.0 4.1 or 5.0? |
|
This will not be part of 4.0. |
Good to see that this finally go into J 4.1 and really looking forward how to could improve Joomla in this space...thks hackwar |
The tagging system in Joomla has several flaws. It is tied to the UCM idea (an idea that itself has failed), it has several routing bugs, it has HORRIBLE code and it is extremely tightly coupled with the component structure that com_content has.
This proposal first of all uncouples the tagging from UCM, even though several concepts are copied over from there. For example copying the data into its own content table isn't something that feels right, but for now that is the best thing that I can come up with under the given circumstances. However as I said the UCM concept is dead and with tagging being tied to UCM, we are limiting us from developing this further or finding better replacements. All changes always interact with the UCM system and are limited by its limitations and cross-dependencies. Thus a standalone tagging system is the way to go, also to be able to drop UCM as a concept from 4.0.
Tagging right now also has issues with routing that can not be really fixed in a B/C way. Trying to fix this here, too.
But most annoyingly the code is just plainout crap. A lot of stuff revolves around the TagsHelper class, which is instantiated as an object time and time again, but doesn't do anything that requires an object. Methods like
TagsHelper::getTagIds()take a CSV string and return a CSV string and it takes a really long time to understand what that method does. Also implementing tags into your component either means that you have to use a rather exact copy of com_content or reimplement everything again yourself.New implementation
This proposal aims for a two-layer-approach. The first layer is a set of classes (in the
\Joomla\CMS\Taggingnamespace) to read and write tags and thus providing an API on which arbitrary code can rely on. The other layer is an implementation for components to use that API.It still relys on a copy of the content data into its own table and thus there is a ContentItem class. Each object of that class is supposed to represent a content item in our tagging system and can be added, deleted or modified. Such a ContentItem object also can give you all tags associated with that item, which then returns an array of Tag objects. A Tag object represents a tag in our system and besides the usual CRUD, it also can provide you all content items associated with that tag. Both classes also allow you to add associations with the respective other class.
To make the distinction clear, the new system also uses new tables.
This would be the first layer and could be used by any code out there in whatever way or form the developer deems fitting. You could add tagging capabilities to your legacy J1.0 component or to your component built on another framework, if you really have to.
The layer on top of that first one depends on a few things. There is the
TaggableTableInterfacewhich signals that this Table wants to implement tagging. The behavior plugintaggablereacts on that interface and does all the necessary steps to process tagging data when editing an item. The necessary code to implement tagging into your component should be pretty minimal with this. The tags field also handles creating tags during data verification, thus not needing any additional calls to obscure TagsHelper methods.Goal & Caveats
This together with #23432 aims to provide a sane, easy to use API and to make it possible to drop the broken remnants of UCM from 4.0. It is a pretty hard B/C break, but would make life so much easier. The code for tagging right now is a horrible mess and I doubt that it will get any better in the coming years if we were to drag this along until 5.0. Why should we rewrite this then, when it is even further established than now? The right way to go seems to me to make the cut now. Also, regarding UCM, I'm pretty sure that there are very few 3PDs out there using this, thus the impact for the community should be pretty minimal. I know that a few Joomla infrastructure systems use UCM, but it shouldn't be that hard to provide them with a plugin that provides the UCM classes until the code has been refactored to also not use this anymore.
Tagging and Versioning are the two big main features that are coupled to UCM. If those two are done and decoupled, then there is very little code left that needs our attention to drop the UCM classes and tables and remove remaining code from our MVC classes.
Current Status
This is a work in progress (and thus opened as a draft PR). There is still lots of stuff to do, but I wanted to make this attempt public in order to get early feedback. I'm also open for any help out there to get this done. 😄