brandon.w

I have the same problem. Here is the error in the JS console:

TypeError: document.getElementById(...) is null
e.prototype.setDataFromSnippet()
 wp-seo-post-scraper-310.min.js:1
e.prototype.saveSnippetData()
 wp-seo-post-scraper-310.min.js:1
[28]</E.prototype.updateDataFromDOM()
 yoast-seo-310.min.js:2
[28]</E.prototype.changedInput<()
 yoast-seo-310.min.js:2
i()
 yoast-seo-310.min.js:6
j()
 yoast-seo-310.min.js:6
 wp-seo-post-scraper-310.min.js:1:3975

HA! I just tried it and it worked! Can you please add that verbiage to the Settings > Simple Sitemap screen? Thanks!

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 Swifty Page Manager, without relying on the parent/child relationships imposed by WordPress.

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.

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 Nested pages, without relying on the parent/child relationships imposed by WordPress.

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.

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…

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.

I followed the advice in the following thread and it worked for me. But I don’t think I should be messing around in the database like that on a regular basis….

https://www.ads-software.com/support/topic/502-bad-gateway-24?replies=3

Basically, open the ‘posts’ table, then search for the np-redirect. Actually, I added a title called “DELETE ME!” to the links, then sorted the table by modified date so they would come to the top of the list and I could be certain that I was deleting the proper entries.

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.

Not only can I not delete them, but I can’t even set them to be “hidden.” Just try it, then refresh the page. Not hidden, are they? Not deleted are they? Maddening, isn’t it?

Yes, but custom permalinks are not saving properly when used with the “Nested Pages” plugin or with WooCommerce.

I just created a test link (with an actual href) and now it’s stuck, too. How are we to delete these custom links?

I did exactly this, thinking it would be easier than using a privately published page as a folder (containing element for other hidden pages). I didn’t like the way it worked, because I couldn’t add any notes to it (I use the body of the private page for notes – like why it was created or what it’s purpose is).

So, I decided to delete it. But I can’t. It’s “stuck’ in nested view. I want to delete it, but it won’t go away ??

Also – It looks like with the most recent version of Yoast, my original issue has been corrected and the fix mentioned in my original post (which was no longer working) is no longer necessary.

Thus, marking this topic as closed.