and EXCLUDE rewriting when /content/images/ is in the url
It has been working well up to the point we upgraded. Now, every url we give will be written into https://www.domain.com/blog$1/. For some reason, the $1 captured group is not printing.
I have spent a few days trying to resolve this but it looks to me more like a bug than my incorrect regex.
Does anyone have similar experience? Thanks a lot.
However, this configuration wrongly results in a redirection from http://localhost:3001/p/0123/ to http://localhost:3001/http://localhost:8000/preview/0123/.
It makes perfect sense! You’ve written a regex that matches any path in Ghost and redirects it to /blog/[matched path]…
When Ghost gets a request for /blog/article-1 it will automatically redirect to /blog/article-1/ because all urls in Ghost must end with a trialing slash.
Now your regex "^\\/(.*)/$" matches /blog/article-1/ so it redirects to /blog/$1 which in this case would be /blog/blog/article-1/which again matches your regex and so it redirects again. And so on forever.
You need to write a more targeted regex, that doesn’t match things that start with /blog/ - here’s a starting point: regex101: build, test, and debug regex
I thought it was a way to tell Ghost to treat it as a regex. Because, you see, regex patterns are usually contained between two forward slashes. However, my assumptions–mixed with the brief documentation on the whole redirect.json topic–led me to the wrong outcome.
Removing the first slash does route me to localhost:8000, but it does not expand any captured group. Hence, I get redirected to http://localhost:8000/preview/$1/, with a literal $1 at the end of the path.
Yes, I’m using the Admin API. It would have been easier if the posts.read and pages.read methods accepted a uuid as URL parameter, but I got it working nonetheless.
The only missing piece is the redirect rule. Once that falls into place, I could call it a day and maybe contribute with a tutorial. How does one apply for that?
Hi tortoise, your regex reads: match what starts with a slash, not followed by content/images/ (either with or without trailing slash), followed by 0 or more of anything.
With this definition in mind, you can now see why your redirection creates a loophole: when you redirect from /article-1 to /blog/article-1, the latter still matches the pattern. That’s because /blog/article-1 does start with a slash, is not followed by content/images, and is followed by 0 or more characters. Same goes for /blog/blog/article-1, and so on, and so on.
Would you benefit more from using JavaScript to redirect people to the Gatsby preview? Considering the editor would have to have JavaScript enabled then it would be pretty safe to rely on JavaScript to redirect them with a script that executes when someone tries to navigate to a preview
Well, yes, it would work. AFAIK, there are two ways to do so: the first is to edit the {{ghost_head}} and place my script there; the second is to fork a Ghost theme and edit its source code. They both have drawbacks, though. The former is fast and low-keyed, but I can’t keep track of it with, let’s say, Git. The latter is traceable with Git, but it’s cumbersome and time-consuming to set up.
However, if I look between the lines, I can read that redirects.json is currently not an option, is it? So, in the end, the decision must be between those two. Are there other viable options I’m not aware of?
With that reasoning redirects.json is probably the worst as it would have to be tracked in it’s own repo and manually uploaded to your Ghost admin. I have this very small snippet that would redirect the Ghost site to your Jamstack site:
Not really. I’m running Ghost inside a docker container, and I mounted its content directory to a volume inside my repository. This way, I can easily track the redirects.json file.
