Symphony.

I just added a bunch of share URLs to articles so people can easily share posts to sites like facebook and twitter. Currently articles are retrieved by the title of a post(mysite.com/articles/my-article-title/), I would like to create a permalink so people can still get to my article even if the title has changed.

I was thinking of just putting the system id at the end of the url as another parameter to the url. So if the article system id is 47 i would have mysite.com/articles/my-article-title/47 so then the articles page would just generate the page based off the system id and leave the title in the url only for SEO purposes.

I was just wondering what you guys think of this approach and if any has done something different.

Hmm that would be a bit tricky. If someone makes a typo when trying to link to another article; its very easy to end up with duplicate content unless you customize your data-source and issue 301s if the my-article-title does not work.

The issue would as well turn up if you had to edit the handle of your article, as Google knows the previous page, the new page would be a duplicate with its own ranking so best is to issue a 301 if you want to change the url.

I think I put the system id before the title to ensure that a title change doesn't stop old URLs working.

… so best is to issue a 301 if you want to change the url.

Would be an interesting idea to create a special title field (extending the core input field) that stores all versions of its content and handles 301 redirecting (by either adding rules to the .htaccess or by doing something more fancy like URL router).

I'm not too sure which way I would go. I'd rather have them in something like URL router. If a url is changed it would add an entry into URL router.

But you could also do maybe something else like if the title & id do not match please redirect this page to the the correct page which is obtianed from this ID (providing that the ID is a valid entry in the related section) In which case would be something completely different to URL router. (obviously this might mean a lot of 301s for non-existing pages)

I like Nils' idea. :-)

This would be a great field/extension idea. My clients have often changed key page names and not realised the navigational consequences.

To bring this old thread up again, I think I found a (quite nice) solution to this problem.

What I do is the following: I use the URL Router extension with the following route: /\/(.*)\/([0-9]*)-(.*)/ which leads to /$1/$2/$3. Then, I construct my URL's like this: http://example.com/articles/322-this-is-an-example-article. Now, because of the rules in the router, this will mean that in the background, the following URL is actually requested: example.com/articles/322/this-is-an-example-article, so I can just filter my datasources with the first parameter, and discard the second one (do create it when creating your page, though).

What's that second param for, you ask? Well, because I want my urls to be clean, and I prefer to return 301's rather than giving the right link in the HTML for caching reasons, I've created a very small event that checks to see if the title is matching the ID (when they are split up like this they are both in the _env variable, so no fancy parsing is needed) and I redirect if they aren't.

So, what this gives me is the following: the URL is very nice from a SEO point of view, I do not need to keep track of previous names for the article, since the ID will point to the correct URL all the time, and it is relatively painless. Also, because the event will not redirect if no page is found with that ID, I get no redirects for non-existing ID's - the datasource takes care of that.

Very creative, and very cool. It even solves the problem of sharing content on the web (speak "2.0", if you like) and changing the title later (which is an issue authors don't keep in mind, most of the time).

I likey. But then, I like anything using the URL Router.

Question: Why don't you just use the URL scheme you are redirecting to? It seems you are just adding a redirection without really earning anything. Or am I missing something?

@Nils, because of a few reasons:

• I prefer my users to be redirected to the correct url, so that if they share it, the context isn't lost. In other words: the visitor is always redirected to the latest URL/title combination, avoiding cases where the title does not match the article at all.
• Having your content in one place is a good thing for google. Sure, I could use the conical url tag for that, but since I like to be able to cache the response as much as possible, a redirect is a lot cheaper than rendering and saving the entire page again.

Besides these reasons, I think it's just good practice to use the things that are designed for this: when the page is renamed, the 301 header says exactly that, so pretty much all computers that understand HTTP can understand what is going on, and do the right thing - even if I choose to switch from Varnish to Akamai or CloudFlare I won't have to change the implementation (much).

I understand your concept. What I don't understand is why you need http://example.com/articles/322-this-is-an-example-article for this. From what I see, you could apply your event logic (and the redirection if the URL doesn't feature the right title) from example.com/articles/322/this-is-an-example-article. I do something similar on my blog when switching languages.

So I'm not questioning the redirection to the correct, updated URL. I'm questioning your starting point: the URL combining id and title that needs redirection under the hood to extract all needed parameters. Think about a wrong title:

• /322-wrong-title redirects to /322/wrong-title internally
• this will be redirected to /322-correct-title
• which will again be redirected to 322/correct-title internally

If you started with /322/wrong-title you'd only have to redirect to 322/correct-title – if the title is correct no redirection would be needed at all.

/322-my-title looks a lot better to me (and probably to Google as well) than /322/my-title, because the latter suggest a hierarchical order which does not exist.