You are not logged in.
I know, this topic has been raised several times … But, as we will see 4.5 soon, are there any plans to include more article categories in one of the next releases (4.6, 5.0)?
To me this is one of the major drawbacks of TXP. I never really understood why there are categories at all, if you have only two to choose from. In all four major projects i did in 2012 with TXP this was a serious limitation which I tried to overcome with rss_unlimited_categories. But this plugin is no longer maintained by Rob and we don’t know if it will work with future releases (in addition, from my point of view, it doesn’t integrate very well with the admin area). For commercial projects I don’t feel very well relying on orphaned plugins …
I hope unlimited categories will become part of the core one day.
What’s your thoughts?
hmm, i’m surprised that there seem to be quite few requests for more categories …
Stef is mulling over the multiple categories (and subsections) problem. So maybe one day…
i’m not a programmer at all, but would it be such a big deal just to “adopt” rrs_unlimited_categories and to make it part of the core?
Yes. A few implication of simply adopting a former plugin as a core solution would include…
<txp:if_article_category>accepts a “number” attribute (1 or 2). How will we deal with this number when categories are unlimited? Does it even count then, or shall we simply ignore it?
<txp:category2>need a compatible successor. What is the “first” or “second” category when you have an unlimited set of them?
rss_unlimited_categories (and any other plugin) does not have to consider any of these factors as the site builder makes a deliberate design decision to employ a particular plugin and builds her code around it. This is not true if we change the behaviour of core semantics.
Back compatibility is a huge concern when one can wreck your users’ investments with one single bad decision.
thanks very much for joining this thread. i understand better now.
just an idea: what if textpattern would set up some “core plugins” that are not enabled by default but can if needed? these plugins would be maintained the same way as the core and users can rest assured that they will not be orphaned one day. other cms follow this concept successfully.
my concern is, that some “third-hand-party-plugins” are so important that i feel uncomfortable to rely on it for commercial projects. for example, rob sable developed some very good and important plugins, but at some point quit working on it and disappeared … sure, aks continues some of his work, but for how long?
my candidates for core plugins would be
i know, you are all doing this in your spare time. but maybe one day …
I think we’ve already indicated previously that the next development cycle (Textpattern 4.6) aims for unlimited categories and unlimited custom fields (which are basically just two specialized instances of a general unlimited article properties concept).
It’s just not that easy as one would think at first sight, no matter how you integrate this functionality with what is deemed as “the core”.
I’d even strongly disagree with the concept of core plugins which modify core semantics like e.g. limited vs. unlimited categories. Testing and supporting such a diffuse system would surely turn into a nightmare.
Core plugins were mentioned elsewhere and my understanding was that they were simply plugins maintained by the Textpattern developers and were not integrated into the core at all, just extras that worked and were reliable because txp devs have the insight and knowhow to do the best job with them. I imagine that smd and wet plugins generally work with few or no problems because of their authors’ inside knowledge?
My choice of such ‘core’ plugins would be zem_contact_reborn and rvm_css but if core plugins were to appear I think it should totally be left to the devs to decide which ones. It’s their time and they are already giving lots of it for our benefit.
TXPQ Examples and discussion of Textpattern CMS quality.
I think we’ve already indicated previously that the next development cycle (Textpattern 4.6) aims for unlimited categories
From my own experience I can say that the greatest benefit will be replacing
I use the same site at the same time
limited category and
limited category allow to do quick select (high performance) on the main grounds.
unlimited category is useful to define secondary signs. This statement will be always run slower than