Ghost: Suggestion: 301 redirects for old post links

[BrianHicks]

This is along the lines of the feature discussed on the roadmap trello board, but with an added wrinkle: I'd like to be able to set a URL that Ghost will listen on to redirect traffic. This is important to me because my old posts (which have been linked elsewhere) have the URL structure /category/year/month/day/title/ and although I can get close with Ghost's date-in-the-permalink setting I'd like to not break everyone's links unnecessarily. So basically, the feature request is:

/development/2014/01/01/blah/ -> 301 /2014/01/01/blah/

It'd also be great if changed post titles/URLs would make redirection links, so as to _never_ break a URL.

It might make sense for this to be an app, but it would certainly help ease the transition of popular blogs coming to ghost.

[novaugust]

Hey BrianHicks, that sounds more like a job for a service like nginx or apache. I actually recently moved a blog from wordpress to ghost, and just added appropriate rewrite and redirect rules for it, like this:

RedirectMatch 301 /blog/\d{4}/\d{2}/([\w-]*?)/?$ http://blog.novaugust.net/$1

That's an apache rule that says "If you get a request for site.com/blog/<year>/<month>/<title>, send them to blog.site.com/<title>"

Or, when I converted my wordpress categories to tags, I added this:

RedirectMatch 301 /blog/category/([\w-]*?)/?$ http://blog.novaugust.net/tag/$1

Seeing as all of this is already accomplishable with a webserver, which is how we recommend running Ghost, I don't think it'll be added in to Ghost itself in any way.

[novaugust]

Feel free to hit me up on #ghost irc if you need help writing those rewrites :)

[BrianHicks]

Yes, this makes sense for running Ghost on a VPS. I, however, am running a slightly patched version on Heroku (which I know you don't officially support yet.) It might also make sense for the redirect to take place in Ghost itself to aid matching the feature on Ghost Pro.

Fortunately for my little blog there aren't too many links that will break and I can set up a 404 page.

Thanks for considering!

[novaugust]

Certainly, and thanks for a good writeup :) The bit about keeping track of a post's urls will be an interesting thing to consider when we implement post versions..
But ultimately, I think redirecting will be something left to webservers/apps.

[ErisDS]

It might also make sense for the redirect to take place in Ghost itself to aid matching the feature on Ghost Pro.

Ghost(Pro) already supports 301 redirects, there's no UI but you can email a list of redirects and the lovely support team will sort you out ;)

[karloscarweber]

That is awesome. Is it possible that I could help out with building this functionality into Ghost. I have never contributed to Open Source and if it's not on the immediate roadmap for the Ghost dev team to build this I would like to do it.

[pedro380085]

+1

[GaryStanton]

This may be a job for the server if you're coming from an external platform, but I feel Ghost should _absolutely_ be responsible for setting up redirects when you change the location of the post via the editor.

Case in point, I edited the 'welcome-to-ghost' post and changed its location, but not before Google found and listed it.
Now it's a 404. It should be a 301 to the new location of that post. This is pretty easy to manage by storing old and new slugs in the database and running all missing content requests though a front end controller.
Please re-open this... it's basic functionality.

[kevinansfield]

This is pretty easy to manage by storing old and new slugs in the database and running all missing content requests though a front end controller.
Please re-open this... it's basic functionality.

@GaryStanton That's a different feature than this issue. We have wishlist where you can make/vote on feature requests, there are a couple of related ideas already:

• http://ideas.ghost.org/forums/285309-wishlist/suggestions/8616571-posts-redirects
• http://ideas.ghost.org/forums/285309-wishlist/suggestions/11501454-404-not-found-redirects

However, this is not as simple as it sounds, if we do what you suggest then anywhere slugs are used in the UI it needs to be able to cope with the possibility of conflicts and management of historic data. What happens if you want to re-assign/delete an old slug? What happens when you want an old slug to point elsewhere completely? Does the user want the redirect be a 301 or 302? How is cache invalidation handled as slugs change? How long should the trail of historic slugs be? How do we prevent user's from shooting themselves in the foot with soft-404 penalties from Google?

All the above complexity needs to be designed, managed and maintained in order to account for an outside use case. In the rare occasions where a redirect is actually desired/warranted it's better to set up individual rules in your web server of choice.

[GaryStanton]

Sure, everywhere a slug can be changed or created in the UI it needs to run through a bunch of functions to check for conflicts and such.
I've rolled this solution on several applications myself... I'd contend that slug functionality simply shouldn't exist in an application unless this side of it has been taken care of, otherwise you're just creating endless 404s every time a user changes a slug. I don't think you should expect the user to handle this server-side, it can become completely unmanageable very quickly.

My usual solution has a function to check for a slug conflict (presumably something like this exists already, lest two posts end up with the same slug) and deletes any records where the 'Old' slug matches our 'New' slug - otherwise you can end up in an infinite redirect.

I can't think of a use case where these redirects should be anything other than 301. If a user renames a slug back, the redirect conflict function takes care of the historical slug, and the redirect from the once new, now old, becomes a 301. 'Permanent' in this context is more about intention than timespan.

I have no experience with NodeJS at all, otherwise I'd have a crack at this myself... I might give it a look anyway. ;)

[harsaharsa]

:+1: for this!