but people are stuck with bum slugs forever, that kind of sucks.
They can always rewrite via nginx.
And honestly, who deep links to the category topic list pages? NONE of the topics in the category would be affected since they don’t have category in their URL.
also, reparenting is not resolvable, eg: a subcategory moved from one parent to another, admittedly an edge case, but not resolvable
It looks like the tagging plugin has a more severe case here: eg:
people totally suck at tagging and renaming tags is not too much of an edge case.
I’d argue we should just prevent renaming tags after a certain amount of time – create a new one if a different tag is needed.
Yes, allowing users to change usernames willy-nilly is asking for trouble. It should always require admin involvement.
However, when I said there are sometimes valid reasons for changing their usernames, I’m not speaking as a n00b forum admin. It does happen.
For example, I own a forum for professionals in a particular industry to shoot the breeze about their jobs, their employers, politics, etc.
Every so often someone who’s been using his/her real name decides they don’t want their old posts attached to their Google profile. They don’t mind if I and the other forum users know who they are, but they just don’t want a potential employer rejecting their resume because of their political leanings or because of a crass joke. So they want their username changed and all past posts attributed to their new username. Sure, their content is on archive.org under their old name, but most of their potential employers aren’t tech savvy enough to go digging there.
Is it a valid reason to change a username? Depends on how you choose to admin your community. Personally, I’ve got no problem honoring these requests.
Is it an edge case? Yes.
Does it happen in real life? Yes, a few times a year for a community with ~15K members.
Is it a big deal? No, it only happens a few times a year.
In general though it seems short-sighted to me to go for squeaky-clean urls at the cost of flexibility.
If I change the category names, I’m going to change the slug as well–who wants a slug that doesn’t actually match the name?
When I migrated that other site, I had multiple inbound links from other sites pointing at specific boards (equivalent of categories) but using different variations on the name. Clearly the prior owner had changed the name of some of the boards more than once. Thankfully, the urls including a board ID so it was easy to redirect everything properly at the Nginx level without having to hit a mapping table.
What do you gain by excluding the tag ids? How much cruft does it really add to the url to include a cannonical ID?
If the choice were between domain.com/tag/cute-tag-name versus domain.com/tag/funky.aspx?#255p0jࢻ&US&3242341 then yeah, I see your point.
And I do agree going domain.com/content_type/content_id/content_title/ is ugly–the number in the middle of the words is like a rude interruption to the reader. But appending the content_id at the end seems fine to me.
Sorry to revive this, but I want to try to re-raise the use case.
We do, for one. Now that we have nice category logos, backgrounds, custom colors, etc., the category page can be a pretty nice landing page for someone to come to a focused area of community discussion.
I went to rename a category and then realized I’d be stuck with such a bum slug for this very reason. Both for our main parent category and the sub-categories.
I believe you can set up manual arbitrary redirects in Admin now, that’s something @techapj worked on.
I would think that we could lean on the work that @tgxworld did for the category tagging feature to address this feature.
- plugin - Discourse Meta goes to plugin - Discourse Meta
- https://meta.discourse.org/c/foo/bar/22 also goes to plugin - Discourse Meta
- https://meta.discourse.org/c/foo/bar/34 goes to https://meta.discourse.org/c/plugin/broken-plugin/34
Discourse Meta goes to https://meta.discourse.org/c/plugin/broken-plugin/34
(EDIT this last one works when you click on it, but not if you type it into the address bar)
How does one determine a category ID? I’m trying to use the permalink UI but can’t figure it out.
i.e., Trying to redirect my bum slug topic list to the new ones –
You can grab the ID from categories.json, search for e.g.
That worked. Thanks!
But I find it interesting that subcategories are not listed in categories.json … any reason why?
Category and sub-category IDs can be found at
/site.json – https://meta.discourse.org/site.json
Paste the output from above URL to http://pro.jsonlint.com for better JSON formatting.
We’re constantly moving and renaming categories, which then breaks the link for that category. In Zendesk, if an article is created and then later renamed, it will automatically redirect to the new URL. Atlassian Confluence does something similar when a page is renamed.
Originally, the URL for one of our categories was http://forums.docker.com/c/commercial-products/ucp. We then renamed “Commercial Products” to “Docker Datacenter” and the URL changed to UCP - Docker Forums. Unfortunately, we hardcoded this link in some of our collateral.
It is possible the act of renaming the category could cause a new redirect permalink to automatically generated… @techapj can you add this to your list?
The trigger event is “rename of category”, then follow the usual code paths as if the user manually entered a permalink to direct the old category URL to the new one.
Note, renaming topics works fine, this is just for the narrow case of renaming categories, agree that a redirect here can help. Another option is including the category id in the URL something I personally prefer.
Okay, this is now done via:
Changing the category slug will now automatically create a permalink to redirect old category slug to new category slug.
That sounds cool. What happens if there is already a permalink with that name? (Due to a spate of superfluous renaming, perhaps.)
This was one of the first things I also wanted to check.
Looking at the tests one is called “
deletes permalink when sub category slug is reused” - it would appear this case is handled by deleting the existing permalink.
Does anyone know exactly how to delete the redirects for the ‘burned’ slugs. I did a few renames for new categories and now I can’t change the slug to the desired name, it’s stuck with the old slug, it gives me a 500 error. Help would be appreciated!
Edit - Nevermind! I found the solution by going to
/admin/customize/permalinks and deleting the unwanted rules.