Page "PARENT" field not shown if there is any JS error on pageload

[ttodua]

Describe the bug
I've seen that gutenberg blocks heavily depends on JS (unlike old classic editor page), so in case there happens (even plugins or etc) JavaScript issue (can be seen in console), the other javascript commands are (as we know) not executed after that issue. So, this leads to some problems, like not triggering the JS function that creates the PARENT field under page attributes.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'wp-admin/post-new.php?post_type=page'

2. Let's say an error happens in js console (i'm causing example error on screenshot. To say in details, just define add_shortcode('smth', function($atts){echo 'aaa';} ); and you will get Uncaught (in promise) SyntaxError: Unexpected token < in JSON at position 2 )

3. The "PARENT" field doesn't appear

Screenshots
https://i.imgur.com/uRvNnHb.png

• OS: Win10
• Browser Chrome
• latest chrome & latest WP

[ttodua]

i've updated details.

[swissspidy]

I'd say it's pretty good that this is the only missing thing in that case :-)

[ttodua]

is that 'wontfix' ?

[designsimply]

It's not a wontfix but it matters where to fix. If third-party code causes an error that breaks something in the editor (or anywhere in WordPress), the most common advice is to ask the author of that code to fix the error they have introduced.

For a case like this one, which begins very broadly saying all sorts of things are possible to break, a very good start is to look at a specific case. I see that you have done that already, and it sounds like what we need to find out next is whether the parent page selector can be made more resilient and harder to break from the editor side or if this is a case where it's more appropriate to ask that the third-party code be fixed to avoid the problem.

[rogerlos]

I have a client with this issue, which I cannot replicate locally despite having the same plugins installed using the same theme...so it's likely (I guess) that something got saved "sideways" (perhaps a plugin removed a meta field but the data is still in the DB, or a custom field was added and then removed, or...?).

In any case, the console errors themselves in the Gutenberg environment are maddeningly vague and point at minified JS even if script debugging is turned on, so it's virtually impossible to determine what is wrong.

For example, in the above error, which is the same as my client's site shows, logging the actual JSON to the console would immediately pinpoint the error, but that is not done. I had a similar error a week or so ago where I was able to alter a gutenberg error message about a wp.hooks name being "incorrect" to actually list the offending name on an otherwise mystery meat error message, which allowed me to email the plugin vendor and alert them to the issue.

Is there a reason Gutenberg error messages are obfuscated? You literally, in most cases, have the erroneous item right there and could sent it to the console, saving hours of debugging woes, but the most generic message possible is sent in its place.

(If anything, the React debugger extension is even worse. Trying to debug anything in the editor using that is what I imagine mental illness might be like. I've literally been 30 levels deep in a tree where the space available for code is about 20 pixels and still been unable to determine anything useful.)

[waybis]

I'm seeing this also, if you are using the Block Editor, any page content with js errors removes the Parent selection field in Page Attributes for all pages.

[rogerlos]

FYI, in my specific case this is the fault of the "WordPress Google Maps" plugin, but it only happens if you fiddle around with one of the "advanced" features...which is why it failed on the client's server and I could not replicate it locally very easily. The plugin devs echo inline stylesheets on REST pages requests (!) if you do the aforementioned fiddling.

For anyone else trying to hunt down a similar problem, examine the "response" to the /pages XHR request in your browser's network console. There might be a clue lurking there, if you're lucky.

(I'm going to go lay face down on the floor and await the sweet release of death now, having spent a few hours I won't be paid for figuring this out.)

[waybis]

Thanks for the tip @rogerlos , and don't despair, I'm sure your sacrifice will benefit this open source project in some shape or form. Wordpress appears to be going through a renaissance period at the moment, so I expect a lot more things that we take for granted, are going to break in the short term, but will be fixed in the long term.

[rogerlos]

@waybis, good point.

(What I'm amazed at is how aggressive Gutenberg's development has been--for better or for worse--and how staid the PHP side of wordpress is. WordPress cannot even get past supporting PHP 5.x -- "end of lifed" more than a decade ago! -- and give us namespaces and other genuinely useful server-side tools. 5.0 would have been the time to upgrade WP's core PHP requirements, but they punted, and based on comments on trac, honestly I don't think WP will ever move beyond PHP 5.2 .)

[swissspidy]

WordPress cannot even get past supporting PHP 5.x -- "end of lifed" more than a decade ago!

See https://make.wordpress.org/core/2018/12/08/updating-the-minimum-php-version/

[webdeveloperjon]

Going back to the original comments on this topic, we have this, or related issue with the parent page drop-down disappearing, but the JavaScript error is occurring whilst retrieving it. In our case we have 700+ pages, and the editor retrieves the page information using JavaScript from the API in batches of 100, but it fails on request 7, whereupon the server happens to return a 502 error. The JavaScript doesn't handle this bad response or indicate there's been a problem; it fails silently and thus the parent page drop-down is not shown.

Our server side 502 error was due to a plugin function breaking, but regardless of that, there are a couple of issues/suggestions for the editor:

1. The main one is the editor script retrieving the list needs to be more robust and be capable of handling bad responses from the API, regardless of what causes the API error.
   If an error occurs, it should indicate something to the user, rather than, in this case, simply hiding the parent drop-down - which just causes confusion.

2. The API call to get the pages list is returning the full page objects for each page returned, rather than just the fields needed (id and title?).
   The returned objects include page content, tags and other meta data etc, meaning that the server is processing shortcodes and calling other plugins, and generally doing a huge amount of work, increasing the chance of issues. In our case, the example above means we have loaded over 600 pages of full content via the API - just in order to display a list of page titles. Can the JavaScript call the API in such a way that only the required fields are returned? In our case, each request was returning about 1MB of JSON data so costing ~6MB in all, just to display the parent dropdown (which of course, it didn't ultimately do due to the server error)

If this is helpful and further information would help, let me know what's needed.

[aduth]

There's a few too many separate problems and off-topic comments being discussed for this issue to be very actionable in its current state.

To address a few specific:

• The dropdown won't show because it interprets the lack of data (due to the malformed response) as a lack of data
  • Possible action item: Consider some way to present that a failure had occurred in interpreting the response (needs design feedback, duplicate of Present a more specific and descriptive error message when a REST API request fails #10492)
  • Likely overlap with: https://core.trac.wordpress.org/ticket/44534
  • I would consider the above note "but it fails on request 7, whereupon the server happens to return a 502 error" and related tolerance to be included here as well.
• There was previously an issue where errors logged by failed requests would be logged in a way which was not suitable for debugging (redux-routine casts anything to an Error object from a rejected promise. #12375). This was later fixed (Improve castError handling of non strings #13315).
• Request batching should be more consolidated by increasing number of items per request.
  • Duplicate of Increase upper bound used on per_page argument #10881
• The block editor requests more data than it uses
  • Related: Abysmal response time when fetching pages to be listed in page attributes. 2nd try #13618, Performance: Improve the initial loading time and the feeling fo smoothness while typing in blocks. #11782 (comment)
  • This becomes more challenging because it often contradicts with parallel optimizations to reuse fetched data across multiple parts of the UI which each have their own specific data requirements.

[aduth]

To the original issue, this is working as intended: If the editor cannot retrieve the data, it cannot present the data. The various subtleties and implications of this are represented in related issues described in #12930 (comment) .

The block editor requests more data than it uses

• Related: Abysmal response time when fetching pages to be listed in page attributes. 2nd try #13618, #11782 (comment)
• This becomes more challenging because it often contradicts with parallel optimizations to reuse fetched data across multiple parts of the UI which each have their own specific data requirements.

I've spun this off into two separate related issues #15115 and #15114 to serve as directly actionable tasks.