#5034 closed feature request (maybelater)
Impossible to have duplicate category slugs with different parents
Reported by: | snakefoot | Owned by: | |
---|---|---|---|
Milestone: | Priority: | high | |
Severity: | normal | Version: | 2.3 |
Component: | Taxonomy | Keywords: | has-patch close |
Focuses: | Cc: |
Description
I'm using Wordpress as a CMS tool where categories are used as macro level grouping.
Windows XP -> Utilities
Windows Vista -> Utilities
This is no longer possible with WP 2.3, which ignores parent category when testing whether a slug is unique.
Attachments (4)
Change History (56)
#1
in reply to:
↑ description
@
17 years ago
#2
@
17 years ago
Whoops two different taxonomy can point to the same slug, so the situation with link-category and post-category is not an issue.
#3
@
17 years ago
Would it be possible to change the term_taxonomy table so the unique key is
"term_id + taxonomy + parent" ? (Instead of "term-id + taxonomy")
Then would be a matter of correcting the upgrade function, so it would create multiple entries in the term_taxonomy table if several category is has similar name but different parents.
#4
@
17 years ago
- Owner changed from anonymous to ryan
- Priority changed from normal to high
Pinging Ryan
#5
@
17 years ago
Just peeked at some of the category code, and it seems there is some kind of conversion from the taxonomy + terms table to the old category format.
Sadly enough it expects a one to one relationship between the taxonomy and terms table, and gets angry when two different taxonomy entries points to the same term (Just tried to change the unique index to see what happened). It seems to use the id of the term to identify the category, where it probably should use the id from the taxonomy table.
#6
@
17 years ago
In retrospect, we probably should have gone with passing term_taxonomy_id instead of term_id + taxonomy around the API and adding parent to the term_taxonomy keying. But, term_id + taxonomy is what we have. I think we'll have to make new term_ids with unique slugs to work around this.
#7
@
17 years ago
Guess one should be able to change the inner workings of the API, so terms are identified using the taxonomy-id instead. Post-categories, link-categories and tags would use taxonomy-id as their id.
This wouldn't break API's (one can always get a unique term using the taxonomy-id). Though it would change id's for all taxonomy-types (like ids changes with WP 2.3), and plugins will require a new API to aquire the actual term-id.
But it will pretty much require a complete rewrite of all taxonomy code :)
Guess I'm stuck with WP 2.0
#8
@
17 years ago
Btw. WP already makes new slugs when upgrading (avoids duplicate slugs by appending a counter), but not very elegant though will probably be acceptable for most.
#13
@
16 years ago
- Cc janbrasna added
- Component changed from General to Taxonomy
- Keywords category tag permalink slug taxonomy unique added; tags removed
#17
follow-up:
↓ 18
@
15 years ago
- Milestone changed from 2.9 to Future Release
Punting for time and lack of recent activity.
#18
in reply to:
↑ 17
@
15 years ago
Replying to janeforshort:
Punting for time and lack of recent activity.
Should be closed for me as not a bug => wontfix
#21
@
13 years ago
- Cc wycks added
- Keywords needs-refresh added
- Type changed from defect (bug) to feature request
Related: #6211
This is ancient but could really use addressing especially for sites that are multilingual, it kills the permalink structure and causes issues with all the multi-language plugins.
For example words in several languages can be the same ( eg:restaurant) so in a multilingual structure WordPress treats them as duplicates.
/test/restaurant/example ... English version
/test/fr/restaurant/example ... French version is not currently possible in WP!
/test/fr/restaurant-1/example ... Works but is ugly
#22
@
13 years ago
Yep, needing this as well with MarketPress shopping cart, bumping and following.
Although assigned version here is 2.3, I guess it's safe to say nothing has changed with this in 3.3.1?
#26
@
12 years ago
- Keywords dev-feedback added; category tag permalink slug taxonomy unique removed
Attached is the minimum required to attempt this - however, it breaks the list table hierarchy by not showing the dupe terms, etc. If someone blesses this schema change, we can take it from there.
#29
@
11 years ago
- Keywords has-patch added; dev-feedback removed
- Milestone changed from Future Release to 3.7
For 3.7 taxonomy research
#31
in reply to:
↑ 27
@
11 years ago
- Milestone changed from 3.7 to Future Release
Replying to wonderboymusic:
If we tackle Taxonomy in 3.7, this might be a thing
Not for 3.7.
How does this tie into http://make.wordpress.org/core/2013/07/28/potential-roadmap-for-taxonomy-meta-and-post-relationships/?
#33
@
11 years ago
Evil workaround until someone finds this important:
http://someweblog.com/wordpress-custom-taxonomy-with-same-slug-as-custom-post-type/
This ticket was mentioned in IRC in #wordpress-dev by wonderboymusic. View the logs.
11 years ago
This ticket was mentioned in IRC in #wordpress-dev by simonwheatley. View the logs.
11 years ago
This ticket was mentioned in IRC in #wordpress-dev by SergeyBiryukov. View the logs.
10 years ago
#39
@
10 years ago
We have the solution for this which was coded by some specialist consultants, it allows duplicate category paths and also a separate plugin for duplicate taxonomies for WooCommerce and WPEC, no database changes - it uses the core - so very stable. We are moving over to the retail side (digital music which should be interesting) so if anyone wants to talk about handing over the plugins let us know, info [at] serpyre [dot] com.
#41
@
10 years ago
After the unique index has been removed with 4.1.1, then I can correct the slugs directly using the php-dbadmin.
But the query-lookup only looks at the last slug, and gets confused by similar slugs with different parents. The original version checked the hierarchy if pretty permalinks was activated.
I have attached a simple plugin, that performs this parent lookup and fixes the category term_id (category-slug-hierarchy.php)
#42
@
7 years ago
Has there been any update, workaround or temporary way to reuse slugs under different parent terms? There's no alternative that I was able to find anywhere on the Internet. @snakefoot, the plugin doesn't seem to work? did you end up finding an alternative at all? Any help would be greatly appreciated.
#43
follow-up:
↓ 44
@
7 years ago
@bryomedia I have uploaded the plugin that I'm using right now. Because the Wordpress GUI does not allow duplicate category-slugs, then you have to fix the slugs by editing the database directly.
#44
in reply to:
↑ 43
@
7 years ago
@snakefoot , that's correct. I have 2 categories with an identical slug, but which sit at different levels in the hierarchy. But when accessed, both query the same data even though one of them does not have any posts associated with it.
#45
@
7 years ago
@bryomedia Well that is working on my site, as the posted plugin fixes the category-lookup. Instead of just looking at the last part of the URL, then it uses the entire URL to determine hierarchy.
Have the following permalink logic:
Custom structure: /article/%postname%.html
Category base: articles
Tag base:
#46
@
5 years ago
Is this ultimately a duplicate of #5809 that was Was this resolved in WP 4.3?
https://make.wordpress.org/core/2015/06/09/eliminating-shared-taxonomy-terms-in-wordpress-4-3/
#47
@
2 years ago
Duplicate categories still hasn't been fixed, has been there since time began, and probably never will be solved, there is a long answer below but we had to have the duplicate permalink for product categories (and standard categories) designed and integrated in to the build packages.
https://wordpress.stackexchange.com/a/409944/226189
Wordpress is a content system and not really designed for these types of things, you can use the Permalink Manager plugin to make some changes but in the end, it is purely a limitation of the WordPress system, and given Google doesn't like these things it is a limitation (from a business perspective), not a feature as most would try to say (from a developer perspective), and never the twain shall meet.
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
23 months ago
#49
@
23 months ago
- Keywords close added
- Milestone changed from Future Release to Awaiting Review
This ticket was discussed during today's old ticket bug scrub. As a result of the discussion, I'm adding a suggestion to close
this one as a wontfix
or maybelater
because:
- There are a few plugins that attempt to solve this already.
- This feels very risky and time intensive to fix.
- It doesn't really fall under any of the current priorities for the project.
- This doesn't seem to be an issue for a large number of users, failing the 80/20 rule.
- No workable solutions have presented themselves in the post-term splitting times.
I'll leave this open for a few weeks more to allow for anyone to leave any additional thoughts, feedback, or ideas they may have and circle back to close after a period of time.
Even if this one is closed out, discussion can always continue on closed tickets and it can be reopened if priorities or conditions change, or new and compelling potential solutions present themselves.
This ticket was mentioned in Slack in #core by abhanonstopnews. View the logs.
13 months ago
#51
@
13 months ago
- Milestone Awaiting Review deleted
- Resolution set to maybelater
- Status changed from assigned to closed
Based on desrosj's comment and that 10 months have gone by without objection and/or an alternative suggestion, I'm closing this as maybelater
.
If the priorities of the project change and/or a workable solution with a plethera of tests surfaces, this should be reopened.
Guess it is also impossible to have duplicate slugs with different taxonomy. Forexample I have a link category called "news" and I also have a post-category called "news".
But I can see that this is no longer possible with the new database design, and removing these new limitations would require a redesign of the database. And I guess this not something which is going to happen in the 2.3 branch.
Glad that WP 2.0 is kept alive for several more years :)