Multiple Categories

1,420 views
Skip to first unread message

Hassan Nasir

unread,
Mar 29, 2010, 6:48:30 AM3/29/10
to joomla-...@googlegroups.com
Can there be a way to have one article belong to multiple categories? As have add article to any nested category, it already belongs to multiple categories but under same root? But can we have one article under different roots?


Mark Dexter

unread,
Mar 29, 2010, 10:22:22 AM3/29/10
to joomla-...@googlegroups.com
Hi Hassan. No, an article can only belong to one category. Perhaps the best solution to this is using a tagging system. For example, in 1.5, I wrote an extension called FJ Related Component that lets you create blog and list layouts using keywords as tags. I think there are plans for adding tagging to the core, perhaps for 1.7. Mark

On Mon, Mar 29, 2010 at 3:48 AM, Hassan Nasir <hassan...@gmail.com> wrote:
Can there be a way to have one article belong to multiple categories? As have add article to any nested category, it already belongs to multiple categories but under same root? But can we have one article under different roots?


--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Matt Thomas

unread,
Mar 29, 2010, 10:24:11 AM3/29/10
to joomla-...@googlegroups.com
You've got my vote for inclusion to 1.7.

Matt

Mark Dexter

unread,
Mar 29, 2010, 10:32:13 AM3/29/10
to joomla-...@googlegroups.com
There are at multiple possible approaches to this issue. One would be to simply expand the featured (frontpage) concept to allow multiple featured menu items (for example, Cats, Pets, Animals). The UI for this could be similar to the existing frontpage, except that instead of a yes/no checkbox you would have a drop-down list of available featured menu items and assign an article to one or more of these. Then you could create a blog or list based on the articles tagged for that menu item.

A second approach would be to do something like I do with keywords in my extension and allow the creation of blog or list layouts based on matching keywords.

I'm sure there are other approaches as well. Not sure which approach people would prefer. The multiple featured approach is perhaps the most similar to what we have now and might be the most natural way to extend the functionality. Mark

Mircea

unread,
Mar 29, 2010, 11:43:39 AM3/29/10
to Joomla! CMS Development
Hello,

Hassan, take a look at flexicontent component (flexicontent.org) for
categories multi-mapping options. They made an alpha version for
Joomla 1.6 too..

On 29 Mar, 17:32, Mark Dexter <dextercow...@gmail.com> wrote:
> There are at multiple possible approaches to this issue. One would be to
> simply expand the featured (frontpage) concept to allow multiple featured
> menu items (for example, Cats, Pets, Animals). The UI for this could be
> similar to the existing frontpage, except that instead of a yes/no checkbox
> you would have a drop-down list of available featured menu items and assign
> an article to one or more of these. Then you could create a blog or list
> based on the articles tagged for that menu item.
>
> A second approach would be to do something like I do with keywords in my
> extension and allow the creation of blog or list layouts based on matching
> keywords.
>
> I'm sure there are other approaches as well. Not sure which approach people
> would prefer. The multiple featured approach is perhaps the most similar to
> what we have now and might be the most natural way to extend the
> functionality. Mark
>

> On Mon, Mar 29, 2010 at 7:24 AM, Matt Thomas <m...@betweenbrain.com> wrote:
> > You've got my vote for inclusion to 1.7.
>
> > Matt
>

> > On Mon, Mar 29, 2010 at 10:22 AM, Mark Dexter <dextercow...@gmail.com>wrote:
>
> >> Hi Hassan. No, an article can only belong to one category. Perhaps the
> >> best solution to this is using a tagging system. For example, in 1.5, I
> >> wrote an extension called FJ Related Component that lets you create blog and
> >> list layouts using keywords as tags. I think there are plans for adding
> >> tagging to the core, perhaps for 1.7. Mark
>

> >> On Mon, Mar 29, 2010 at 3:48 AM, Hassan Nasir <hassanmir...@gmail.com>wrote:
>
> >>> Can there be a way to have one article belong to multiple categories? As
> >>> have add article to any nested category, it already belongs to multiple
> >>> categories but under same root? But can we have one article under different
> >>> roots?
>
> >>>  --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "Joomla! CMS Development" group.
> >>> To post to this group, send an email to joomla-...@googlegroups.com.
> >>> To unsubscribe from this group, send email to

> >>> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsu...@googlegroups.com>


> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> >>  --
> >> You received this message because you are subscribed to the Google Groups
> >> "Joomla! CMS Development" group.
> >> To post to this group, send an email to joomla-...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsu...@googlegroups.com>


> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "Joomla! CMS Development" group.
> > To post to this group, send an email to joomla-...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > joomla-dev-cm...@googlegroups.com<joomla-dev-cms%2Bunsu...@googlegroups.com>

Luis M@ster

unread,
Mar 30, 2010, 9:43:40 AM3/30/10
to Joomla! CMS Development
Hi!

This theme of multiple categories is very important, joomla thought I
would take this into consideration in 1.6, I think we still have time
and add this function to joomla, it is really very important and would
solve many problems for developers who create large website.

one of the great problems of joomla 1.5 in security, are third-party
extensions to this should not be needed an extension, this is
something that should be part of the core joomla.

Regards

On 29 mar, 10:22, Mark Dexter <dextercow...@gmail.com> wrote:
> Hola Hassan. No, un artículo sólo puede pertenecer a una categoría. Tal vez la mejor
> solución a esto es usando un sistema de etiquetado. Por ejemplo, en el 1,5, escribí un
> extensión llamada FJ relacionadas componente que le permite crear un blog y la lista de
> diseños utilizando palabras clave como etiquetas. Creo que hay planes para añadir etiquetas
> hasta la médula, tal vez por 1,7. Mark
>
> El Lun, 29 de marzo 2010 a las 3:48 AM, Hassan <hassanmir Nasir...gmail.com>escribió:
>
>
>
>
>
> > ¿Puede haber una manera de tener un artículo pertenecen a varias categorías? Ya que
> > Han añadir el artículo a una categoría anidados, que ya pertenece a múltiples
> Categorías> pero en la misma raíz? Pero, ¿podemos tener un artículo en diferentes
> Raíces>?
>
> > --
> > Has recibido este mensaje porque estás suscrito a los Grupos de Google
> > "CMS Joomla! Desarrollo" del grupo.
> > Para enviar mensajes a este grupo, envía un correo electrónico a joomla-...@googlegroups.com.
> > Para darse de baja de este grupo, envía un correo electrónico a
> > Joomla-dev-cms + unsub...@googlegroups.com <joomla-dev-cms% 2Bunsubscribe @ googlegroups.com>
> >.
> > Para obtener más opciones, visita este grupo en
> >Http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

Ian MacLennan

unread,
Mar 30, 2010, 9:53:30 AM3/30/10
to joomla-...@googlegroups.com
Yes, there is certainly still time to add this feature in 1.7 or later.

Regards

2010/3/30 Luis M@ster <luism...@iwebdevelope.com>

Luis M@ster

unread,
Mar 30, 2010, 10:22:55 AM3/30/10
to Joomla! CMS Development
Not that I'm impatient, but we are in the alpha of 1.6 and we are
talking about the 1.7, I do not have to wait a year, to integrate this
function to joomla. not what I mean. can not speak for the 1.7, if
1.6, this in development.

Sorry if I sound bad.

On 30 mar, 09:53, Ian MacLennan <ian.maclen...@joomla.org> wrote:
> Sí, sin duda hay todavía tiempo para añadir esta característica en 1.7 o posterior.
>
> Recuerdos
>
> 2010/3/30 Luis M @ ster <luismas...iwebdevelope.com>
>
>
>
>
>
> > Hi!
>
> > Este tema de varias categorías es muy importante, pensé que joomla
> > Lo tomaría en consideración en 1,6, creo que todavía estamos a tiempo
> > Y añadir esta función a Joomla, es realmente muy importante y
> > Resolver los muchos problemas a los desarrolladores que crean gran sitio web.
>
> > Uno de los grandes problemas de Joomla 1.5 en la seguridad, son de terceros
> > Extensiones a esto no debería ser necesaria una ampliación, esto es
> > Algo que debería ser parte de la comunidad de Joomla básico.
>
> > Regards
>
> > El 29 de marzo, 10:22, Mark <dextercow Dexter...gmail.com>escribió:
> >> Hola Hassan. No, sólo un articulo Puede Pertenecer A UNA categoría. Tal
> > Vez la mejor
> >> Solución a esto es usando un sistema de etiquetado. Por ejemplo, en el
> > 1,5, escribí un
> >> Extensión llamada FJ relacionadas componente que le Permite Crear un blog
> > Y la lista de
> >> Diseños Utilizando palabras clave como etiquetas. Creo que hay aviones
> Añadir etiquetas> para
> >> Hasta la médula, tal vez por 1,7. Mark
>
> >> El Lun, 29 de marzo 2010 a las 3:48 AM, Hassan <Nasir hassanmir ...
> > Gmail.com> escribió:
>
> >>> ¿Puede haber una Manera de Tener un artículo pertenecen uno varias
> > Categorías? Que Ya
> >>> Han añadir el artículo A UNA Anidados categoría, que ya Pertenece a
> > Múltiples
> >> Categorías> pero en la misma Raíz? Pero, ¿podemos Tener un artículo en
> > Diferentes
> >> Raíces>?
>
> >>> --
> >>> ¿Ha recibido este mensaje Porque estás suscrito A LOS Grupos de Google
> >>> "CMS Joomla! Y Desarrollo" del grupo.
> >>> Para enviar mensajes a este grupo, Envía un correo electrónico a
> > Joomla-...@googlegroups.com.
> >>> Para darse de baja de este grupo, Envía un correo electrónico a
> >>> Joomla-dev-cms + unsub...@googlegroups.com <joomla-dev-cms%
> > 2Bunsu...@googlegroups.com>
> >>>.
> >>> Para Obtener más opciones, visita este grupo en
> >>> Http: / / / groups.google.com / group / dev-joomla-cms? Hl = es-ES.

Sam Moffatt

unread,
Mar 30, 2010, 5:22:08 PM3/30/10
to joomla-...@googlegroups.com
If one keeps adding features then one remains at alpha because new
features invariably mean new bugs. If you want I can give you access
and you can have a branch to build the functionality proposed.

Cheers,

Sam Moffatt
http://pasamio.id.au

2010/3/31 Luis M@ster <luism...@iwebdevelope.com>:

Luis M@ster

unread,
Mar 30, 2010, 7:00:40 PM3/30/10
to Joomla! CMS Development

Hi Sam Moffatt

He is absolutely right in what he says, I hope that in future this
function is taken into consideration as it is very important.

if you can send the access, thanks you very much.

Regards

Jase Williams

unread,
Oct 19, 2012, 7:01:53 AM10/19/12
to joomla-...@googlegroups.com, hassan...@gmail.com
What happened to this?
Is anyone planning on working on this or has it been scraped?

Thanks
Jason

Nils Rückmann

unread,
Oct 19, 2012, 9:39:55 AM10/19/12
to joomla-...@googlegroups.com, hassan...@gmail.com
Nope, but it's still a must have. I think the mian problem is our router (sef) and the way how to inherit.

elin

unread,
Oct 19, 2012, 6:43:04 PM10/19/12
to joomla-...@googlegroups.com, hassan...@gmail.com
The routing has nothing to do with why we don't have a tagging system. We don't have a tagging system because if I go look in the feature tracker or in the platform tracker I don't see any code submitted to implement one or to supply the underlying classes needed.  The closest we have in the CMS are two things: Smart Search filters and related items using the metadata keywords. It would be great for someone to take related items and extend it to all core components and also create a way to make menu items for the keywords. Since Smart search indexes the keywords already there may be a way to work with that.

It's a great project for someone to take on for 3.1.

Elin

Nils Rückmann

unread,
Oct 19, 2012, 8:04:48 PM10/19/12
to joomla-...@googlegroups.com, hassan...@gmail.com
Are we talking about tags or about multiple categories ?

Mark Dexter

unread,
Oct 19, 2012, 10:45:25 PM10/19/12
to joomla-...@googlegroups.com
I would like to understand the use case for multiple categories. The
only one I have heard is to allow for articles (or other content) to
list on multiple pages -- for example, in multiple lists or blogs.
This use case is best handled with tagging.

So, the question is: what are the use cases for multiple categories?

Thanks. Mark

On Fri, Oct 19, 2012 at 5:04 PM, Nils Rückmann <in...@nils-rueckmann.de> wrote:
> Are we talking about tags or about multiple categories ?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/EopVUbEqrloJ.

ssnobben

unread,
Oct 20, 2012, 3:46:41 AM10/20/12
to joomla-...@googlegroups.com, hassan...@gmail.com
This was discussed before also when discussions were about sections/categories and about tagging system comparison with how Drupal doing things.

What I would like to achieve with Joomla is a possible standard way to structure content (articles) "many-to-many" in conjunction also with all Joomla components(modules), adding more semantic relations with a structured/unstructured tagging system? Maybe you can achieve this in another way and I have not understood it.

Let say you create an German article about Italian cars in the city Modena or you write an similar forum post in Kuena, or a similar blogging post in Easyblog or setting up a Italian car company from Modena in Sobi2 directory or Seblod CCK etc all should be possible to use this standard tagging system? as an option if you can multi categorise them by article tagging in standard way. Its like now Easyblog have its own tag system and xxx have its own tag system without any relation to each other. So now you have multiple tag system that not work together.

Example: when you would like to have a multi mapping for this article to your semantic structured tagging system for Joomla blog categories-->World-->Europe-->Italy-->Cars but also with Joomlas own standard multi select semantic structured(unstructured) tagging system for-->Sportscars-->Ferrari, Lamborghini, etc where you can find/filter what you are looking for. So Joomla would have a browser friendly easy to understand content system.

So when you browse for content you can do it by categories/nested categories on a Joomla front page but also by the semantic related system by tagging filters..


This is an extract from the early discussions 2008 about tagging system and the replacement of our section/categories discussions..

http://forum.joomla.org/viewtopic.php?f=500&t=273958
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Author:  darb [ Sun Mar 09, 2008 5:13 pm ]
Post subject:  Re: Replace Section/Category with Tagging (Draft)

I dont think this is a good idea at all. To take away the section/category structure of Joomla.

As I understand Delicious is non-hierarchical structure using tags for mapping social bookmarks?

What Joomla must preserve is to be m o r e and better hierarchical structured than today working with attributes/topics and terms (Drupal word), nodes and t a x o n o m y.

How you do when you want to map many to many attributes? Tags is useful when you have a couple of hundreds relations but what happens later when you got 1000 and 10000 of them? And how do you map them accurately and how will I find them? only by searching? I think its important not to miss the browsing too.

Tagging is good for SEO and making an extra way of finding your content but not in my opinion to replace Joomlas core structure...

But using taxonomy system is a powerful way to categorize and structure the content of a site and to specify how different categories are semantically related to each other; that is how their meaning is related. Using Taxonomy you can build trees (known as vocabularies) of topics (known as terms) to define the conceptual and semantic structure of your site. The tree can illustrate the purpose, meaning and relationship of one node to another. This is how it works with Drupal and I hope Joomla will following this instead...

Nils Rückmann

unread,
Oct 20, 2012, 6:46:22 AM10/20/12
to joomla-...@googlegroups.com, hassan...@gmail.com
Of course your're right Mark, but i see a difference between tags and categories. First of all, categories can be hierachical (tags too, but isn't a common behavior). And categories are a sort of "parent" where items can inherit params or something.

Recently i worked on an ecommerce system for joomla where exactly this problem appears. My solution was to have a main category, which is used for the canonical url and so on, and the ability to add the item to more categories. The layout params for example comes from the current displayed category. Maybe it's not the best solution, but it worked for me.

What i'm trying to explain is that since we have a global category system, we should also think about our extensions by giving them the most of possible abilities.

Mark Dexter

unread,
Oct 20, 2012, 10:47:38 AM10/20/12
to joomla-...@googlegroups.com
@ssnobben: If I understand you correctly, what you are describing can
be easily accomplished with a tagging system. You would tag arrticles
with whatever keywords (or tags) fit (for example, World, Europe,
Cars, Italy, Blue) and then you could retrieve cars that fit any
combination of those tags.

@Nils: I don't understand your use case? Why does it need to be categories?

We use categories, for example, in the ACL. Imo, the ACL is
complicated enough without trying to explain to users what happens
when an article is in 3 categories that have different ACL
permissions. Or what happens when an article is in 3 categories and 1
is unpublished. Or 1 is deleted.

At this point I think if we discuss use cases it will be more helpful
than discussing specific implementations or features. What are other
use cases that we would like to have a core answer for?

Thanks. Mark
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/78lJKi9Z6OIJ.

elin

unread,
Oct 20, 2012, 11:09:34 AM10/20/12
to joomla-...@googlegroups.com
Categories use nested sets http://en.wikipedia.org/wiki/Nested_set_model   http://docs.joomla.org/Using_nested_sets They are defined to be hierarchical and we use them with inheritance and each item can only have one parent by the definition of nested sets. You cannot change the math of that.  Pre order transversal is pre order transversal and that is it.

 So if you want something that allows multiple parents you need to use a different graph theoretic approach, one that allows overlapping sets. It would be awesome for someone to implement this.

Alternatively you can use a simple tagging model which would just require keeping a list of the tags. This is easy in the sense that you can just make a plugin for smart search that indexes the tags (or as I said just use the keyword field in metadata since smart search already indexes those and just implement a smart search menu filter based on the keywords only).

Elin


Elin

Niels Braczek

unread,
Oct 20, 2012, 11:16:53 AM10/20/12
to joomla-...@googlegroups.com
Am 20.10.2012 04:45, schrieb Mark Dexter:

> So, the question is: what are the use cases for multiple categories?^

Consider a shop selling electr(on)ic devices, like tv sets,
refridgerators, notebooks, ...
The shop has categories for each kind of device, with appropriate parent
and sub categories, so the user easily can browse the goods.

Now ACME Corp presents a new device: a no-noise flat refridgerator with
a 40" tv flat screen as the door, so you can have cooled beer in your
living room just behind your tv set.

Where should the shop owner put this device? In 'tv sets' or in
'refridgerators'? Obviously, the device belongs to both. A separate
category would not do the job, because neither tv set nor refridgerator
customers would find it.

Regards,
Niels

--
| http://barcamp-wk.de · 2. Barcamp Westküste Frühjahr 2013 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

Nils Rückmann

unread,
Oct 20, 2012, 11:23:35 AM10/20/12
to joomla-...@googlegroups.com
@elin: of course, the nested set only provides one parent. but articles (or other items) aren't part of the nested set. nobody wants to have an n:m relation between categories.

@mark: okay, it could be tags. but we haven't any tags at the moment ;) .. so i step back and say, let's provide some stuff for multi assinging, which is used by the core, but also can be used for extensions.

elin

unread,
Oct 20, 2012, 11:27:47 AM10/20/12
to joomla-...@googlegroups.com
This is what I keep saying. It cannot be part of the categories system. 
When you use the term categories in the context of the joomla cms you are referring to nested sets.
If you want to talk about something else use a different term. Otherwise it's just the same going in circles. 

Elin

Niels Braczek

unread,
Oct 20, 2012, 11:27:49 AM10/20/12
to joomla-...@googlegroups.com
Am 20.10.2012 16:47, schrieb Mark Dexter:

> We use categories, for example, in the ACL. Imo, the ACL is
> complicated enough without trying to explain to users what happens
> when an article is in 3 categories that have different ACL
> permissions.

Then the system is mis-configured. Any outcome (use the weakest or
strongest path) would be appropriate. I'd prefer the strongest, though.

> Or what happens when an article is in 3 categories and 1
> is unpublished.

The unpublished category is treated as non-existent. No problem at all.

> Or 1 is deleted.

Non-empty categories are not (should not be) deletable.

> At this point I think if we discuss use cases it will be more helpful
> than discussing specific implementations or features. What are other
> use cases that we would like to have a core answer for?

Not only should it be possible to assign an article to multiple
categories, categories must also be able to have multiple parents, and,
last but not least, categories must be independent from any component.
It must be possible to assign articles, weblinks, contacts, forums, shop
items, ... to the very same category. (I know that the latter is not
possible now, but it is a requirement for any Unified Content Model.)

Niels Braczek

unread,
Oct 20, 2012, 11:30:39 AM10/20/12
to joomla-...@googlegroups.com
Am 20.10.2012 17:09, schrieb elin:

> Categories use nested sets http://en.wikipedia.org/wiki/Nested_set_model
> http://docs.joomla.org/Using_nested_sets They are defined to be
> hierarchical and we use them with inheritance and each item can only have
> one parent by the definition of nested sets. You cannot change the math of
> that. Pre order transversal is pre order transversal and that is it.

That's another reason, why one should avoid nested sets.

Mike Hamanaka

unread,
Oct 20, 2012, 11:48:11 AM10/20/12
to joomla-...@googlegroups.com
> Not only should it be possible to assign an article to multiple
> categories, categories must also be able to have multiple parents, and,
> last but not least, categories must be independent from any component.
> It must be possible to assign articles, weblinks, contacts, forums, shop
> items, ... to the very same category. (I know that the latter is not
> possible now, but it is a requirement for any Unified Content Model.)

I like this suggestion, meta keywords was a way I have attempted to solve this just for articles, but possibly this would be implemented not as tags, as the tags have traditionally been thought as only for one component type like articles, but now that I have read the above argument for UCM, I am thinking that now we could be thinking of a "super-tag" as an alternative (or in addition to) categories when making use of the future joomla tagging feature, and using meta keywords just as keywords, this super-tagging could be designed to be flexible enough to unite disparate content types across a Joomla website, and be able to offer filterable results, and multiple categorizations of any content type. Just a thought.

Mark Dexter

unread,
Oct 20, 2012, 12:36:18 PM10/20/12
to joomla-...@googlegroups.com
I think the best answer for tagging, as Elin mentioned earlier, is to
use Smart Search along with a new tagging feature. This would give us
everything we get with tagging, plus a lot of extra's that come with
Smart Search.

To me, the first step for this might be to create a #__common table
(or some other name) that has all of the common columns from all of
the content tables (id, state, start/stop publishing, language, etc.).
That way, we can add tagging without worrying about dealing with the
separate components. The other piece of this would be a smart-search
list and blog layout, which could be worked on independently and which
is pretty easy to do (I think).

However, for any of this to happen, we need people willing to step up
and work on code.

Mark
> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

Nils Rückmann

unread,
Oct 20, 2012, 7:52:34 PM10/20/12
to joomla-...@googlegroups.com
However, for any of this to happen, we need people willing to step up
and work on code.

But willing people should at least know if there's a chance that the code will be adopted.
I have great respect for all people who spend hours, days or maybe weeks to code something without the knowledge
if the community will accept it.

That's by the way the reason why i'm asking about the need of a dependency system for extensions (and core).

elin

unread,
Oct 20, 2012, 9:33:11 PM10/20/12
to joomla-...@googlegroups.com
Until there is code there is no way to know that it is good enough. That's the fact. No matter how useful the feature is, if the code for it is no good--in fact if it is not excellent-- it cannot and should not go in.

Everyone plays on the same playing field and no one get a guarantee. If you can't live with that then that's that.  It's no different than being an author or an artist. 

Elin

Matt Thomas

unread,
Oct 20, 2012, 10:10:16 PM10/20/12
to joomla-...@googlegroups.com

It's really a shame that this is the kind of response Nils gets. He was simply asking for feedback on the concept of the feature. Instead of some sort encouragement or general feedback, that might result in some code, this is what he gets, which will likely further discourage any possible contribution. I know it discourages me even more from bothering to code a new feature for consideration.

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Composed and delivered courtesy of Nexus 7.
On Oct 20, 2012 9:33 PM, "elin" <elin....@gmail.com> wrote:

Victor Drover

unread,
Oct 20, 2012, 11:39:55 PM10/20/12
to joomla-...@googlegroups.com
Let's see if we can't change the direction. 

In the current JCal Pro build, we extend joomla categories to organize events. We use a main or canonical category to control URL aliases and event permissions, and then maintain a separate DB table to cross-reference the events to any number of secondary categories. We don't use the secondary categories (again, just Joomla categories) for basically tagging. 

This setup gives us the best of both worlds: we use Joomla's categories and don't need to add a "tag" feature. By restricting all ACL and such to just the canonical category, we don't have any of the complicated ACL issues mentioned earlier. 

In any event, we've built it, it works great, and I think it meets all the criteria mentioned earlier in this thread.

Feedback on applying this concept to com_content would be appreciated. If it suits the bill, we'd be happy to submit it.

-V

Milton Bryant

unread,
Oct 20, 2012, 10:59:15 PM10/20/12
to joomla-...@googlegroups.com
I think the comparison would be more appropriate to describe a developer who codes for a living. Because an author or artist usually works with the idea of being paid for their efforts.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/WdrVYAkGT8sJ.

Nils Rückmann

unread,
Oct 21, 2012, 8:49:00 AM10/21/12
to joomla-...@googlegroups.com
Thanks Matt, unfortunately that's the way the joomla community is working. Reminds me of a simple bugfix which i submitted. After months of waiting i have asked about it. The answer i've got was something like "don't care, if you want to fix something you have to do more than writing a patch, creating an item in the bug tracker and on github, you have to begging around for people to test it".

So it tells me again to step back, leave the core alone and investing my time for own projects.

elin

unread,
Oct 21, 2012, 10:58:18 AM10/21/12
to joomla-...@googlegroups.com
I don't get how explaining the process to you is negative or discouraging in any way.

Elin

G. D. Speer

unread,
Oct 21, 2012, 11:08:54 AM10/21/12
to joomla-...@googlegroups.com
Ouch -
Isn't this message a bit harsh and counter productive? 
I'm not disagreeing with your points - yes code has to be excellent, code cannot be evaluated before it exists, and there are no guarantees even for excelent code.  Yoou have certainly moderated expectations.
 
But, this answer is also putting volunteer contributors in a box because it shuts down the conceptual discussion of "if I build it - would it fly?"  I would much rather allow a contributor to get feedback on a concept as to whether it is "directionally correct" and in line with the Joomla Project vision long before hundreds of hours are invested getting to as first draft codeset, only to get the response "it's not appropriate for core" or "there are dependencies you did not know to consider."
 
Maybe I'm misreading your tone, but I would rather encourage the dialog and potential new contributions than put high hurdles in their path and put a damper on the discussion, forcing willing volunteers to guess in the dark about the direction of the roadmap at their peril.
 
Just sayin,
 
 
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/WdrVYAkGT8sJ.

Mark Dexter

unread,
Oct 21, 2012, 11:11:36 AM10/21/12
to joomla-...@googlegroups.com
@Victor: I don't quite understand what you have done. Why do you use
categories for the secondary cross-reference? What advantage does that
give you (as opposed to adding a tags table).

I'm not sure what this means: "We don't use the secondary categories
(again, just Joomla categories) for basically tagging." (Possibly a
typo? You don't use them for anything except tagging?)

If some categories are used for ACL and others are used only for
tagging, is that potentially confusing?

Thanks. Mark

Victor Drover

unread,
Oct 21, 2012, 11:12:48 AM10/21/12
to joomla-...@googlegroups.com
Regardless of the tone, Elin is correct. The take home message to me is clear: "Yes, there is a chance it will get accepted." I think that was the crux of the issue originally. 

Not sure if my first reply came through, so lets try again:

In the current JCal Pro build, we extend joomla categories to organize events. We use a main or canonical category to control URL aliases and event permissions, and then maintain a separate DB table to cross-reference the events to any number of secondary categories. We use the secondary categories (again, just Joomla categories) only for tagging purposes, thus sidestepping any ACL issues for examnple. 

This setup gives us the best of both worlds: we use Joomla's categories and don't need to add a "tag" feature. By restricting all ACL and such to just the canonical category, we don't have any of the complicated ACL issues mentioned earlier. 

In any event, we've built it, it works great, and I think it meets all the criteria mentioned earlier in this thread.

Feedback on applying this concept to com_content would be appreciated. If it suits the bill, we'd be happy to submit it.

-V

Victor Drover

unread,
Oct 21, 2012, 11:29:10 AM10/21/12
to joomla-...@googlegroups.com
Since we're simply extending/using Joomla's categories, each category can have its own parameters such as ACL (in JCal, we have lots of other parameters, but that's not pertinent here).

The critical thing to note is that only the parameters from the canonical/primary category apply to an event. If an events also has secondary categories specified, these categories are (i) stored in the cross-reference DB table and (ii) are only used for tagging.

Perhaps an example would be helpful.

Event 1, Vic's Birthday: primary cat = birthday, secondary cat = personal
Event 2, Joe's Birthday: primary cat = birthday, secondary cat = personal
Event 3, Lady Gaga Concert: primary cat = music, secondary cat = personal

Now, lets say we have menu items for each category, and the category ACL is as follows: birthday (special), music (public), personal (special). We might also have a menu item for ALL categories.

In the Birthday menu item, we'd see Event 1 and Event 2 only if an admin was logged in as per the category permissions.

In the Music menu item, we'd see Event 3 all the time as the primary category has public permissions.

In the Personal menu item, we'll see all 3 events when logged in as an admin, and just Event 3 if not logged in.

In the All menu item, we'll see all 3 events when logged in as an admin, and just Event 3 if not logged in.

All the parameters that control event display go back to the canonical category (as does URL re-writing), with the secondary used for tagging.

Does that help explain it?

Ofer Cohen

unread,
Oct 21, 2012, 2:38:09 PM10/21/12
to joomla-...@googlegroups.com

I think we need to make it simple.
leave the category as is, and we should build general tagging system that can be integrated with multiple components (just like categories). In addition, as Elin mentioned, we also should integrated this with smart search.
In the future we could extend it to multi category with cross reference, but first let's build simple tagging, cause tagging feature is very valuable feature for CMS.

just my shnekel :)

Ofer

Victor Drover

unread,
Oct 21, 2012, 2:46:19 PM10/21/12
to joomla-...@googlegroups.com
I don't actually think that's simpler since  I need to add a new feature. categories already can be used by all extensions. I think we get 2-for-1 with my proposal. 

Sent from my iPhone

Mark Dexter

unread,
Oct 21, 2012, 4:57:49 PM10/21/12
to joomla-...@googlegroups.com
I agree with Ofer on this. The categories do what they are designed to
do at present, and I think it is better in the long run to build a
proper tagging system. Using categories for two separate things seems
to me to be confusing and a bit of a kluge. That's my .02. Mark

Victor Drover

unread,
Oct 21, 2012, 8:00:08 PM10/21/12
to joomla-...@googlegroups.com
It guess its a difference of philosophy. What is tagging except another way to categorize things?

brian teeman

unread,
Oct 22, 2012, 4:46:07 AM10/22/12
to joomla-...@googlegroups.com
If I understand this correctly victor is proposing a method of placing items into multiple categories using the existing category structure but allocating the categories to an item by defining each category with a different priority. And Marc is talking about using a completely separate system "tags" which will be in addition to the category system.

On a simple system with limited content I can see victors system working adequately but my worry is that such a system will get very complicated when you have lots of content. It would be ok when you are displaying single level categories but I can see it getting into a real mess when you have nested categories.

Having said that it's only a guess and the only way to really tell would be to have some code that can be tested in real world environments.

Marc's tagging solution seems a better option in the long run as it sits outside of the category structure but I don't like the idea of it relying on smart search to display it as that still has many issues on sites that fully use the ACL.

shumisha

unread,
Oct 22, 2012, 4:47:10 AM10/22/12
to joomla-...@googlegroups.com
Hi All,

@Mark, @Ofer: there seem to be a confusion about the request/proposal, in that you seem to assume tagging can achieve the desired function.

I don't think tagging can be used to achieve the desired behavior. The reason was already given by Nils, but seems to have been overlooked: tags are (usually) not hierarchical.
Tags serves another purpose (mark "things" across an existing hierarchy), while the proposal is simply for an improved hierarchy.

Maybe an example would clarify my understanding of the desired/proposed behavior. Going to use contacts for a change:

Category: /joomla/support/programming -> Mark, Nils, Elin, Victor
Category: /joomla/support/templates -> Kyle, Elin, Steve
Category: /joomla/legal -> Steve, Victor
Category: /joomla/community -> Elin, Mark, Victor
Category: /joomla/community/France -> Yannick
Category: /wordpress/support/templates -> Steve, Matt

Now without any additional work, you can display:

view /joomla/support ==> Mark, Nils, Elin, Victor, Kyle, Steve
view /joomla ==> (everybody except Matt)

Using tagging, you'd have to tag all contacts to say they belong to: 'joomla' to have the /joomla view work properly.
Likewise, you'd have to tag everybody in /support/programming and /support/templates to say they belong to 'support', 'joomla' AND 'templates' or 'programming' respectively, instead of letting them inherit all "tags" from the category hierarchy they belong to.

A couple more things:

- no change is needed to the current category structure or programming paradigm. This is about how categories are used, not how they are built, operate.
- categories will not be used for two different things. The introduction of the word 'tagging' here has led to believe that the proposal was to mimic "tags" with categories. That is not the case.

PS: The names used here are purely fictional. Any resemblance to any real person would be purely coincidental, as evidenced by Victor being put in the "programming" support team.

Mike Hamanaka

unread,
Oct 22, 2012, 4:53:17 AM10/22/12
to joomla-...@googlegroups.com
On a simple system with limited content I can see victors system working adequately but my worry is that such a system will get very complicated when you have lots of content. It would be ok when you are displaying single level categories but I can see it getting into a real mess when you have nested categories.

Having said that it's only a guess and the only way to really tell would be to have some code that can be tested in real world environments.

Right, the only way to see if Victor's categories as tags system would work is by testing it,  At least from how it was explained by Victor, I don't think it would get messy with nested categories, the only complication I could imagine is how you would easily separate the two types of categories in the category manager and category selectors.

brian teeman

unread,
Oct 22, 2012, 5:42:39 AM10/22/12
to joomla-...@googlegroups.com
Yannick now you have really confused me as your example is very different to victors

brian teeman

unread,
Oct 22, 2012, 7:07:06 AM10/22/12
to joomla-...@googlegroups.com
Having spoken to Yannick things are a little clearer to me now. you would need just two category selectors for an item. One will select the primary (or canonical) category just as we have right now and the additional one (which would be optional for people to use) would be a multi-select which you could use to put the item into other categories.

Daniele Rosario

unread,
Oct 22, 2012, 7:14:42 AM10/22/12
to joomla-...@googlegroups.com
If you want to see a live example of this, zoo from yootheme uses the same concept for its categories

Daniele Rosario
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/zUXgxROSDuEJ.

Nils Rückmann

unread,
Oct 22, 2012, 9:10:21 AM10/22/12
to joomla-...@googlegroups.com
That's exactly what i was talking about two days ago.

Recently i worked on an ecommerce system for joomla where exactly this problem appears. My solution was to have a main category, which is used for the canonical url and so on, and the ability to add the item to more categories. The layout params for example comes from the current displayed category. Maybe it's not the best solution, but it worked for me.

Maybe next time i should descripe it more detailed. But while i'm using the same concept, it still feels like a workaround.

Lately i was thinking about the ACL problem with multi-categories and came more and more to the decision that there isn't really a problem. Today we are using only "create", "delete" and "edit":
  1. If i create an article the ACL is only used by getting possbile categories, so nothing will changed.
  2. If i want to delete an article i have to check if its in a category where i be able to delte something. So instead of getting the permission of one category we will loop through assigned categories.
  3. If i want to edit an article it's the same thing like to delete.

The only thing we need is the assumption that by default it's denied and loop through the categories until he gets the permission (if he gets it). And the best: If he uses only one category per article, ut's the same behavior like now.

So if the ACL isn't a problem i see two others: sef-urls and access.

I don't like our sef-urls generally. But a short soultion could be to use an extra slide/accordion/fieldset for seo related stuff with an option to to use a category for sef-urls. The alias and the meta options could also belongs to that slide/accordion/fieldset.

About the access i want to ask first if there's any approach of changes. Wasn't there something about adding something like "privacy" to differentiate between access to an item and view the item (-intro) ?

Are there more problem which i may overlooked ?


Nils Rückmann

unread,
Oct 22, 2012, 9:19:46 AM10/22/12
to joomla-...@googlegroups.com
btw: If i'm right we are using the access-column instead of real ACl, because there's currently no good way to use the ACL in our db-queries. But if we use a mapping table instead of "wibbly wobbly"-json we can throw out the access-column.

Mark Dexter

unread,
Oct 22, 2012, 11:13:52 AM10/22/12
to joomla-...@googlegroups.com
I may well be missing something important, but I'm not seeing a
compelling advantage to a hierarchical tagging system. It would seem
to be a trade-off between less maintenance (in some cases) vs.
increased complexity and decreased flexibility.

In the examples above, with a simple, flat tagging system you would
just tag an item with all tags that apply to that item. I suppose if
you wanted to get fancy you could have pre-defined groups of tags or a
copy tags from another item feature.

For example, in shumisha's example above, what if I wanted to be
tagged as joomla & programming, but not as support? Would this be
possible? Is it really more work to just click each tag that applies?

One benefit of a tagging system (to me at least) is that it is
completely unstructured and you can tag things with any combination of
tags that makes sense for that item. I'm not sure that trying to fit
this into a hierarchy is a good trade-off.

Again, just my .02. Mark
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/ByvmGLmDOEEJ.

Niels Braczek

unread,
Oct 22, 2012, 12:19:08 PM10/22/12
to joomla-...@googlegroups.com
Am 22.10.2012 17:13, schrieb Mark Dexter:

> One benefit of a tagging system (to me at least) is that it is
> completely unstructured and you can tag things with any combination of
> tags that makes sense for that item. I'm not sure that trying to fit
> this into a hierarchy is a good trade-off.

I shared your point of view for a very long time. For me, categories
always were equal to menu structure.

But: Tags are not related to each other. Say you want Ann to be tagged
as a Joomla developer and a WordPress supporter. Tagging gives you
[Joomla] [developer] [WordPress] [supporter]. Thus, she'll be reported
as a Joomla supporter and WordPress developer as well, which is not
correct. To avoid that, you'll have to repeat yourself: [Joomla] [Joomla
developer] [WordPress] [WordPress supporter]. If you have three ore more
levels, this gets really annoying.

Another example for multi-categories is the tv-refridgerator
combination, I mentioned earlier.

You can replace tagging (and taxonomy, for completeness' sake)
seemlessly with multi-categories, but not vice versa.

Beside of that, multi-categories is one of the top ten requested
features (1,165 votes) on ideas.joomla.org. We can't really ignore that.

I'm sure that we'll see a lot of usecases, we never thought of, once
this feature is out in the wild.

Victor's proposal sounds reasonable to me. We should at least have a
closer look on it.

Regards,
Niels

--
| http://barcamp-wk.de · 2. Barcamp Westküste Frühjahr 2013 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

Mark Dexter

unread,
Oct 22, 2012, 12:54:06 PM10/22/12
to joomla-...@googlegroups.com
Hi Niels. I'm still not following. In your first example, I would
think the tags should be "Joomla Supporter" and "Wordpress Supporter"
so you can keep them separate.

If there is a compelling reason to make tags hierarchical, we could do
that. Just make it a tablenested table like categories. I'm not
convinced this is needed, but it could be done. I can't think of a use
case where a hierarchical system can do something that a flat system
can't do, although there could be cases where you could do it with
fewer tags (hence the other idea of tag groups).

It still seems confusing to use categories in two completely different
ways. The current use is analogous to folders, to be used by the ACL
and when looking at published state. There the current
one-category-to-many-items makes perfect sense (at least to me).

As far as the Ideas site, I agree with you that this is very important
to pay attention to. However, to me the "multiple categories" idea is
very ambiguous and can easily mean different things to different
people. So far the only use case I have seen is the tagging idea. So,
if this is what people on the Ideas site mean by multiple categories,
then tagging would fit that need.

I agree that it could be valuable to look at different options for
this. If someone wants to post some code or a detailed design document
with what multiple categories might look like, it would well be worth
looking at and discussing further.

Mark
> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

javier gómez

unread,
Oct 22, 2012, 1:08:27 PM10/22/12
to joomla-...@googlegroups.com
Maybe is a bit off-topic, but finding the best category solution is just impossible because there is always different needs.

Why we just provide different "categorization algorithms" to the Platform and the "component in the CMS" that will deal with it to be used for different needs in components.

For example:
- The current category system is very cool and good in performance, but the tree database structure makes difficult to create a new category via script (see https://gist.github.com/3211464). Sometimes a component will don't use much cagegories (maybe just 1 deep level) so for that situation maybe it would be simple to use a similar approach to the 1.5 solution.

Maybe there can be in the future a bunch of solutions that you can use with your component: category (com_categories), simple-category (com_simplecategories), multi-category (com_multicategories), taxonomy (com_tags)... 
And each one will have it's benefits and it's bad things, so the component builder can choose between the ones that fits better with his/her needs.

The benefit is that the code contributors don't need to find the perfect solution that makes everyone happy. Just one possible solution. Obviously this solution must be efficient in all cases.

Just an idea.
--
Javi

Nils Rückmann

unread,
Oct 22, 2012, 1:19:12 PM10/22/12
to joomla-...@googlegroups.com
is there a particular reason why my posting is be ignored ? Bad english maybe ? Not detailed ? Completly wrong ?

shumisha

unread,
Oct 22, 2012, 2:55:35 PM10/22/12
to joomla-...@googlegroups.com
Hi Nils,

They are not ;)

Regarding SEF urls, an aread I'm familiar with, you actually don't need to change anything to the current system. In that particular case, the same item should have different urls when displayed as part of one category or another, so there's no need to select a specific category for building the sef urls.
There is such need however, to make sure a canonical tag is inserted and link to the proper page: ie the page where this item is displayed as part of its "primary" category. So there's a need, as outlined by Brian above, for a "primary" category selector, on top of the ability to select "secondary" categories an item belongs to.



Le lundi 22 octobre 2012 19:19:12 UTC+2, Nils Rückmann a écrit :

Nils Rückmann

unread,
Oct 22, 2012, 3:21:06 PM10/22/12
to joomla-...@googlegroups.com
Yes you're right, we need something for the sefurl. But my proposal was have the multi-categories-field as primary and the sef-category stuff besides. There could be for example the choice of using a category for sef or stay without category.

Like i said, whether i'm using the "one primary category and multi categories as addition"-system, it's still a workaround.
If the sefurl is the only thing which keep us away from a real multiple categories feature, than the categories should comes first and tiny things like sefurls should be the additional.

shumisha

unread,
Oct 22, 2012, 3:35:07 PM10/22/12
to joomla-...@googlegroups.com
Sorry, there seem to be a misunderstanding.

What I am saying is that the SEF url system does NOT need to change. It will work fine as it is, and will handle perfectly items in multiple categories without any change.
So we do not "need something for the sefurl".
We only need something for the canonical tag. And that's a separate thing, that only requires that an item has a "primary" category selected.

shumisha

unread,
Oct 22, 2012, 3:49:31 PM10/22/12
to joomla-...@googlegroups.com
Hi Mark,


    I may well be missing something important, but I'm not seeing a
    compelling advantage to a hierarchical tagging system.
 
You are right, there are none, and this is why we are not talking about a tagging system.
The initial post was extremely clear: "Can there be a way to have one article belong to multiple categories?"
This is definitely NOT the same thing as a tagging system.


    It would seem
    to be a trade-off between less maintenance (in some cases) vs.
    increased complexity and decreased flexibility.
    In the examples above, with a simple, flat tagging system you would
    just tag an item with all tags that apply to that item.

Yes, and this is exactly why a tagging system is not what the proponents are looking for: tagging with all tags that apply is totally impractical, and error prone, as soon as you have more than a few categories and items.

 
    For example, in shumisha's example above, what if I wanted to be
    tagged as joomla & programming, but not as support? Would this be
    possible? Is it really more work to just click each tag that applies?

Then for such a specific feature, you would use a tagging system. This is where tags and categories are different.
The point here, and this is also comforted by Niels' reference to the ideas site, is that the need for an item to belong to several categories is more common.
To provide background, one of the reason I jumped into that discussion is because 2 weeks ago we had a Joomla 3 discovery and install party for about 20 people, and the Wordpress guys first question was: how do you put articles in more than one cat?
Wordpress does that, so that articles can be displayed from different "access points" without having to tag them in so many different ways.
If you make a quick poll about the first reasons why people use Flexicontent or Zoo, I'm pretty sure putting items in more than one cat would be near the top.


    It still seems confusing to use categories in two completely different
    ways. The current use is analogous to folders, to be used by the ACL
    and when looking at published state.""

If you want to keep that analogy, it happened to me many times, in the non-virtual ages, to put a copy of an item in another folder, as this data really belonged as well to two or more different places. So that I could leave and take the folder with me, with all appropriate data in hand (that's just a far fetched analogy!)


    One benefit of a tagging system (to me at least) is that it is
    completely unstructured and you can tag things with any combination of
    tags that makes sense for that item. I'm not sure that trying to fit
    this into a hierarchy is a good trade-off.

And that is also a tagging system biggest drawback: you have to tag items. That is not what was asked for. It sure would be a bad tradeoff, and I don't even think it could be achieved.
To get back to my example:

Category: /joomla/support/programming -> Mark, Nils, Elin, Victor
Category: /joomla/legal -> Steve, Victor
Category: /joomla/community -> Elin, Mark, Victor

If I want to display a view of people involved with Joomla, using tags, I have to tag:
Mark: 4 times (joomla, support, programming, community)
Nils: 3 times (joomla, support, programming)
Elin: 4 times
Victor: 5 times (joomla, support, programming, legal, community)
Steve: once

On the contrary, if an item can belong to multiple categories, I only have to make:
Mark: belongs to 2 cats
Nils: belongs to 1 cat
Elin: belongs to 2 cats
Victor: belongs to 3 cats
Steve belongs to one cat

All the other categories are inherited, without the need to explicitly list them.

Cheers

Nils Rückmann

unread,
Oct 22, 2012, 3:55:43 PM10/22/12
to joomla-...@googlegroups.com
Ahh, now i understand. Yes thats what i meant. No matter if we use a canonical tag or force a single sefurl. It's of course the same approach.

Niels Braczek

unread,
Oct 22, 2012, 4:20:19 PM10/22/12
to joomla-...@googlegroups.com
Am 22.10.2012 18:54, schrieb Mark Dexter:

> Hi Niels. I'm still not following. In your first example, I would
> think the tags should be "Joomla Supporter" and "Wordpress Supporter"
> so you can keep them separate.

Plus [Joomla Developer] and [WordPress Developer], [Joomla Template
Developer] and [WordPress Template Developer], [Joomla Extension
Developer] and [WordPress Extension Developer], ... Now get the Joomla
people... not possible, especially, if the subcategories are extended to
other contribution types.

> If there is a compelling reason to make tags hierarchical, we could do
> that. Just make it a tablenested table like categories. I'm not
> convinced this is needed, but it could be done.

That's what we have already - it's named 'categories' internally. There
would be no significant difference.

> I can't think of a use
> case where a hierarchical system can do something that a flat system
> can't do, although there could be cases where you could do it with
> fewer tags (hence the other idea of tag groups).

To be honest, that does not really matter. More than 1000 other can. At
least one (Victor) is offering a working solution.

> It still seems confusing to use categories in two completely different
> ways. The current use is analogous to folders, to be used by the ACL
> and when looking at published state. There the current
> one-category-to-many-items makes perfect sense (at least to me).

Think about symlinks. They were introduced, because the folder
limitation does not even work for filesystems.

> As far as the Ideas site, I agree with you that this is very important
> to pay attention to. However, to me the "multiple categories" idea is
> very ambiguous and can easily mean different things to different
> people. So far the only use case I have seen is the tagging idea. So,
> if this is what people on the Ideas site mean by multiple categories,
> then tagging would fit that need.

Tagging is only one (usually less organized) way to categorize things.
Tell me one usecase for tagging, that would not be solved by multiple
categories. I gave you one the other way above.

> I agree that it could be valuable to look at different options for
> this. If someone wants to post some code or a detailed design document
> with what multiple categories might look like, it would well be worth
> looking at and discussing further.

To be honest, I would not invest any hour in code, if chances are so
little as they seem to be now. My time is precious. Victor *has* offered
code, but it is rejected without a look at it.

Mark Dexter

unread,
Oct 22, 2012, 9:15:27 PM10/22/12
to joomla-...@googlegroups.com
Well it seems like the next step would be to come up with a detailed
design and proposal. Perhaps interested people can form a Production
Working Group on the wiki and post a proposed design there?

I don't think I can get my head around this until I see in a lot more
detail what it would look like. Where would the categories be entered?
Would there be one "main" category for each item along with multiple
possible "secondary" categories? What would the UI for this look like?
What would the db schema be? What current component logic would need
to be altered and how?

Thanks. Mark

Niels Braczek

unread,
Oct 22, 2012, 10:42:45 PM10/22/12
to joomla-...@googlegroups.com
Am 23.10.2012 03:15, schrieb Mark Dexter:

> Where would the categories be entered?

In the Category Manager, just like it is now. No difference.

> Would there be one "main" category for each item along with multiple
> possible "secondary" categories?

For articles: yes. For extensions: As you like.

> What would the UI for this look like?

For a single main category, nothing will change.
For the (secondary) multi-category, the basic implementation is a simple
multi-select input control. Templates may or may not add some jQuery
magic to it.

> What would the db schema be?

A simple n:m table. Since different extensions have to be supported, the
columns will be
id // autoincrement value for simple CRUD
category_id // the category id
item_type // a component identifier, like 'com_content'
item_id // the id of the item

> What current component logic would need
> to be altered and how?

1. One new field in the edit form
2. CRUD for the n:m table
3. The logic to retrieve subcategories and items from a category has
to be extended to also look into the n:m table (recursive, since
item_type can be com_categories as well, with a configurable depth
limit).

Did I miss something?

Mark Dexter

unread,
Oct 22, 2012, 11:22:37 PM10/22/12
to joomla-...@googlegroups.com
So the category edit screen for the secondary categories would have UI
to enter ACL information, correct? But this information would be
ignored? Mark

Victor Drover

unread,
Oct 22, 2012, 11:36:14 PM10/22/12
to joomla-...@googlegroups.com
Ignored when the category is selected as a secondary cat. Those params would apply for content that use this cat as a primary/ canonical cat.

Sent from my iPhone

Nils Rückmann

unread,
Oct 22, 2012, 11:47:14 PM10/22/12
to joomla-...@googlegroups.com
Next try:

Why we are using a main category field, if the "main category" is only needed for seo stuff ?
It makes lot more sense for me using one (multiple-)category field and an additional for the sef-url/cononical-url

@Niels: We only need a simple mapping table without item_type, since we have single categories-table which holds the context.

Victor Drover

unread,
Oct 23, 2012, 12:05:33 AM10/23/12
to joomla-...@googlegroups.com
The primary category is required for parameters. If we stop needing a primary category, then we have mass confusion for ACL and such.

And we already have a field to customize the sef url: the primary category alias.

RE: implementation for articles, we've done a very basic one so far for events. 


Would need to be modified for 3.0, and to have a max height (auto-scroll) for sites with lots of cats .

-V

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/urxXWxMs0nMJ.

Nils Rückmann

unread,
Oct 23, 2012, 6:45:46 AM10/23/12
to joomla-...@googlegroups.com

Lately i was thinking about the ACL problem with multi-categories and came more and more to the decision that there isn't really a problem. Today we are using only "create", "delete" and "edit":
  1. If i create an article the ACL is only used by getting possbile categories, so nothing will changed.
  2. If i want to delete an article i have to check if its in a category where i be able to delte something. So instead of getting the permission of one category we will loop through assigned categories.
  3. If i want to edit an article it's the same thing like to delete.

The only thing we need is the assumption that by default it's denied and loop through the categories until he gets the permission (if he gets it). And the best: If he uses only one category per article, ut's the same behavior like now.

So if the ACL isn't a problem i see two others: sef-urls and access.

I don't like our sef-urls generally. But a short soultion could be to use an extra slide/accordion/fieldset for seo related stuff with an option to to use a category for sef-urls. The alias and the meta options could also belongs to that slide/accordion/fieldset.

About the access i want to ask first if there's any approach of changes. Wasn't there something about adding something like "privacy" to differentiate between access to an item and view the item (-intro) ?

Are there more problem which i may overlooked ?

I see no problem with the ACL

Victor Drover

unread,
Oct 23, 2012, 7:47:26 AM10/23/12
to joomla-...@googlegroups.com
Remember, there are other parameters besides ACL, alternative layout for example, as well as access permissions that control who can view or not view an item.

In addition, if extensions have properly extended the categories, there may be many more parameters and expanded ACL also. Again, JCal example:


-V

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/Sy-V4jQt-1sJ.

Nils Rückmann

unread,
Oct 23, 2012, 8:47:09 AM10/23/12
to joomla-...@googlegroups.com
But we can inherit the access permission and other parameters from the categories.
My idea is to use the current/active category to inherit such things. That will allow us for example to have different alternative layouts for the same article. Or even different altenative intro layouts in the same blog view.

Victor Drover

unread,
Oct 23, 2012, 9:47:53 AM10/23/12
to joomla-...@googlegroups.com
I think if you go this route, folks will be too confused. Like, "can i add this as a secondary category? I forget if the permissions are the same in that category".

On Oct 23, 2012, at 7:47 AM, Nils Rückmann <syb...@googlemail.com> wrote:

But we can inherit the access permission and other parameters from the categories.
My idea is to use the current/active category to inherit such things. That will allow us for example to have different alternative layouts for the same article. Or even different altenative intro layouts in the same blog view.


--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/DrZtvm_6CoEJ.

Nils Rückmann

unread,
Oct 23, 2012, 10:59:51 AM10/23/12
to joomla-...@googlegroups.com
They don't need to have the same permissions. And if someone uses different permission on his site he already have to know the persmissions.

I really think that this could be a major step on the way we use the category system, instead of creating a sort of workaround only to get relations, especially if we will have global categories sometimes, which could uses be several item types. I know it's a lot more harder
to implement this, but in my opinion the cms have to change the focus, The cms should give us a base where extensions can build of and not only a collection of features. Examples: Our none or half generic form-templates, which can't be accessed by plugins. Or the half baked profile plugin (which is also related to form-templates), Or the new acl which is based on a non-normalized database structure, what decreases the benefits incredibly.
All these are very cool features, but not really sustainable and more like a quik shot. Btw: This is why i think we should discuss possible features first, and not waiting for code and say yes or no.

goldenmean

unread,
Oct 24, 2012, 11:36:40 AM10/24/12
to joomla-...@googlegroups.com
Vic, I approve of your approach to multiple categories. I would be happy to commit to testing if you are willing to push the update.

Thanks for all your work.

elin

unread,
Oct 25, 2012, 3:14:08 PM10/25/12
to joomla-...@googlegroups.com
What I'd like to suggest is the following.

One person create a wiki page to start and then the people who want to work on this begin writing a list of specifications. That is, define what problem it is you are trying to solve and what a solution would look like: in the data base, in terms of packages in the cms or platform libraries, to search, and to various groups of end users and also make a list of what CMS extensions you would need (a component, some modules, some plugins etc).

Once there is agreement on those things, determine through discussion as a group and on list if you wish what an optimal design approach will be. Remember ... you are writing core code not a workaround solution designed to get around limitations of the core. You are doing the opposite of a workaround. You are attempting to eliminate the need for workarounds. Make it clean, simple, extensible  and performant.

Do some research on how various applications (WP, Drupal, Concrete 5 , whatever) and joomla extensions have approached this.  You might also want to look at the taxonomy summer of code project from a couple of years ago (which was lost in the rush to 1.6 and is a great example of why allowing the platform to move forward independently of whether the CMS is ready to use a package makes total sense). Understand their strengths and weaknesses.  Come to an agreement on what the right approach is and document that for people to comment on. 

Think about the user interface and how it should work both on the rendered page and for people using it, including people on multilingual sites (i.e. should these always be language specific or should the


Elin

ssnobben

unread,
Nov 2, 2012, 7:59:12 AM11/2/12
to joomla-...@googlegroups.com
Maybe also get some input on how Instagram doing with their hash tagging system for photos http://blog.instagram.com/tagged/tips

Usage
http://blog.instagram.com/tagged/photo_feature

Example tag #festivaloflights      http://www.gramfeed.com/instagram/tags#festivaloflights   etc

piotr_cz

unread,
Nov 14, 2012, 4:32:16 AM11/14/12
to Joomla! CMS Development
I really like this implementation, although I think what most end-
users look for is trivial, 1-level tagging system.

My questions/ notes:
Let's say an Item 'Orange' has a secondary category 'Fruits'.

- Viewing access levels
'Fruits' category has Viewing Access levels set to 'Registered'. I
suppose that when Orange item is opened by guests, the tag 'Fruits'
should not be shown?

- Maintenance
Once we delete the 'Fruits' category, it should be removed from all
items that have it also as secondary category.


On Oct 21, 4:12 pm, Victor Drover <ad...@anything-digital.com> wrote:
> Regardless of the tone, Elin is correct. The take home message to me is clear: "Yes, there is a chance it will get accepted." I think that was the crux of the issue originally.
>
> Not sure if my first reply came through, so lets try again:
>
> In the current JCal Pro build, we extend joomla categories to organize events. We use a main or canonical category to control URL aliases and event permissions, and then maintain a separate DB table to cross-reference the events to any number of secondary categories. We use the secondary categories (again, just Joomla categories) only for tagging purposes, thus sidestepping any ACL issues for examnple.
>
> This setup gives us the best of both worlds: we use Joomla's categories and don't need to add a "tag" feature. By restricting all ACL and such to just the canonical category, we don't have any of the complicated ACL issues mentioned earlier.
>
> In any event, we've built it, it works great, and I think it meets all the criteria mentioned earlier in this thread.
>
> Feedback on applying this concept to com_content would be appreciated. If it suits the bill, we'd be happy to submit it.
>
> -V
>
> On Oct 21, 2012, at 10:08 AM, "G. D. Speer" <gsp...@cortech.org> wrote:
>
>
>
>
>
>
>
> > Ouch -
> > Isn't this message a bit harsh and counter productive?
> > I'm not disagreeing with your points - yes code has to be excellent, code cannot be evaluated before it exists, and there are no guarantees even for excelent code.  Yoou have certainly moderated expectations.
>
> > But, this answer is also putting volunteer contributors in a box because it shuts down the conceptual discussion of "if I build it - would it fly?"  I would much rather allow a contributor to get feedback on a concept as to whether it is "directionally correct" and in line with the Joomla Project vision long before hundreds of hours are invested getting to as first draft codeset, only to get the response "it's not appropriate for core" or "there are dependencies you did not know to consider."
>
> > Maybe I'm misreading your tone, but I would rather encourage the dialog and potential new contributions than put high hurdles in their path and put a damper on the discussion, forcing willing volunteers to guess in the dark about the direction of the roadmap at their peril.
>
> > Just sayin,
>
> > ----- Original Message -----
> > From: elin
> > To: joomla-...@googlegroups.com
> > Sent: Saturday, October 20, 2012 7:33 PM
> > Subject: Re: [jcms] Re: Multiple Categories
>
> > Until there is code there is no way to know that it is good enough. That's the fact. No matter how useful the feature is, if the code for it is no good--in fact if it is not excellent-- it cannot and should not go in.
>
> > Everyone plays on the same playing field and no one get a guarantee. If you can't live with that then that's that.  It's no different than being an author or an artist.
>
> > Elin
>
> > On Saturday, October 20, 2012 7:52:34 PM UTC-4, Nils Rückmann wrote:
> > However, for any of this to happen, we need people willing to step up
> > and work on code.
>
> > But willing people should at least know if there's a chance that the code will be adopted.
> > I have great respect for all people who spend hours, days or maybe weeks to code something without the knowledge
> > if the community will accept it.
>
> > That's by the way the reason why i'm asking about the need of a dependency system for extensions (and core).
>
> > --
> > You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> > To view this discussion on the web, visithttps://groups.google.com/d/msg/joomla-dev-cms/-/WdrVYAkGT8sJ.
> > To post to this group, send an email to joomla-...@googlegroups.com.
> > To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
> > --
> > You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

elin

unread,
Nov 15, 2012, 7:51:08 PM11/15/12
to joomla-...@googlegroups.com

elin

unread,
Nov 15, 2012, 7:57:47 PM11/15/12
to joomla-...@googlegroups.com
Jcalpro does not use categories for acl. All assets are directly off of the component asset. Thus using categories as a tagging system is possible though I have not looked at how that plays out for access.
Elin

piotr_cz

unread,
Nov 16, 2012, 4:41:31 AM11/16/12
to Joomla! CMS Development
I understood it that it's using categories just like other components
and additionally secondary categories for tagging, or am I wrong?

Victor Drover

unread,
Nov 16, 2012, 7:48:18 AM11/16/12
to joomla-...@googlegroups.com
The primary category is used for access control.

Sent from my iPhone

elin

unread,
Nov 17, 2012, 7:06:27 PM11/17/12
to joomla-...@googlegroups.com
No it isn't if you. Look at the parent ids in the asset table you will see events are right off the component.

Also check the table class.

Elin

elin

unread,
Dec 23, 2012, 1:30:48 PM12/23/12
to joomla-...@googlegroups.com
Hi,

Mark and I talked a lot about this topic since the last post.  I'm going to give a summary of what I see as the goals for this and why but if you want to skip ahead there is a code link at the bottom.

So I would describe what as wanted as this: 1.  a way of grouping items that allows multiple assignments to the same item and 2. for these things that for simplicity sake I am going to call tags should optionally be able to be nested.  3. It should be easy to make a menu link (or a link in general) that gets all of the items with a certain tag and 4. optimally the tags should be able to apply to any content type for which the developer buys into the system.

Tags are different from what we have in Joomla categories in that: tags are NOT containers for other items meaning the hierarchy of tags end with tags and does not have final leaves that are items like articles.  Items do not inherit anything from a tag whereas with categories items (and other categories) inherit acl and publication status. That is a tag being unpublished or limited to managers does not limit the items tagged with it to being unpublished or to visibility.

Some of the confusion about terminology here I think comes from people looking at WP which has what I call tagegories.  That is it has a combined system with a single table that holds categories, which can be nested, and tags, which can't be nested.  The tags concept came after the categories concept basically because of problems with scaling when there are large numbers of categories, which is why WP encourages users to limit use of categories and focus on tags instead.  Basically WP uses a system for categories that is similar to what we had in 1.5 or what we have for mappings in smart search.  That is it does not use nested sets which is why it doesn't scale very well.

So what I did was to write some code for a new core component to create and manage tags and allow applying tags to the four core content types (though there is no reason that categories and user profiles couldn't be added to the list, but this is just potentially phase one if we decide to go for this).   It definitely is not finished in that some people who are great at JQuery would want to make the ui better especially focused on an easy way to create new tags on the fly when editing/creating and item and I didn't modify layouts to show the tags an item is assigned to (the new layouts system will be good for this), but it's a start.   So if you are interested please take a look and test and give some feed back. 


Elin

Nick Savov

unread,
Dec 23, 2012, 1:51:56 PM12/23/12
to joomla-...@googlegroups.com
Wow, nice job, Elin! :)
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/h1CgsEKc1owJ.

Dmitry Rekun

unread,
Dec 27, 2012, 10:23:38 AM12/27/12
to joomla-...@googlegroups.com
Looks like a very useful and promising feature!

Roberto Segura

unread,
Dec 27, 2012, 1:23:46 PM12/27/12
to joomla-...@googlegroups.com
Did I say I love you???

This is great Elin! I couldn't test it but looks incredible and you did almost all the work.

I'll test it tonight and try to help with the jQuery magic.

Guys please let's help Elin to get this incredible feature tested and merged. We all missed this for years.

Thank you Elin.

elin

unread,
Feb 11, 2013, 3:16:12 PM2/11/13
to joomla-...@googlegroups.com
Hi folks,

There are about 15 people who posted on this thread but so far I only really have testing results from Mark and Roberto.  Can the rest of you please make sure that you don't forget to put comments or test results in the tracker  and also FYI I have some documentation and a small issue tracker going at my repository. Please make sure you are using an up to date version since there have been steady changes and improvements. 


Certainly there are lots of little details to fix and I could really use a Bootstrap person to go over the front end layouts and deal with the classes etc.

Elin

On Friday, December 28, 2012 8:07:19 AM UTC-5, wdburgdorf wrote:
Brilliant! This will be at least as big a step ahead for Joomla as was dropping the strict section/category setup or the ACL. Joomla will become yet so much more suitable for huge sites. I'm getting excited, thinking of the possibilities. The ease of connecting products with articles in a shop. Or connecting images in galleries with articles, news items, users etc. Phantastic.
Reply all
Reply to author
Forward
0 new messages