Could you check if the issue persists also if the plugin is temporarily deactivated?
I have analyzed the HTML source of the linked page. The problem you are experiencing is not in the plugin, but rather the way the “relative” links work.
To put it simply, if you use a relative link “nalogovye-spory” on a subpage “yuridicheskoe-soprovozhdenie-organizacii“, the final URL will be relative NOT to a root (home page URL):
www.new.gorodprava.ru + nalogovye-spory ==> www.new.gorodprava.ru/nalogovye-spory
but to the specific subpage you are currently on:
www.new.gorodprava.ru/yuridicheskoe-soprovozhdenie-organizacii + nalogovye-spory ==> www.new.gorodprava.ru/yuridicheskoe-soprovozhdenie-organizacii/nalogovye-spory
Therefore, if you want that link to be relative to the home directory and therefore lead to “www.new.gorodprava.ru/nalogovye-spory”, you need to change it from:
Check out the comment below for more details. Although, it uses files as example to illustrate the general idea, but the concept applies also to the directories:
I have just deleted nalogovye-spory.svg, so there is no attachment page with the same name/slug as a common page. And the предприятиями link works as expected being in href=”” as it was, nalogovye-spory, not ../nalogovye-spory
So problem does seem to be like the plugin cares about attachment pages and it is not clear how to turn this feature off.
- This reply was modified 1 month, 1 week ago by bonmot.
I see, but this is not related to my plugin. I will try to explain it in detail, how it works.
Firstly, if you hover on the link, you will see how the browser parses that relative link:
The relative “nalogovye-spory” is dynamically converted to “https://www.new.gorodprava.ru/yuridicheskoe-soprovozhdenie-organizacii/nalogovye-spory“.
Now, if you click it, the browser will try to load that full URL (that is apparently not correct):
The problem here is that there is no page using that specific URL, so WordPress will extract the slug from that URL and try to find any content item (attachment, page) that uses the same slug:
That is why, you were redirected to the attachment page (before you removed it), as that attachment was the closest match. It works somehow, now because WordPress automatically redirects that incorrect URL:
Please note that this redirect is not a part of my plugin, but included within the WordPress core canonical redirect:
- This reply was modified 1 month, 1 week ago by Maciej Bis.
If I put add_filter( ‘do_redirect_guess_404_permalink’, ‘__return_false’ ); into functions.php, then the plugin seems to stop working. At least the предприятиями link then starts to lead to 404. But going to attachment page is still there – clicking on штате link brings to the page of the corresponding attachment.
If I put remove_action( ‘template_redirect’, ‘redirect_canonical’ ); into functions.php, then the plugin seems to stop working. At least the предприятиями link then starts to lead to 404. But going to attachment page is still there – clicking on штате link brings to the page of the corresponding attachment.
If I put remove_action( ‘template_redirect’, ‘wp_old_slug_redirect’ ); into functions.php, then it changes nothing.
What then the selected Media checkbox in Tools –> Permalink Manager –> Settings –> Exclusion settings –> Exclude content types is supposed to do?
All in all, there is something pretty awful about links handling in WordPress. Before trying Permalink Manager Lite, I have tried to remove parent slugs by myself, no plugins. I have removed then all right, but could not figure out how to make WordPress to go to the new URLs, not to 404.
And nobody seems to know how to solve it:
There are two problems here. One of them is related to the WordPress canonical redirect, while the other is not.
I will try to go over them once again, so some of the information may be repeated, but please take the time to read and analyze everything carefully.
#1 Relative URLs:
To clarify, the first problem is that you use the relative URLs instead of absolute ones.
As I explained earlier, this may to seem correctly at the first glance, but because this URL is relative, the browser will convert this relative URL to absolute one. You can clearly see this final URL if you hover that link:
As long as the link is “nalogovye-spory“, the browser will convert it to incorrect URL (with parent slug included):
This has nothing to do with WordPress or Permalink Manager, this is how the relative links are parsed by browsers. There is really no other option than:
- changing that link to full/absolute URL:
- changing the base inside link to root URL (two dots):
- adding the base tag to <head> section:
<base href=”https://www.new.gorodprava.ru” />
#2 WordPress & Permalink Manager
Actually, you have managed to remove the parent slugs from the child pages. It seems that you have also adjusted the plugin settings, because now I see that the plugin’s redirect is working as intended:
For instance, the new permalink for “Налоговые споры” seems to be correctly changed from:
Now, whenever a visitor tries to open the original URL (the one with the parent slug), Permalink Manager will automatically redirect it to the canonical custom permalink (the one without the parent slug).
- This reply was modified 1 month, 1 week ago by Maciej Bis.
1) End users tend to be inconsistent. So you can not rely on them to be as strict as always use only relative or only absolute URLs. Dots and slash even worse – sooner or later they will use one dot or three dots or forget to add a slash. No, it has to be foolproof.
2) Base tag in head seems to be the most viable solution. But for some reason I do not see it used often in WordPress. Is it not against some de-facto rules in WordPress world? What does your experience tell here, is it a safe enough solution? Is it not going to break something some time later?
Based on my own experience, WordPress’s WYSIWYG editor is more popular among new users who are not familiar with HTML because it automatically creates absolute URLs when a page is selected from the dropdown list.
Most people find this straightforward, however as you noted, there is still a way to get around it and still enter an incorrect or relative URL.
The base tag is widely supported by all browsers and unless it changes, this should work flawlessly.
It is not widely used, because in WordPress ecosystem the relative URLs seem to be rarely used.
- You must be logged in to reply to this topic.