No Parent page option in Gutenberg

Yes, an invalid response would be why the page listing doesn’t appear, so what would be needed to figure out is why you’re getting the invalid response.

When you examine loading the editor in the Network tab, as suggested, you’ll see one of the requests looks like this:

http: //localhost/wp-json/wp/v2/pages? bunch of stuff here

That is the REST API request by the editor to get the list of Pages from WordPress. If that request isn’t getting the right data returned, then no pages appear in the dropdown.

Try loading this URL on your site, only instead of localhost, use your site’s address:

https://localhost/wp-json/wp/v2/pages

Should return a big list of your Pages, in JSON form. What do you get instead?

Hi Otto,

It comes up with a 404 can’t find page error when I try that link. Looking at the network tab the request that matches best what you’ve described is this (localhost instead of my actual site address):

https://locahost/wp-json/wp/v2/pages?per_page=-1&exclude=2150&parent_exclude=2150&orderby=menu_order&order=asc&context=edit

When I look at the response in the network tab it comes up with the list of pages correctly; when I try that actual link the following error message appears:
{“code”:”rest_forbidden_per_page”,”message”:”Sorry, you are not allowed make unbounded queries.”,”data”:{“status”:401}}

Right, you can’t make that request separate from the editor itself because of the lack of the nonce. Still, if you remove the context=edit and the per page =-1 then it should work.

Still, if you see the correct pages in the network tab, them you should see the listing in the editor.

So, maybe some other request is failing. Look at anything with a wp-json endpoint, and see if you can figure out which one is causing the error in the console.

Also, the 404 isn’t good. That request should work, so maybe you have some other plugin interfering, or an htaccess rule, or something blocking that even though it returns data sometimes?

Ok, so the good news is that the original link you sent (/wp-json/wp/v2/pages) is now coming up correctly with the page details. Still no luck on the parent page in Gutenberg though.

Otto, why is this set up using REST instead of loading it serverside on the very first edit call?

@ramon-fincken I didn’t write the code, so I have no certain answer to that question.

But at a guess, one of the purposes of the new editor is to be primarily browser based. It’s a javascript application, essentially. It communicates with the site using the REST API for essentially everything.

The goal is for it to be device-independent. It will be the same editor on mobile devices, tablets, laptops, etc. Having it thus be a static piece of code allows it to be integrated into not just the webpage, but into a mobile app, or a desktop client. All of the code is thus independent, mostly, from the location where you originally get it from.

So, it uses the REST API for everything. All communication, essentially. It could probbaly preload something like that when it’s rendering from a server built page, but it is still a first version, more or less.

In the end, most of the entire WordPress admin experience is going to move towards javascript oriented webapps. It’s the way of the world. All of these familiar and slow interface screens will be going away, over time, because the web app interface is simply better. It’s faster to respond to change. When you move an image around in the new editor, you see it move immediately. It doesn’t need to go to the server and back to re-render the page. If you use a YouTube video block, you see an actual YouTube video. It loads it up right in the browser instead of having you save the link and only seeing the video once you hit the preview button. While some of these things were possible with the old systems, they were mostly hacks, or add-ons if you will. The use of the REST API for all of the administrative interaction with the site brings this to the forefront, and puts it right there. Immediate response.

Admittedly, if your server has limitations on it that block the REST API, then this can be a problem. Some of these limitations have been added to servers since the REST API was introduced a couple of years ago. It’s time for those limitations to be removed, because WordPress will be using the REST API from now on. That’s why it was created in the first place.

I am having similar issue in gutterberg editor related to “Parent page” list. The only error I see is “Use of Mutation Events is deprecated. Use MutationObserver instead. load-scripts.php:3:9644”

I have two languages in my site, and when I edit a page with guttenberg, the Page drop down menu loads with a delay and then it shows pages with only one language, so I cannot choose a “parent page” for a another language.

@skrasii This topic is over 2 months old, and many Gutenberg versions have been released in that time. As such, your problem is very likely not related, and I encourage you to create your own topic, but it sounds correct that you shouldn’t given parent pages for another language, if this isn’t expected you may need to talk to whomever made the plugin you are using for multiple languages.

To avoid needless noise for participants in this topic, I am closing this thread.