WordPress.org

Make WordPress Core

Opened 13 months ago

Last modified 9 months ago

#45341 new defect (bug)

WSOD when editing a page with define( 'SAVEQUERIES', true ); set in wp-config.php

Reported by: timhibberd Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.0
Component: Editor Keywords: close
Focuses: Cc:
PR Number:

Description (last modified by dd32)

WSOD when editing a page (Issue introduced between v5Beta3 and v5Beta4)

[1542177584  ] PHP   7. trigger_error() /var/www/wordpress/wp-includes/functions.php:4112
[1542177584  ] PHP   6. _deprecated_hook() /var/www/wordpress/wp-includes/plugin.php:629
[1542177584  ] PHP   5. do_action_deprecated() /var/www/wordpress/wp-admin/includes/post.php:2210
[1542177584  ] PHP   4. the_block_editor_meta_box_post_form_hidden_fields() /var/www/wordpress/wp-admin/includes/post.php:2066
[1542177584  ] PHP   3. the_block_editor_meta_boxes() /var/www/wordpress/wp-admin/edit-form-blocks.php:394
[1542177584  ] PHP   2. include() /var/www/wordpress/wp-admin/post.php:160
[1542177584  ] PHP   1. {main}() /var/www/wordpress/wp-admin/post.php:0
[1542177584  ] PHP Stack trace:
[1542177584  ] PHP Notice:  edit_form_advanced is <strong>deprecated</strong> since version 5.0.0! Use block_editor_meta_box_hidden_fields instead. This action is still supported in the classic editor, but is deprecated in the block editor. in /var/www/wordpress/wp-includes/functions.php on line 4112
[1542177584  ] PHP Notice:  edit_form_after_title is <strong>deprecated</strong> since version 5.0.0! Use block_editor_meta_box_hidden_fields instead. This action is still supported in the classic editor, but is deprecated in the block editor. in /var/www/wordpress/wp-includes/functions.php on line 4112

Attachments (2)

WSODWPV5Veta4Edit.png (383.3 KB) - added by timhibberd 13 months ago.
WSODWPV5Beta4Edit-NoPluginsEnabled-twenty12Theme.png (137.2 KB) - added by timhibberd 13 months ago.

Download all attachments as: .zip

Change History (28)

#1 @timhibberd
13 months ago

Clarifying the version is: 5.0-beta4-43896

#2 @dd32
13 months ago

  • Description modified (diff)
  • Keywords reporter-feedback added

Hey @timhibberd,

Unfortunately the error message you've included doesn't really identify the problem you're experiencing, although it does help point in the direction.

My assumption is that it's related to a specific plugins metabox registration that is causing the problem - are you able to disable them and re-enable one-by-one to find out what plugin is causing the issues?

Additionally, Are there any errors showing up in the Browsers Javascript Console?

#3 @timhibberd
13 months ago

Cheers for the quick response @dd32 . I switched the theme to Twenty12 and disabled all the plugins. Still WSOD. See attachment WSODWPV5Beta4Edit-NoPluginsEnabled-twenty12Theme.png.

PHP Errorlog is:

[14-Nov-2018 07:45:52 UTC] PHP Notice:  edit_form_after_title is <strong>deprecated</strong> since version 5.0.0! Use block_editor_meta_box_hidden_fields instead. This action is still supported in the classic editor, but is deprecated in the block editor. in /var/www/wordpress/wp-includes/functions.php on line 4112
[14-Nov-2018 07:45:52 UTC] PHP Stack trace:
[14-Nov-2018 07:45:52 UTC] PHP   1. {main}() /var/www/wordpress/wp-admin/post.php:0
[14-Nov-2018 07:45:52 UTC] PHP   2. include() /var/www/wordpress/wp-admin/post.php:160
[14-Nov-2018 07:45:52 UTC] PHP   3. the_block_editor_meta_boxes() /var/www/wordpress/wp-admin/edit-form-blocks.php:394
[14-Nov-2018 07:45:52 UTC] PHP   4. the_block_editor_meta_box_post_form_hidden_fields() /var/www/wordpress/wp-admin/includes/post.php:2066
[14-Nov-2018 07:45:52 UTC] PHP   5. do_action_deprecated() /var/www/wordpress/wp-admin/includes/post.php:2210
[14-Nov-2018 07:45:52 UTC] PHP   6. _deprecated_hook() /var/www/wordpress/wp-includes/plugin.php:629
[14-Nov-2018 07:45:52 UTC] PHP   7. trigger_error() /var/www/wordpress/wp-includes/functions.php:4112
[14-Nov-2018 07:45:52 UTC] PHP Notice:  edit_form_advanced is <strong>deprecated</strong> since version 5.0.0! Use block_editor_meta_box_hidden_fields instead. This action is still supported in the classic editor, but is deprecated in the block editor. in /var/www/wordpress/wp-includes/functions.php on line 4112
[14-Nov-2018 07:45:52 UTC] PHP Stack trace:
[14-Nov-2018 07:45:52 UTC] PHP   1. {main}() /var/www/wordpress/wp-admin/post.php:0
[14-Nov-2018 07:45:52 UTC] PHP   2. include() /var/www/wordpress/wp-admin/post.php:160
[14-Nov-2018 07:45:52 UTC] PHP   3. the_block_editor_meta_boxes() /var/www/wordpress/wp-admin/edit-form-blocks.php:394
[14-Nov-2018 07:45:52 UTC] PHP   4. the_block_editor_meta_box_post_form_hidden_fields() /var/www/wordpress/wp-admin/includes/post.php:2066
[14-Nov-2018 07:45:52 UTC] PHP   5. do_action_deprecated() /var/www/wordpress/wp-admin/includes/post.php:2210
[14-Nov-2018 07:45:52 UTC] PHP   6. _deprecated_hook() /var/www/wordpress/wp-includes/plugin.php:629
[14-Nov-2018 07:45:52 UTC] PHP   7. trigger_error() /var/www/wordpress/wp-includes/functions.php:4112

#4 @Chouby
13 months ago

I was about to open a ticket about these 2 PHP notices. Reproducible on a fresh install with WP5.0-beta4-43896 (only the beta tester plugin is active). I don't reproduce the WSOD though.

#5 @timhibberd
13 months ago

Were you using release 5.0-beta4-43896 or a newer nightly release?

Version 0, edited 13 months ago by timhibberd (next)

#6 @Chouby
13 months ago

Twenty Nineteen but this doesn't matter. The bugs are inside WP. The 2 actions are used by the core without testing which current editor is in use.

add_action( 'edit_form_advanced', array( $this, 'maybe_run_ajax_cache' ) );

in class-wp-embed.php.

add_action( 'edit_form_after_title', array( 'WP_Privacy_Policy_Content', 'notice' ) );

in admin-filters.php.

#7 @timhibberd
13 months ago

@Chouby - I asked about which theme you used not related to the bugs which, as you observed, are in the core but rather I asked because you said "I don't reproduce the WDOD though". I retried on my install using Twenty Nineteen and still get the WSOD. Actually it's not your traditional php-based WSOD. All the page information is being delivered but is triggering fatal Javascript errors so the page is not being displayed(see attachments). I updated to the latest release 5.0-beta5-43907 and the problem is still there. Still getting WSOD.

#8 @timhibberd
13 months ago

  • Keywords dev-feedback added; reporter-feedback removed

This is still an issue in 5.0-beta5-43908.

#9 @timhibberd
13 months ago

This is still an issue in 5.0-beta5-43909

#10 @timhibberd
13 months ago

This is still an issue in 5.0-beta5-43933

#11 @timhibberd
13 months ago

This is still an issue in 5.0-beta5-43939.

editor.js:14135:1

 TypeError: external_this_wp_components_ is undefined
this.wp.editor<          http://localhost:32778/wp-includes/js/dist/editor.js:14135:1
__webpack_require__      http://localhost:32778/wp-includes/js/dist/editor.js:21:12
this.wp.editor<          http://localhost:32778/wp-includes/js/dist/editor.js:85:18
<anonymous>              http://localhost:32778/wp-includes/js/dist/editor.js:2:11

#12 @timhibberd
13 months ago

Actually, I get different javascript errors depending on which mechanism I use to open the page:

1) Edit in place from the page list
2) Edit in place from the Toolbar
3) Edit using right-click-open-new-tab from page list
4) Edit using right-click-open-new-tab from the toolbar

The most reproducible path to a WSOD has been approach 3 or 4.

#13 @Ipstenu
13 months ago

We have people in the forums able to reproduce this, but not with a WSOD. That is, they get the deprecation warning, but not the white screen.

It would be nice to not have core warn that it, itself, is using deprecated code, at the very least.

#14 @timhibberd
13 months ago

Cheers @Ipstenu - I have been hoping some others might add further insight to this issue. My problems literally commenced with the upgrade from v5Beta3 to v5Beta4. No change on the system on my side and it went from working to non-working GB edits with the upgrade. So something changed between v5Beta3 and v5Beta4 that would be a natural suspect in the generation of these Javascript errors. Was there a Webpack version upgrade at that time?

My installation is just WordPress with a few debugging plug-ins (disabling the plug-ins does not change anything).

For those joining this thread in the middle, the WSOD is not caused by a PHP error. The page is being delivered in entirety and the WSOD is caused by Javascript errors within REACT code with a number being Webpack related. Displaying existing pages built with previous GB editor works fine but I can no longer add / edit pages.

I will do more testing to try to identify any common patterns. At the moment the errors look like random concurrency issues related to dynamic loading of REACT / DOM elements. I'm new to REACT so it will take me time to be more specifically helpful.

The only thing I am doing that may be different from others is that I am running this under Docker for Windows. It is possible that this configuration varies the timing sufficient to show race-conditions that others don't see using a conventional installation. I have done some Google searching and it looks like REACT is not a linear renderer and uses a number of concurrency and asynchronous rendering tricks to make the render appear to be faster and more fluid. At the moment this is what this error looks like to me. Concurrency race-conditions.

I'll test and research further. It would be good if there was at least someone else experiencing fatal JavaScript errors so we could compare set-ups.

#15 @timhibberd
13 months ago

Still an issue in 5.0-RC1-43944.

This looks like a race condition in the REACT / Webpack centric Javascript on the EditPage.

I switched to 2019 theme and kept only one browser tab open to focus my testing and can now occasionally switch a viewed page into edit mode. But the page edit fails with Javacript errors 90% of the time. No issue with viewing existing pages. Just can't Add New pages or edit existing pages.

Here is the latest Javascript errors:

09:20:32.679 SyntaxError: missing } after property list[Learn More] editor.js:19359:34 note: { opened at line 19354, column 53editor.js:19354:53
09:20:32.699 TypeError: Object(...) is not a function[Learn More] block-library.js:1740:67
09:20:32.719 TypeError: Object(...)(...) is undefined[Learn More] edit-post.js:2102:16
09:20:32.904 TypeError: wp.editPost is undefined[Learn More] post.php:1732:4 

If I refresh the page sometimes it works. Another failure, different from the previous, simply by refreshing the edit page:

09:22:41.637 SyntaxError: unexpected token: identifier[Learn More] components.js:23536:33
09:22:41.756 TypeError: external_this_wp_components_ is undefined[Learn More] editor.js:14135:1
09:22:41.776 TypeError: external_this_wp_components_ is undefined[Learn More] block-library.js:1515:5
09:22:41.790 TypeError: external_this_wp_components_ is undefined[Learn More] edit-post.js:1113:5
09:22:41.795 TypeError: external_this_wp_components_ is undefined[Learn More] format-library.js:1162:34
09:22:41.960 TypeError: wp.editPost is undefined[Learn More] post.php:1732:4 

Here is another failure:

09:24:22.888 SyntaxError: '' string literal contains an unescaped line break components.js:24146:377
09:24:23.011 TypeError: external_this_wp_components_ is undefined[Learn More] editor.js:14135:1
09:24:23.034 TypeError: external_this_wp_components_ is undefined[Learn More] block-library.js:1515:5
09:24:23.049 TypeError: external_this_wp_components_ is undefined[Learn More] edit-post.js:1113:5
09:24:23.055 TypeError: external_this_wp_components_ is undefined[Learn More] format-library.js:1162:34
09:24:23.218 TypeError: wp.editPost is undefined[Learn More] post.php:1732:4 

The edit page refresh after this error worked with no fatal Javascript errors.

The subsequent edit page refresh failed (notice it is the same error as previous but at a different line:

09:26:39.663 SyntaxError: "" string literal contains an unescaped line break components.js:23712:27
09:26:39.781 TypeError: external_this_wp_components_ is undefined[Learn More] editor.js:14135:1
09:26:39.803 TypeError: external_this_wp_components_ is undefined[Learn More] block-library.js:1515:5
09:26:39.818 TypeError: external_this_wp_components_ is undefined[Learn More] edit-post.js:1113:5
09:26:39.824 TypeError: external_this_wp_components_ is undefined[Learn More] format-library.js:1162:34
09:26:39.998 TypeError: wp.editPost is undefined[Learn More] post.php:1732:4 

This looks like a race condition problem to me. Race condition problems are nasty to track down and fix. Devastating in the field. You can't predict which sites it will affect or how many sites it will affect and there is no quick field fix to recommend to people. I would not recommend shipping WP5.0 until someone can work with me to try to isolate the root cause of these race condition errors.

#16 @timhibberd
13 months ago

There seems to be an improvement in 5.0-RC1-43945 but the WSOD still exists.

Using Twenty-Nineteen theme. latest Firefox and no plug-ins enabled in docker container under Docker for Windows.

I can now add and edit pages but if I open the FireFox debugger the edit page fails every time with random but repeatable errors (see below).

Based on experience if the software works when the debugger is off and fails when the debugger is on then the problem is race conditions.

15:21:14.544 SyntaxError: unexpected token: identifier[Learn More] components.js:23536:33
15:21:14.634 SyntaxError: missing ( before formal parameters editor.js:19884:69
15:21:14.654 TypeError: external_this_wp_components_ is undefined[Learn More] block-library.js:1515:5
15:21:14.669 TypeError: external_this_wp_components_ is undefined[Learn More] edit-post.js:1113:5
15:21:14.675 TypeError: external_this_wp_components_ is undefined[Learn More] format-library.js:1162:34
15:21:14.865 TypeError: wp.editPost is undefined[Learn More] post.php:1732:4 

Then refresh and:

15:24:28.534 SyntaxError: illegal character[Learn More] editor.js:20294:23
15:24:28.554 TypeError: Object(...) is not a function[Learn More] block-library.js:1740:67
15:24:28.575 TypeError: Object(...)(...) is undefined[Learn More] edit-post.js:2102:16
15:24:28.684 TypeError: wp.editPost is undefined[Learn More] post.php:1729:4

Then refresh and:

15:25:41.188 SyntaxError: missing } after property list[Learn More] editor.js:20332:20 note: { opened at line 20331, column 92editor.js:20331:92
15:25:41.209 TypeError: Object(...) is not a function[Learn More] block-library.js:1740:67
15:25:41.227 TypeError: Object(...)(...) is undefined[Learn More] edit-post.js:2102:16
15:25:41.342 TypeError: wp.editPost is undefined[Learn More] post.php:1729:4 

#17 @timhibberd
13 months ago

Still an issue in 5.0-RC1-43946. As with 5.0-RC1-43945 add / edit page seems to work ok BUT if you enable browser debug tools (Firefox) then you get a WSOD due to Javascript errors.

Please do not interpret this as a reason to defer solving it. If it is a race condition issue as I suspect then it would randomly re-emerge for people who do not have debuger tools enabled.

16:28:04.132 SyntaxError: missing } after property list[Learn More] editor.js:19359:34 note: { opened at line 19354, column 53editor.js:19354:53
16:28:04.152 TypeError: Object(...) is not a function[Learn More] block-library.js:1740:67
16:28:04.170 TypeError: Object(...)(...) is undefined[Learn More] edit-post.js:2102:16
16:28:04.280 TypeError: wp.editPost is undefined[Learn More] post.php:1731:4 

#18 @timhibberd
13 months ago

Still an issue in 5.0-RC1-43947. Worse than 5.0-RC1-43946. About as bad as when I started reporting this issue. Now it fails virtually all the time with or without Firefox debug enabled.

Sample errors:

15:50:37.100 SyntaxError: unexpected token: identifier[Learn More] components.js:23536:33
15:50:37.184 SyntaxError: missing } after property list[Learn More] editor.js:19359:34 note: { opened at line 19354, column 53editor.js:19354:53
15:50:37.203 TypeError: external_this_wp_components_ is undefined[Learn More] block-library.js:1515:5
15:50:37.217 TypeError: external_this_wp_components_ is undefined[Learn More] edit-post.js:1113:5
15:50:37.223 TypeError: external_this_wp_components_ is undefined[Learn More] format-library.js:1162:34
15:50:37.343 TypeError: wp.editPost is undefined[Learn More] post.php:1731:4 
15:53:42.736 SyntaxError: unexpected token: identifier[Learn More] components.js:23536:33
15:53:42.864 TypeError: external_this_wp_components_ is undefined[Learn More] editor.js:14135:1
15:53:42.883 TypeError: external_this_wp_components_ is undefined[Learn More] block-library.js:1515:5
15:53:42.897 TypeError: external_this_wp_components_ is undefined[Learn More] edit-post.js:1113:5
15:53:42.902 TypeError: external_this_wp_components_ is undefined[Learn More] format-library.js:1162:34
15:53:43.000 TypeError: wp.editPost is undefined[Learn More] post-new.php:1728:4 
15:55:37.219 SyntaxError: missing } after property list[Learn More] editor.js:19359:34 note: { opened at line 19354, column 53editor.js:19354:53
15:55:37.248 TypeError: Object(...) is not a function[Learn More] block-library.js:1740:67
15:55:37.267 TypeError: Object(...)(...) is undefined[Learn More] edit-post.js:2102:16
15:55:37.381 TypeError: wp.editPost is undefined[Learn More] post-new.php:1728:4 

#19 @aduth
13 months ago

@timhibberd :

Based on the error messages , specifically the SyntaxError, it seems to me that the server is sending an incomplete JavaScript file. Could you try sending several requests to /wp-includes/js/dist/editor.js directly to see if the server sends with an identical response each time? Perhaps there is a timeout or max response size which is being reached, at which point the server is bailing?

Last edited 13 months ago by aduth (previous) (diff)

#20 @timhibberd
13 months ago

Cheers @aduth - In the absence of anyone else having a similar problem I will try to rebuild this Docker container (Turnkey Linux, PHP upgrade to 7.2, xdebug enabled,WordPress locally mounted on desktop disk) and see if I can reproduce these issues. If not, I'll likely close this issue and chalk it up to a non-backward compatible database upgrade issue (uninitialised variable perhaps) from v5Beta3 and v5Beta4.

#21 @timhibberd
12 months ago

Cheers @mcsf for your follow-up in the [Nov 30 WP5.0 Status report](https://make.wordpress.org/core/2018/11/30/5-0-gutenberg-status-update-nov-30/) regarding this issue. Your assistance is much appreciated.

I have included your comment below for the purposes of further discussion and to keep you in the loop:


"To be clear, I am assuming we are talking about 45341 (cc @jorbin). I’ve had a look at this and have discussed it with @aduth, and so far the evidence suggests a server issue. Whatever is behind that, I believe the central issue is that the JS assets are failing to properly load. In any case, nothing indicates an issue of concurrency or in the way React operates — rather, the failure to load critical packages leads to errors in the initialisation of the editor. Furthermore, there don’t seem to be corroborations of the actual WSOD, only of the logging of PHP notices.

In short: it was wrong to leave the ticket in the awaiting review queue, but it’s not a critical bug. However, I hope we can spend some more time to get to the bottom of it."


I am still working through the request from @aduth to test the server angle.

Although @aduth suggestion that the server may be timing out and returning an incomplete Javascript file is a good suggestion and I will look to see if that is the cause, it is however equally likely that the issue is a REACT race-condition (browser side dynamic loading / rendering issue) or an error on the server side in the dynamic production of the returned JavaScript files.

Analysis Factors To Date:

  • I had no fatal JavaScript errors in any WP5 release up to and including v5Beta3 with this installation. The issues started to happen once I upgraded to v5Beta4 and the issues have persisted in newer releases. Anything interesting / significant in the REACT / WebPack arena between v5Beta3 and v5Beta4?
  • There are no failed file requests in the browser network log on any of the pages with JavaScript errors so server delivery does not appear to be an issue (this is a standard Turnkey Linux LAMP environment I have been using for years with no server delivery issues)
  • Some edit pages reproducibly succeed / fail simply by toggling the browser (firefox) debugger on / off. Although this may change the request dynamics to the server subtly it indicates a potential Javascript issue on the browser rendering side more so than it indicates a server delivery issue.
  • It is unlikely to be a server delivery / network corruption issue because a successfully rendered edit page is consistently rendered without error through multiple refreshes then fails reproducibly with multiple refreshes simply by toggling the browser debugger on.
  • JavaScript errors are mid-file...this is not file truncation as one would expect to see if there was a server error (see sample below)

Sample error with associated Javascript file:

06:54:14.337 SyntaxError: function statement requires a name[Learn More] components.js:23645:9
06:54:14.420 SyntaxError: unexpected token: string literal[Learn More] editor.js:19352:19
06:54:14.440 TypeError: external_this_wp_components_ is undefined[Learn More] block-library.js:1515:5
06:54:14.453 TypeError: external_this_wp_components_ is undefined[Learn More] edit-post.js:1113:5
06:54:14.459 TypeError: external_this_wp_components_ is undefined[Learn More] format-library.js:1162:34
06:54:14.552 TypeError: wp.editPost is undefined[Learn More] post.php:1729:4 
var block_list_BlockList =
/*#__PURE__*/
function (_Component) {
  Object(inherits["a" /* default */])(BlockList, _Component);

  function BlockList(props) {
    var _this;

    Object(classCallCheck["a" /* default */])(this, BlockList);

    _this = Object(possibleConstructorReturn["a" /* default */])(this, Object(getPrototypeOf["a" /* default */])(BlockList).call(this, props));
    _this.onSelectionStart = _this.onSelectionStart.bind(Object(assertThisInitialized["a" /* default */])(Object(assertThisInitialized["a" /* default */])(_this)));
    _this.onSelectionEnd = _this.onSelectionEnd.bind(Object(assertThisInitialized["a" /* default */])(Object(assertThisInitialized["a" /* default */])(_this)));
    _this.setBlockRef = _this.setBlockRef.bind(Object(assertThisInitialized["a" /* default */])(Object(assertThisInitialized["a" /* default */])(_this)));
    _this.setLastClientY = _this.setLastClientY.bind(Object(assertThisInitialized["a" /* default */])(Object(assertThisInitialized["a" /* default */])(_this)));
    _this.onPointerMove = Object(external_lodash_["throttle"])(_this.onPointerMove.bind(Object(assertThisInitialized["a" /* default */])(Object(assertThisInitialized["a" /* default */])(_this))), 100); // Browser does not fire `*move` event when the pointer position changes
    // relative to the document, so fire it with the last known position.

    _this.onScroll = function () {
      return _this.onPointerMove({
        clientY: _this.lastClientY
      });
    };

    _this.lastClie "componentDidMount",
    value: function componentDidMount() {
      window.addEventListener('mousemove', this.setLastClientY);
    }
  }, {
    key: "componentWillUnmount",
    value: function componentWillUnmount() {
      window.removeEventListener('mousemove', this.setLastClientY);
    }
  }, {
    key: "setLastClientY",
    value: function setLastClientY(_ref) {
      var clientY = _ref.clientY;
      this.lastClientY = clientY;
    }
  }, {
    key: "setBlockRef",
    value: function setBlockRef(node, clientId) {
      if (node === null) {
        delete this.nodes[clientId];
      } else {
        this.nodes = Object(objectSpread["a" /* default */])({}, this.nodes, Object(defineProperty["a" /* default */])({}, clientId, node));
      }
    }
    /**
     * Handles a pointer move event to update the extent of the current cursor
     * multi-selection.
     *
     * @param {MouseEvent} event A mousemove event object.
     *
     * @return {void}
     */

  }, {

You can see the mid-file code line (editor.js:19352:19) _this.lastClie "componentDidMount", appears to have been partially rendered. This would be more of an indicator of a browser side dynamic loading / rendering issue or a server-side file creation issue rather than a delivery issue.

Or...it is possible that this WordPress / Server combo got corrupted during the upgrade process from v5Beta3 to v5Beta4 and this is just a bad build.

So...next steps...I am trying to re-create another Docker container from scratch that reproducibly experiences these types of errors. If I can reproducibly re-create an environment that reproduces these issues then others can try to replicate. If I can't reproduce the environment I will probably close this issue and we will roll the dice and hope that it was just a bad build.

But it is worth some effort...race condition issues are a bugger in the field and reproducing them in the lab in many cases is impossible. If this IS a race condition issue then this build is worth its weight in gold.

I have some client work to do over today and tomorrow so I probably won't get a chance to progress this further until the weekend. Given the push to get V5.0 released I am trying to give this as much priority as I can (debugging this type of issue is very time-consuming).

#22 @pento
12 months ago

  • Keywords reporter-feedback close added; dev-feedback removed
  • Milestone Awaiting Review deleted

The JS files being corrupted sounds like a Docker issue.

For example, if you're using VMWare Fusion with Docker Machine, syncing corruption issues can occur: https://github.com/docker/machine/issues/1460

Using Virtualbox with Docker Machine can also have corruption issues: https://frankooh.wordpress.com/2011/01/21/vboxsf-and-small-files/

I'd probably start investigating there: if you're able to create another Docker environment exhibiting the same symptoms, are you then still able to reproduce it if the WordPress files are installed within the container, rather than mounted from the host?

#23 @timhibberd
12 months ago

@pento thanks for the suggestion. I agree it is a possibility. At the moment there are a lot of possible culprits.

What is throwing me off is that I have been using this Docker-for-Windows setup with WordPress 4.x for over a year with most containers running WordPress mounted on the local disk AND the V5Beta WordPress container instance presently giving me grief worked fine for all V5 releases up to and including v5Beta3. The trouble only started in v5Beta4.

So I am focusing on the deltas...what has changed and what is different.

The container-based V5 WordPress causing trouble is different from all the others that work fine in the following ways:

1) I upgraded PHP on the server in the container from PHP7.0 to PHP7.2. All my other containers that work fine are running PHP7.0

2) XDEBUG was installed and enabled on this container only. XDebug is not installed / enabled on the other containers that work fine

3) This is the only container with a WordPress that has been updated daily with nightly V5Beta releases since early V5Beta releases were made available...is this just a corrupted upgrade sequence! Maybe!

So with all the possibilities including a build corrupted somehow through the nightly Beta build upgrades I think my prudent next step is to try to recreate an environment with the same problems.

I will poke at this container instance a bit but I am reluctant to invest too much of my time and valuable time of contributors such as yourself on what is quite possibly a red herring.

I just don't want to give up too quickly and find out later through failures in the field that there is a REACT / Webpack race-condition. Race conditions are hard to reproduce so if this is one, this container is a debug goldmine. I am targeting to diagnose this issue or close it as a red herring by mid next week.

Thanks for your help. Much appreciated :-)

#24 @timhibberd
12 months ago

  • Keywords needs-patch reporter-feedback removed
  • Severity changed from critical to normal

Problem(s) diagnosed:

  1. "admin-post" reference in components.min.js file missing from components.js file (happened on v5Beta4 upgrade)
  2. Bleeding edge builds do not package the /wp-includes/js/dist/ folder (which would have corrected issue1)
  3. define( 'SAVEQUERIES', true ); in wp-config.php file causes JavaScript errors when browser debugging enabled

NOTE:

Not sure why define( 'SAVEQUERIES', true ); would cause JavaScript errors when browser debugging is enabled since this setting affects the server. If it caused issues I would expect it to affect the delivered JavaScript whether browser debugging was enabled or disabled. Toggling the browser debugging would only affect the timing of the server requests not their substance. Thoughts?


Actions:

ME:

  • Downgrade Severity from Critical to Normal
  • Drop NeedsPatch tag
  • Drop ReporterFeedback tag

@pento (or other core developer)

  1. Decide how best to handle this (close it? make it minor? make it enhancement? Add a note to the developer guide? etc)
  2. Consider enabling C.I. on bleeding edge releases so the /wp-includes/js/dist/ is updated and released in every build
  3. Consider why define( 'SAVEQUERIES', true ); would cause JavaScript errors when browser debugging is enabled

Thanks for all your help everyone. I'm glad this turned into a non-bug though it chewed up a chunk of my life that I would rather have back :-)

#25 @timhibberd
12 months ago

  • Summary changed from WSOD when editing a page (Issue introduced between v5Beta3 and v5Beta4) to WSOD when editing a page with define( 'SAVEQUERIES', true ); set in wp-config.php

I have re-titled this issue. It should not be closed without diagnosing and solving it or at least not before putting a prominent warning in the developer handbook.

#26 @SergeyBiryukov
9 months ago

  • Milestone set to Awaiting Review
Note: See TracTickets for help on using tickets.