Plugin Author
Aaron
(@aaron13100)
Basically the plugin only redirects if a 404 is detected. So I’m not sure how to reproduce what you’re describing. Do you know how I can reproduce this?
Write a post, put it as scheduled in one hour for example. Then you know what the real URL of the article is but the URL is still not accessible until it is released. And if the URL is similar to the older one, it should not create a redirected link to something older but should check if any article, even scheduled, is in the system.
Simply, you need to have a check for scheduled posts and block any redirection of them.
Plugin Author
Aaron
(@aaron13100)
So I guess what happened was this.
1) someone requested /published-post-b
2) it didn’t exist so they were directed to /published-post-a, which does exist.
3) the post /published-post-be is now published.
4) when a user requests /published-post-b now they will always be directed to /published-post-a, even though /published-post-be is a closer match.
Is that a good summary of the issue?
Since redirects are created and saved automatically, this describes the current functionality of the plugin.
-
This reply was modified 6 years, 11 months ago by
Aaron.
Well, just to be clear:
1. post a was created in the past
2. post b was scheduled to be published in 3 hours (with similar title)
3. someone tried to view the post b but automatic redirect got him to post a
4. post b is always now redirected to post a even after publishing
As I said, you need to have a check with redirection if the post is already in the database, even as scheduled, or not. If it is, it cannot be automatically redirected to some older one because then the new one even after release will not work…
Plugin Author
Aaron
(@aaron13100)
I’m a bit skeptical that a post that exists is being redirected to a different post.
The main redirection functionality of the plugin is that it only listens for 404s.
It registers the listener for template_redirect and then checks for a 404 with !is_404(). If is_404() returns false then the plugin doesn’t redirect. So I think perhaps there is something else going on. Maybe the is_404() method provided by WordPress isn’t functioning properly. Probably what’s more likely though is that there’s some small difference in the actual URL and the requested URL that’s causing a 404, like a trailing slash or something. site.com/contact/ isn’t the same as site.com/contact, for example.
Anyway, we can see some of what’s happening in the debug log if you do the following.
1) Go to Settings -> 404 Solution -> Options -> Advanced Settings Etc -> Debug logging -> [check the box then click Save]
2) Go to the URL that’s redirecting to somewhere when it shouldn’t be.
3) View the debug log: Settings -> 404 Solution -> Options -> Advanced Settings Etc -> View the debug file
4) Copy the last two pages to https://pastebin.com/ and give me the URL that’s created there so I can have a look at the log file. (Do not paste the log file here).
Of course, in all likelihood this will only show us that it’s redirecting from one URL to another and offer no other information. Basically I’m at a loss as of what to do though, because of what I described above about the plugin only redirecting when the is_404() method returns true.
Let me know if you have any other ideas.
thanks
I think you still don’t get it. You can publish the post in the future. Until then the post is still in Draft mode, or rather Scheduled mode. There is clear URL which the article will have but most probably it is not yet fully in the database. I don’t know. But the article is existing, only not published. Just scheduled to be release in a few hours. I don’t know how WordPress works in this case with URLs but of course, normal person without the right to edit or see unpublished post will get common 404. He has no right to see it. BUT the article is there, just not published. So in this case, you cannot automatically redirect even the user gets 404, that is simply destroying the final URL of the article. Simple rule, if the article is existing just not “viewable” by the visitor, you should not create an automatic redirect rule…
Plugin Author
Aaron
(@aaron13100)
I followed your directions with a scheduled post and tried to reproduce this and I wasn’t able to. Please send me…
1) The URL that’s getting redirected, but shouldn’t be.
2) The URL that opens when you’re editing the post and you click the “Preview” link.
I think a similar kind of thing is easy to test by creating a redirect that matches a post exactly, then switching the post from “Private” to “Published” and back. Of course, to test the private post you can use a private browser window so as to not be logged in as admin.
thanks
It’s not about the preview link. There is the final link already created. See here https://imgur.com/a/xxBWLdn
And if you go to that link before the post is published, you get 404 if you do not have the access rights.
Plugin Author
Aaron
(@aaron13100)
So the issue is that you get a 404 for a post that hasn’t been published? I don’t understand what the issue is anymore.
Well, I don’t know what you don’t understand.
1. Post is written and scheduled to be released in 3 hours. URL i.e. http://www.tobereleased.com
2. Someone shares the link to his colleague or on the web.
3. He comes to http://www.tobereleased.com but he cannot get there because it is just scheduled and cannot be accessed if you are not the admin, author or with the correct rights
4. Automatic redirect is created to older post http://www.tobereleased1.com from http://www.tobereleased.com
5. New post is published after 3 hours
6. Someone goes to http://www.toberealeased.com but there is automatic redirect so he gets to http://www.tobereleased1.com
7. New article is not accessible for public and is simply behind the redirect wall
Plugin Author
Aaron
(@aaron13100)
I’m pretty close to giving up on this, but I will try to be more clear in what I’m asking.
Look here https://imgur.com/a/fhWsAKk. It shows you where to click.
1) Open the edit dialog for the post you’re having trouble with.
2) Click the Preview link indicated by the green arrow in the image.
3) Tell me what happens.
Eh. Well… Check this image https://imgur.com/a/TndjVzQ
Preview is one thing and that has nothing to do with the problem. The problem is with the final URL which you can see on our image, number 1. Which means that you can go to that link even now if you have the access rights. The link is working.
But if you do not have the access rights, you cannot get there and get 404 error which then creates the redirection.
We use permalink customizer but that is off for all the new posts and I think that option to edit permalink is part of the core wordpress, if I am not wrong? And that link is making the problem, not the preview link. And if someone from our team is using it on Slack or somewhere else for others to inform that he is working on it, people will click it, then the error appears and creates the wrong redirection.
And, just to make it clear. Articles in Draft are fine, the link is always using preview at the end of the URL. But that is not the case for Scheduled posts. Those are taken as practically published, just not yet. So the URL is also in the database etc.
-
This reply was modified 6 years, 11 months ago by
keengamer.
Plugin Author
Aaron
(@aaron13100)
Which means that you can go to that link even now if you have the access rights. The link is working.
But if you do not have the access rights, you cannot get there and get 404 error which then creates the redirection.
This is the expected functionality of the plugin. When the user gets a 404 they are redirected. If you don’t want an automatic redirect created, please uncheck that in the options.
Yes, I know. But if your plugin would test before creating the redirection if the page does exist (and it does) in the wordpress (database) and exclude URL which exists but not for everyone, that would be much appreciated. Imagine, that there are private URLs or hidden or just for some roles, groups. And if someone else tries to get there and rewrite the real URL to some strange automatic redirection then it simply destroys the link for all the relevant users…
