Problem with generated children page urls
-
Hello,
We’ve been using the plugin on our site for a few weeks now and it worked perfectly, but in the past week, when we add new sub pages, the url won’t include the parent folder name (I hope I’m being clear.. Lets say we have a parent page called “home” and a sub page, or child page, called “kitchen”, instead of getting https://www.site.com/home/kitchen, we get https://www.site.com/kitchen). What may be the problem and how can we get it fixed?
Thanks!
-
Did you manage to fix this? I’m having similar issues. Creating new subpages or moving existing pages to be a subpage does not update the parent page slug in its url.
Yes, we actually just had a problem with the plugin we used. I downloaded a plugin called CMS Tree Page View that fixed it for us/.
Hi we did the test with WP 4.1.1. It has worked nicely. APM doesn’t change the native WP page URL management. The only thing I can see is a conflict with another plugin :-\
I’m having the same problem. Testing this plugin over “Nested Pages” (lots of issues), but when I try to create any new page, the URL defaults to the wrong permalink structure. (It’s using the default “Plain” permalink setting, rather than the one I have set in Settings > Permalink Settings). This renders the plugin unusable for me, as it would require manually changing the URL of every page I create.
@brandon.w Can you confirm if you’re seeing the “plain” permalink when you hover over the view link or whether you see when you actually navigate to the page?
EDIT: Both. Hovering the view link and while editing the page. (I did not actual navigate to the page).
I’ve temporarily moved back to Nested Pages, in the meantime, as I figured out how to solve one of their issues by manually editing my database. But I’ll keep my eyes out for this to be resolved.
@brandon.w I’ve been trying to reproduce the problem without any luck. The one thing I did notice was that if the parent page isn’t published, the permalink for the sub-page doesn’t include the parent page. Any chance you were dealing with an unpublished parent page?
Yes. In Settings > Permalinks, I have it set to “Post name.”
When I create a subpage under an unpublished parent, the URL slug is the “Plain” version (?=123). This is true when hovering over the preview link, in the page edit screen as well as when I navigate to the page.
Upon further testing, the URL slug takes on the proper form of “Post name” after the page has been published. However, this is only true in the page edit screen. When navigating to the published subpage, WordPress attempts to load the “Plain” URL, then redirects to the proper slug name, but shows a 404 not found error. Additionally, the “View” link from the “All Pages” screen still shows the “Plain” permalink when hovering. This is likely due to the OP’s problem with subpage slugs not including the parent page slug. By default, after the subpage was published and “showed” the post name slug, it did NOT include the parent page’s slug.
I tried this same scenario again, this time adding a subpage under a PUBLISHED parent. All of the above is true again, except that after the subpage was published, the URL slug included both the parent slug and the subpage slug. This means that navigating to the published subpage worked as intended. However, the “view” link on the “All Pages” screen still showed the “Plain” permalink when hovering over it, which is wrong.
It appears that this plugin is using a different type of redirect for originally published URLs to the new post name URL. The only evidence of this is that the “View” links always attempt to load the “Plain” permalink in the browser, then it redirects after a second or two to the “post name” version. This is completely unacceptable. It’s almost as if the plugin is not actually changing the original permalink, but rather just adding a 302 redirect from one URL to another (NOT GOOD!).
Hopefully this helps address some issues. In the meantime, I am going back to Nested Pages. I’ve been working with Swifty Pages, as well, which has it’s own set of limitations they are hoping to overcome.
I wish all three sets of authors would get together to make one AMAZING plugin…
@brandon.w The additional info is great. I’ll dig some more.
One thing I can comment on now, just for some background, is about the plain URL. Those always exist “behind the scenes” and always work. Regardless of what permalink settings you have, the plain version can be used to access a page/post/category. You can also see these in the GUID field of your RSS feed if you were to view the source code. It’s how WordPress works. Any time you see a “pretty” URL that’s just WordPress replacing the plain one using the permalink rules you’ve specified. The redirect is automatic and is a facility provided by WordPress.
So when you say the redirect is not good and completely unacceptable, I’m not sure I see it the same way.
However, to reduce confusion perhaps the view link could point to the final URL rather than passing through the plain URL. One possible complication is that if you were to change a parent page or change the status of a parent page, then all sub-pages would need to be refreshed so their view URLs would be correct which might necessitate reloading the whole tree and some people might find that annoying.
My apologies. Thanks for educating me about plain URLs and pretty permalinks. I’m astounded about this. It just seems like WP would want to automatically redirect ugly URLs to pretty permalinks all the time. I digress, though.
With both Nested Pages and Swifty Page Manager, the view links all use the final URL. And an unpublished page (regardless of hierarchy) always uses pretty permalinks, in the page list, in the page editor and for the view links.
Isn’t that also how WordPress functions natively?
I see your point about having to refresh the child pages if and when the parent page changes. But, the other plugins already appear to be doing this, somehow. And let’s face it, if the user is going to change a parent page, they will likely assume it will affect all the child pages, as well, right?
I also use the Custom Permalinks plugin, as well as the Yoast SEO plugin. The nice thing about the Custom Permalinks plugin is that once I’ve manually edited the permalink of a page, it doesn’t change, regardless of the parent/child relationship. So I am free to edit parent URLs using your plugin (or Nested Pages or Swifty) and I don’t have to worry that all my child page URLs are going to change.
Note: I do this in order to have a parent/child hierarchy of my choosing, while maintaining the ability to strip the parent URL slug from the child URL.
Note: I only mentioned Yoast, because it’s meta box on the page editor screen also shows the page’s URL.
In the event that the parent page is PUBLISHED and public, changing it’s URL probably SHOULD affect the child pages, unless the permalinks were customized. However, if the parent is NOT PUBLISHED or it’s private, etc), then there’s a good chance the user is using it as a “folder” and would not want URL changes to propagate to it’s child pages.
Followup: I’ve decided I can no longer use pages or custom links as “folders” because they will appear in the page’s breadcrumb trail, regardless of publishing status.
I wish there was a way to group pages in Advanced Page Manager, without relying on the parent/child relationships imposed by WordPress.
- The topic ‘Problem with generated children page urls’ is closed to new replies.