I agree this is useful and has long-been on my list of things to tackle. The main issue stopping me has been backwards compatibility:

The textpattern database table has category1 and category2 dedicated columns - expanding this is not sustainable so we need a category-to-content mapping table.
The other content types only have one column for category name - again, needs to use the mapping table.
The tags and attributes for things like <txp:article> make reference to category1 and category2 explicitly. What happens when we allow more?
Migrating existing category assignments to a new table is definitely doable - ensuring that the category1 value occupies an ID=1 in the new table, and category2 is in slot number 2 - it's just a hassle on upgrade.
How to filter by one or more categories from the URL at once, with ALL/ANY support. See smd_tags for possible solutions, if they can be tidied up.
Category management itself is a pain if you want to maintain lists of categories and keep them in sync across one or more content types. That's more a UX issue separate from unlimited cats, but it's kind of loosely tied with it.

My thinking, if we intend to tackle this, is a clean departure:

Introduce a new table that maps categories to content.
Possibly permit txp:category to accept an id attribute that would extract the category by number from the current content cat assignment. Its use would be discouraged but it could be used internally (see below).
On upgrade, copy existing category assignments for all assets to the mapping table so they are mirrored. Thus <txp:category1 /> and <txp:category id="1" /> are interchangeable. Delete old category columns once content is migrated.
Introduce a container tag for extracting the categories assigned to content. e.g. <txp:categories type="article" wraptag="ul" break="li"><txp:category /></txp:categories> would show a list of all cats assigned to the current article. The type would be inferred from context, and overridable if desired. Not sure how this will interact with the existing use of the URL-aware <txp:category> though, so we might have to come up with a different naming convention (e.g. genus or subject or something).
Introduce conditional tags such as <txp:if_categories> to test if content contains any subject assignment, or test whether it has one or more particular subjects. Bonus marks for ALL/ANY matching. This is essentially <txp:if_article_category> without the number attribute, and applicable to all content types.
Ensure that if a tag uses both new category and categoryN attributes that the former are used and the latter are ignored. Internally, we'll silently map this on your behalf.

Once copied over during upgrade, the new table is used to manage mapping cats to content and all existing content category tags are retrofitted to use it. This maintains backwards compatibility and permits growth.

Long term, the category1/2 tags and attributes can be phased out.

We can probably keep the category naming convention, but I fear it is going to get confusing so perhaps a new convention is better for assignments that are actually made to an asset compared to a list of available categories that may be assigned/available for filtering from the URL. We need to be mindful that:

<txp:category_list> iterates over the category structure to build lists of available cats of a particular type.
<txp:categories> (or something) iterates over the subset of categories that are assigned to a particular content asset.
<txp:category> pulls out the current category from inside the <txp:category_list> container or the current category in the URL, and not the category assigned to a chunk of content. Unless we can find a way to unambiguously dual-purpose it.

Some thought required here. Especially alongside unlimited custom field improvements.

Uh oh!

Add unlimited categories/tagging to the core #1121

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions