Sub-categories - a must

[acalderon]

If enough people want the solution, I can put together a package or instructions on how to modify to gain unlimited sub-category support.

Hi,

I believe that it is obvious that we are interested on the sub-category issue all right. Please, if you put a package or instructions together we will appreciate it.

Thanks.

[robs1412]

Hi guys,

Maybe this helps with the development
http://forum.joomla.org/index.php/topic,47415.0.html
Especially interesting is the component in my latest post there, it´s nested categories 1.0.1

all the best,

Robert

[nikolas]

Do you know if Joomla 1.5 will have mutlicategory function and unlimited sub categories?

[Tonie]

No, it won't have that functionality.

[ccondrup]

but there is better support for sublevel menus (as flat lists etc) and using a couple of techniques you can therefore simulate subcategories

[milstone]

just adding my 2 cents worth (or less due to inflation)

I've been using gallery2 lately.

you can have as many levels of 'albums' as you wish.

such a dream to integrate this freedom of levels, sections, containers with joomla!!!

gallery, joomla for pictures????

This sounds like a good way to go. I don't understand the apparent focus within Joomla/Mambo on an "actual" hierarchical structure. The approach of asset management applications (such as Cumulus and perhaps Gallery as well) seems to be a simple list of assets with the ability to associate assets with one another in an unlimited number of "virtual groupings" (to use a term foreign to the applications discussed). Such groupings are then organized in a hierarchical structure of unlimited levels. It seems that such many-to-many relationships could be added to Joomla without altering the existing db structure. It would ignore the current Sections/Categories model, although the relationships could be made to replicate an existing organization.

I may be too naive. I am certainly inexperienced. But it seems a parallel organization could be implemented quickly with the plan that it would eventually replace the Section/Category/Content item model. I've read all the above and, honestly, the time frame proposed by the developers is too long. There are good reasons for a conservative approach, but the need for more organizational depth is just to great not to implement an interim solution.

However, I love Joomla and its developers anyway!

Dave

[miamiman]

What ever happened to bdparnes's solution?

[darb]

What ever happened to bdparnes's solution?

Don´t know about this solution.. do you have any info?

[TracyDoesPHP]

We just did a large school-related site, and here is how we solved the issue:

The menu structure we needed was this:

School 1
- - 1st grade
- - - - Class 1a
- - - - Class 1b
- - - - Class 1c
- - 2nd grade
- - - - Class 2a
- - - - Class 2b
- - - - Class 2c
etc

School 2
- - 1st grade
- - - - Class 1a
- - - - Class 1b
- - - - Class 1c
- - 2nd grade
- - - - Class 2a
- - - - Class 2b
- - - - Class 2c
etc.

We created sections for each school and categories for each class, like this:
School 1
- Class 1a
- Class 1b
ect

So we skipped the whole 2nd level menu items.

In the menu we solved it like this:

School 1: Displays content section school 1
- - 1st grade: Displays content categories 1a, 1b, 1c (done by multiselect on the menu creation page)
- - - - Class 1a: Displays content category 1a

etc.

Question for anyone who has implemented an workaround similar to this, using menus to get the site to look like it has more than 3 levels while still using only Joomla's standard section and category hierarchy to enter all the content into the site:

How does this affect the breadcrumb navigation that might display on any given page on the site? Forgetting about the content structure of multiple levels of categories and subcategories of the site I am working on, and trying to get it all onto the site using Joomla with only menus, sections, and categories, sounds like it would save me time over setting up my installation to use subcategories. But, if done that way, using the example of torkil's school site, if I were viewing content in the Class 1b category, wouldn't the breadcrumb nav say "School 1 > Class 1b" instead of "School 1 > 1st grade > Class 1b", which is where the user really is in terms of sublevels of the site?

I am trying to figure out whether I should just force my structure into the 1.5 limitations, instead of just hacking it to be a multi-category system, and this is one of the issues I am forseeing with the former. Any thoughts or hints on this would be greatly appreciated.

Thanks.

[TracyDoesPHP]

Question for anyone who has implemented an workaround similar to this, using menus to get the site to look like it has more than 3 levels while still using only Joomla's standard section and category hierarchy to enter all the content into the site:

How does this affect the breadcrumb navigation that might display on any given page on the site? Forgetting about the content structure of multiple levels of categories and subcategories of the site I am working on, and trying to get it all onto the site using Joomla with only menus, sections, and categories, sounds like it would save me time over setting up my installation to use subcategories. But, if done that way, using the example of torkil's school site, if I were viewing content in the Class 1b category, wouldn't the breadcrumb nav say "School 1 > Class 1b" instead of "School 1 > 1st grade > Class 1b", which is where the user really is in terms of sublevels of the site?

I am trying to figure out whether I should just force my structure into the 1.5 limitations, instead of just hacking it to be a multi-category system, and this is one of the issues I am forseeing with the former. Any thoughts or hints on this would be greatly appreciated.

Thanks.

Also, how would this affect SEF URLs? Again, using the school site example, I would want the user to see /School1/Grade1/Class1b/, but wouldn't they see /School1/Class1b/ ?

[mikyatope]

Infinite subcategories are definitely needed, but we also need the ability to tag content items with multiple categories and to have categories with multiple parents (a polyhierarchy). Drupal supports both of these approaches.

I would badly need this Features too, especialy the second one.
There are some workarounds as mentioned above, but they make working less intuitive and efficient. I am glad to hear that the Multi levels are planned! But what about the "tag content items with multiple categories"? Here the only workaround (duplicating item and mantaining 2 copies ).

Michael

This post I quote is from year 2005 ... and the ideas suggested, and functionalities requested are still the same we still need nowadays...

infinite subsections/subcategories and mainly, tags and polyhierarchy in content is THE SOLUTION !

... since those functionalities are not implemented in joomla... the content will be a mess ... creating a lot of section/category groups to overcome the 2 level limitation SUX ...

...joomla 1.5 don't have polyhierarchy and tags??? ... what a pity... we users need more from those functionalities not a lot of security updates...

[mikyatope]

Unfortunately it isn't quite that simple.... It isn't that the implementation is INCREDIBLY hard to do, it is that it would break a large amount of backward compatibility.  Not to mention how closely coupled things like the menu are to the section -> category -> content structure....

Louis

by the way... you are not  saying something new ... that "there is to much work" stuff ...was said in 2005 ... in this thread! ...

... remodelation of the core, of the structure... dificult stuff ... but, wait... that dificult remodelation and so ... it's what has been done with Joomla 1.5 .. isn't it? ... why the content categorizacion stuff have remained untouched ? (due to make only ONE item section... renaming the "static content" to "uncategorized content" )

[Hackwar]

mikyatope, feel free to provide patches for the issues remaining in 1.5, so that we can release the stable and then feel free to provide the patches to implement this feature. I have not earned one single cent with Joomla in the two years I am with this project and the one year that I am part of the developers and you can very well be sure that I invested several hundred hours in september alone into this. It doesn't work faster than this and if you can't live with the answer you have been given, either help out or use another software.

EDIT: And before you say something like "I'm not a dev" (like you did in another thread): even if you are not a coder that is no excuse ... there are lots of open source developers out there who would love to make a living working on open source software to help everyone... if you payed one to spend his time on something like this to benefit everyone, then you would be making a difference rather than just complaining.

[mikyatope]

xDDDD you catched me!

I've no excuse xDD ...I'm sorry I'm not a programmer, I'm a biologist, in programation and open source since only 6 months or so.. I've started learning php to do some retouches in the websites I make... I'm starting to love that world! ..and the day I'll adquire the skills, I'll be the first to colabrate myself. I'm afraid I've no enough money to pay an open source dev.

I've worked in a lot of stuff without being paid (and without describing my personal issues) I know that doesen't feel good when someone appears and seems he is not appreciating all the hard work done...

but I think that you are taking this too personal, and is not

I think it's not smart saying stuff like "if you don't like... use other CMS..." is not what you really want ...I supose..

(and this is copypaste from my other reply)
"It's only that... I'll continue making noise about this issue if necessary. You guys are replying me, that's a sign that you first read me, and that's great for me! it's not like I'm not listened at all... and that's a step more closer that my wish of a feature is taken into account xD don't feel this too personal! ... I'm thinking, and, maybe if I'd started my question with a big congratulations to the people who are making joomla possible, I could continue saying the same that I said, and I'm sure that then, you will be thinking really diferent about me...

there are a lot of people congratulating, you know you deserve the congrats , we all congratulate all of you indirectly using joomla... ok, I'm simply going to say the real thing, not personal "

I'm living without this feature! xDD we all do, I only made a request, I know It won't be done next week only because a single person has requested it... it's only, that we all think , me too, that Joomla is great! but with a few touches, It'll be really THE BEST (that nowadays is nearly to be) and those features I'd say are: The content multicategory stuff, The user managment, and the multilanguage

[ianmac]

"It's only that... I'll continue making noise about this issue if necessary. You guys are replying me, that's a sign that you first read me, and that's great for me! it's not like I'm not listened at all...

Sorry...  I'm reading this out of context, because I don't have time to read the whole thread...  but please get rid of this attitude.

Please think about what you are saying here:
You are saying the equivalent of: "I will continue to make noise if I don't get my way until I become such a pain that people eventually give in"

IMO, this is an extremely rude thing to say in an open source project.  You have seen that this thread exists, this request has already been made.  Feel free to make your request once, but please don't keep pestering.

Ian

[mcsmom]

Mlkyatope, I suggest you watch this and see if you recognize any patterns.


http://video.google.com/videoplay?docid ... &plindex=0

In addition, no one minds constructive suggestions, but there are ways to make them that do not make people dislike you, and indeed they might even thank you. You might want to practice reading your words before posting and think about how other people will read them
Be polite. Be kind. Be constructive.Say thank you.  Contribute in other ways at the same time such as providing answers in the forums as well as making requests (not demands) of developers. This approach will always be to your own benefit as well as the benefit of the project and community.

[darb]

So better to get back on topic about this important key functionality.

Joomla is a open source community where everyone can talk and contribute so that our strengths and our weaknesses.

ANY news from dev group how to solve this and when?  3 years have passed and it should be nice to hear how you think and discuss about this topic.

Using the JNBS from Enno could be a good starting point http://joomlacode.org/gf/project/soc2007/ It would be good to see a road map when this could be implemented now so ppl can help and contribute.

Suggestion: make a common effort/push to promote this important steps on implementing this as soon as possible.

I don't think this will be easier the more you wait to implement it for v 1.5 right?

I just believe everyone is very interested to hear and get info about this....

This kind of mapping with tags, hiarachies, sub categories and other unlimited nested structures are very nice when building a comprehensive site. Just saw this french site http://www.viafrance.com that answer the questions when, where and how. How should you solve that with joomla ?

[ianmac]

Do you know if Joomla 1.5 will have mutlicategory function and unlimited sub categories?

No, it won't have that functionality.

Ian

[rdillman]

Its disappointing to hear that 1.5 won't have multiple category support for stories.  This is one of the major drawbacks of using Joomla for blogging instead of Wordpress.

[ianmac]

Sure...  this is a feature that many people want, but for b/c reasons we couldn't put it in 1.5.  I'm surprised that nobody has released a good third party component that would switch out the base com_content.  The framework is now built in such a way that com_content doesn't get much special treatment, and therefore could easily be replaced.

Ian

[mouloud]

Hey everybody,
I'm considering paying a developper to add this feature for me. So I was wondering if you have already begin to think about the way to implement this, so I can begin the work in the same way, and maybe propose a patch.
The way I see it :
It should look like exactly as a directory structure, like a static web site. Why ? Because it's a way of thinking that everybody is used to, and specialy google.
So it would be an inifite nested directories and documents, with the possibility to specify an "index.html" content for any directory.
And of course, it should reflect in the url.
How to do this in Joomla :
- a Category manager, where we can create/move/delete categories
- a single menu "category" in com_content, and may be in other content components, to choose the category for this document.
- a modification of the router to create some beautifull url like http://www.mysite.com/products/computer ... ewone.html

As you can see, it's a very basic way : no description of category, no content in multiple category. Just the old school web site behavior, you remember ? when you have to create directory and subdirectory, and put htmls files in it ? I can't see a best way to organise information. And google agree with me.

So if I developpe a plugin like this, do you think it will be compatible with the way you will insert this in 1.6 or 1.7 ? Or do you see it in a completely different way ?

Thanks a lot.

[Hackwar]

you might want to take a look at the google soc project JNBS.

[mouloud]

Ok thanks.
Just a link to that, in case anybody else is interested :
http://code.google.com/soc/2007/joomla/ ... 56012D833B

[endi]

I'll add my not-that-useful contribution to this, since I consider this feature a crucial one too.
I have something to say about backwards compatibility: I don't completely get the point.

• DB backwards compatibility was never even desired, indeed I think I could not run a 1.0 installation upon a 1.5 database, or vice versa. This is perfectly normal, and a wonderful migrator component was written to perform the needed conversion.
• File backwards compatibility does not even make much sense. The core files are very different, I'm not sure whether 1.0 templates can be installed on 1.5 and it would be pointless too, because removing all hardcoded HTML output was one of the key features in 1.5 developement.
• URL backwards compatibility, too, does not exist. Non-SEF URLs are generated from database id's, which (I think) may change in the migration process. SEF urls are totally different, and better. But anyway, there is backlinks for that, right?
• API backwards compatibility was, too, broken. you cannot run a 1.0 component on 1.5 without the legacy plugin. And not all of the old components do run with it, either.

So, we don't have backwards compatibility from 1.5 towards 1.0, we just have backlinks, migrator and legacy to ensure it. And apparently it works like a charm. So why bother about backwards compatibility?

Now here's my point: if JNBS was merged into the trunk, then how hard would it be to make some new migrator convert old sections into level-1 nodes and old categories into level-2 nodes? I think this would be the easy part of the work, changes in the core would be much, much harder.
So, let's stop bothering about backwards compatibility... it is a minor issue, and can be obtained (relatively) easily.

This seems too easy: I must be wrong. But how?
cheers

Andy

[ianmac]

I'll add my not-that-useful contribution to this, since I consider this feature a crucial one too.
I have something to say about backwards compatibility: I don't completely get the point.

• DB backwards compatibility was never even desired, indeed I think I could not run a 1.0 installation upon a 1.5 database, or vice versa. This is perfectly normal, and a wonderful migrator component was written to perform the needed conversion.

DB backward compatibility is necessary so that many third party extensions will work.  Especially modules that operate on the content table, and other tables that third party extensions make use of.

• File backwards compatibility does not even make much sense. The core files are very different, I'm not sure whether 1.0 templates can be installed on 1.5 and it would be pointless too, because removing all hardcoded HTML output was one of the key features in 1.5 developement.

File backwards compatibility has been dropped to an extent.  You will see some files around that basically point to their 1.5 equivalents.  1.0 templates can be installed on 1.5 and many people do find this very useful, from what I understand.

• URL backwards compatibility, too, does not exist. Non-SEF URLs are generated from database id's, which (I think) may change in the migration process. SEF urls are totally different, and better. But anyway, there is backlinks for that, right?

URL backwards compatibility does exist via the backlinks plugin.  All URLs are generated by whatever the extensions passes to the Joomla! core URL generator.

• API backwards compatibility was, too, broken. you cannot run a 1.0 component on 1.5 without the legacy plugin. And not all of the old components do run with it, either.

The legacy plugin is there for backwards compatibility purposes.  While some extensions do not work on 1.5, many do, and this is because the API is backwards compatible.

So, we don't have backwards compatibility from 1.5 towards 1.0, we just have backlinks, migrator and legacy to ensure it. And apparently it works like a charm. So why bother about backwards compatibility?

We do have b/c via these three items.  Note that much work was done so that these things could be possible with the new framework.

Now here's my point: if JNBS was merged into the trunk, then how hard would it be to make some new migrator convert old sections into level-1 nodes and old categories into level-2 nodes? I think this would be the easy part of the work, changes in the core would be much, much harder.
So, let's stop bothering about backwards compatibility... it is a minor issue, and can be obtained (relatively) easily.

Backwards compatibility may be a minor issue for you (and I really could care little about it either), but there are many people who do need backwards compatibility, and this feature was a design goal from the start.  It can be obtained easily with the extensions that we have because we have maintained, for the most part, the same database.

Ian

[endi]

Ian,

thanks a lot for your kind reply. Indeed, my post was meant for me (and possibly other readers?) to better understand the matter. Unfortunately, not being a professional coder, I don't have time to find the answers alone ...

So, do 3p extensions access the #__categories table directly (isn't this approach deprecated?) or is there any API which could be adapted via some compatibility layer like legacy?

And after all, all my thoughts flow into one big obvious question:
Are we likely going to have a real tree structure (possibly hardlinked nested sets) in 1.6?

I really, really wish I had the time to dig into the code and contribute personally... someday soon, i hope...

[mouloud]

you might want to take a look at the google soc project JNBS.

So I looked in google summer of code, and I'm not sure it answer to my question. Not sure because my english is not perfect, and because I didnt' understand well how google code work.  ???
At first, were you talking about the project I put the link "Extending the Nested Sets Model with "Hardlinked Nested Sets""
If yes, as I understand from the title, it talk about extending the nested sets model, with a feature I'm not interested in, and not about creating this nested set model (if I understand good this expression), which is laking in joomla 1.5. Am I right ? Or does the hardlinked nested set the way you choose to integrate sub-categories in joomla ?

Thanks, and sorry for my poor understanding.

[mouloud]

I found what is the Nested Set Model :
http://dev.mysql.com/tech-resources/art ... -data.html
It's very interesting, even if it's a little headheacking 
So my question is : is this the method you choosed to implement subcategories in Joomla ?
I can undesrtand the backyard compatibilty would be a bit more complicated than with the usula parent_id system...