Can't edit pages after update to 6.7 and also later after downgrade

[levskipg]

When i go to Edit Page i see in console:

Uncaught TypeError: Cannot read properties of undefined (reading 'unstable_scheduleCallback')
    at n (react-dom.min.js?ver=18.3.1:10:105894)
    at react-dom.min.js?ver=18.3.1:10:129073
    at react-dom.min.js?ver=18.3.1:10:129108
n @ react-dom.min.js?ver=18.3.1:10
(anonimowa) @ react-dom.min.js?ver=18.3.1:10
(anonimowa) @ react-dom.min.js?ver=18.3.1:10Co oznacza ten błądAI
edit-post.min.js?ver=914d3a541465a53adb05:2 Uncaught TypeError: (0 , c.createRoot) is not a function
    at Module.Jt (edit-post.min.js?ver=914d3a541465a53adb05:2:38319)
    at HTMLDocument.<anonymous> (post.php?post=747&action=edit:3044:25)

And white screen appears. It happen on already 2 websites with different plugins/themes.

[levskipg]

Just done a SHIFT + Refresh and it's working. But many people can have this problem.

[desrosj]

Hi @levskipg,

Welcome to Trac! Thank you for the report. I have a site experiencing this as well. Here is my full error log for reference. I'm moving this to the 6.7.1 milestone to investigate, because if sites are breaking we should fix it the first chance we get.

Uncaught TypeError: can't access property "unstable_scheduleCallback", tu is undefined
  n https://example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1:10
  <anonymous> https://example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1:10
  <anonymous> https://example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1:10
  react-dom.min.js:10:105891
  n https://example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1:10
  <anonymous> https://example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1:10
  <anonymous> https://example.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=18.3.1:10
Uncaught TypeError: d.createRoot is not a function
  Xk https://example.com/wp-includes/js/dist/edit-site.min.js?ver=79e90f0c7638bb507b37:11
  <anonymous> https://example.com/wp-admin/site-editor.php?postType=wp_template&postId=sitename//front-page&canvas=edit:2118
  d jQuery
  <anonymous> https://example.com/wp-admin/site-editor.php?postType=wp_template&postId=sitename//front-page&canvas=edit:2117
  edit-site.min.js:11:502451
  Xk https://example.com/wp-includes/js/dist/edit-site.min.js?ver=79e90f0c7638bb507b37:11
  <anonymous> https://example.com/wp-admin/site-editor.php?postType=wp_template&postId=sitename//front-page&canvas=edit:2118
(Async: EventListener.handleEvent)
  d jQuery
  <anonymous> https://example.com/wp-admin/site-editor.php?postType=wp_template&postId=sitename//front-page&canvas=edit:2117

I haven't been found the root cause yet, but activating the Gutenberg plugin does fix the issue.

[get_dave]

I don't have a good explanation as to what might be causing this but looking at the error, createRoot seems to be called by initializeEditor in the @wordpress/edit-site package which marries up with the edit-site in the error above:

​https://github.com/WordPress/gutenberg/blob/a120f10e63e3c6eb5fa4970e8ab3690e74453fde/packages/edit-site/src/index.js#L41

createRoot itself is provided by @wordpress/element which in turn exports it directly from react-dom/client.

​https://github.com/WordPress/gutenberg/blob/a120f10e63e3c6eb5fa4970e8ab3690e74453fde/packages/element/src/react-platform.js#L12

It's also called in initializePostsDashboard but that's gated to the Gutenberg Plugin:

​https://github.com/WordPress/gutenberg/blob/a120f10e63e3c6eb5fa4970e8ab3690e74453fde/packages/edit-site/src/posts.js#L39

[levskipg]

I think it's because of browser cache of javascripts? As Shift + Refresh resolving the issue.

[desrosj]

@levskipg I agree that it seems to be a caching issue. For me, the site experiencing this issue had caching configured in Cloudflare. Purging the cache fixed the problem.

That said, caches should be busted when a file includes changes in each WordPress release. So it's strange that was not the case in this instance.

[desrosj]

I'm still not exactly sure why this happened, but here are some things I found that may be relevant.

In WP 6.6, [58775] changed how react and react-dom and the commit specifically mentions createRoot. Based on the ​corresponding changeset on the build server, there were changes to these distributed files.

While this change did not update the versions for each dependency in script-loader.php (which is the value responsible for cache busting on update when changes are made), the version of react and react-dom being used was updated in [58187], so anyone updating to 6.6 should have the right version of these files cached.

[desrosj]

I'm not sure what can be done here. All of the occurrences have been resolved by flushing caches and there have been no new reports of this issue. I'm going to close this one out.

Discussion can always continue on closed tickets, and if new reports emerge it can be reopened.

[smerriman]

One of my clients received exactly the same error as provided in the original post. While it also resolved via a hard-refresh, this is more than a one-off occurrence.

[jdnd]

My site with 6.7 is also affected by this. Force reload doesn't work, nor switching Cloudflare into dev mode to bypass caching.

There's a thread with a temporary workaround however which does work:

• ​https://wordpress.org/support/topic/blank-screen-when-trying-to-add-a-new-post/

This post in there suggests the problem gets introduced with minified script versions as the workaround is to load the debug versions:

• ​https://wordpress.org/support/topic/blank-screen-when-trying-to-add-a-new-post/#post-18138555

HTH getting this resolved!

[juanwp22]

I believe I have the same issue as many other users. Here’s the post I created (​https://wordpress.org/support/topic/blank-screen-when-trying-to-add-a-new-post/#post-18138645), where someone shared a temporary solution. I also tried downgrading WordPress, but the problem persisted, so I stayed with the current version. Apologies if this is not the correct way to post here.

[desrosj]

@smerriman @jdnd @juanwp22 Thanks for the additional reports for this one.

Could each of you share which browsers you are using? If you only tried one, could you try one or two others to see if they all experience the problem?

Also, could you share the exact error messages that you're seeing?

[jdnd]

Problem occurs in both Brave and Google Chrome - I'm on MacOS Sequoia 15.1 (24B83):

Brave is up to date
Version 1.73.89 Chromium: 131.0.6778.69 (Official Build) (x86_64)

Nearly up to date! Relaunch Chrome to finish updating.
Version 130.0.6723.92 (Official Build) (x86_64)

However I've just tried Safari - Version 18.1 (20619.2.8.11.10) - and the problem does NOT manifest here!

[desrosj]

Thanks for the added details @jdnd!

Just noting that both Brave and Google Chrome are based on Chromium. However, I was using Firefox when I encountered this problem (which is not Chromium based).

Could you share the errors in your browser console?

[juanwp22]

Replying to desrosj:

@smerriman @jdnd @juanwp22 Thanks for the additional reports for this one.

Could each of you share which browsers you are using? If you only tried one, could you try one or two others to see if they all experience the problem?

Also, could you share the exact error messages that you're seeing?

I always use the latest version of Firefox, but I tested with Chrome, and the same issue occurs. Additionally, I tried on another PC, and the problem persists. I also tested in incognito mode, but it didn’t solve the issue.

[desrosj]

6.7.1 RC1 is due out in a few hours, but there's no clear cause or path forward here. I'm going to punt to 6.7.2 to keep an eye on it.

Please pay close attention when updating to 6.7.2 to see if the issue reoccurs and try to make note of any error messages or patterns.

[seanlanglands]

The contents of react-dom.min.js change between 6.6 and 6.7 (here's the history):
​https://github.com/WordPress/WordPress/commits/master/wp-includes/js/dist/vendor/react-dom.min.js

But the script version does not:

6.6: ​https://github.com/WordPress/wordpress-develop/blob/ee5bd5553f96264359a029768e1525dbc623ed63/src/wp-includes/script-loader.php#L112

6.7: ​https://github.com/WordPress/wordpress-develop/blob/94a798b54b4be308cfafb2db09bbed9c3ea9ff34/src/wp-includes/script-loader.php#L110

I believe the above value is used for the ?ver= parameter when enqueuing. Since evidence points to a caching issue, changing the version should have prevented these issues and forced servers/clients to grab an updated 6.7 script version. Perhaps naming the version "18.3.1-umd" or something to that effect.

[robertstaddon]

Replying to seanlanglands:

The contents of react-dom.min.js change between 6.6 and 6.7 (here's the history):
​https://github.com/WordPress/WordPress/commits/master/wp-includes/js/dist/vendor/react-dom.min.js

But the script version does not:

6.6: ​https://github.com/WordPress/wordpress-develop/blob/ee5bd5553f96264359a029768e1525dbc623ed63/src/wp-includes/script-loader.php#L112

6.7: ​https://github.com/WordPress/wordpress-develop/blob/94a798b54b4be308cfafb2db09bbed9c3ea9ff34/src/wp-includes/script-loader.php#L110

I believe the above value is used for the ?ver= parameter when enqueuing. Since evidence points to a caching issue, changing the version should have prevented these issues and forced servers/clients to grab an updated 6.7 script version. Perhaps naming the version "18.3.1-umd" or something to that effect.

@seanlanglands has absolutely nailed the cause of the problem here! Brilliant work.

Over the past week I have had multiple clients on multiple servers with multiple browsers on a wide variety of themes and plugins all experiencing this exact same JavaScript error in their console after being upgraded from WordPress 6.6 to 6.7. In every situation clearing the CloudFlare cache and having the client do a Shift + refresh to clear their local browser cache resolved the issue.

[seanlanglands]

I was able to replicate the errors when react.js is served with the previous non-umd build (included in WP 6.6.2) and react-dom.js has the new umd build (included in WP 6.7.1).

I'll try to find time to submit a patch to append —umd to those script versions, which should prevent browsers from inconsistently caching during WP upgrades.

[seanlanglands]

prepends react and react-dom script version strings with '-umd' to force clients to request the updated umd build scripts

[desrosj]

Thanks @seanlanglands, 62422.patch​ looks good to me.

I am going to commit to trunk and wait to backport. I'm curious if any security scanners will flag this version as insecure. That's my only hesitation to include in 6.7.2 at this time.

[desrosj]

Fixed in [59536] (forgot the #).

Marking for backport consideration.

Fast follow to fix the tests.

Trac ticket: https://core.trac.wordpress.org/ticket/62422

Merged r59540 / ​https://github.com/WordPress/wordpress-develop/commit/9e4b268049b69e96e78bcc1ab77d9d6a4134f8cf

Modified the suffix per ​this discussion with @desrosj in Slack.

[peterwilsoncc]

A fast follow commit was made in [59540] (GitHub ​9e4b268049b69e9 but isn't showing up on trac. If the earlier commit is backported the fast follow will need to be too.

[dilip2615]

Hello

To fix the issue, ensure your custom scripts rely on WordPress's React (wp-element) instead of a third-party version. Update your functions.php to enqueue scripts properly:

function enqueue_custom_scripts() {

wp_enqueue_script(

'my-custom-script',
get_template_directory_uri() . '/js/custom-script.js',
wp-element?,
null,
true

);

}
add_action('wp_enqueue_scripts', 'enqueue_custom_scripts');

Ensure all block descriptions are strings and replace createRoot with ReactDOM.render. Dequeue any conflicting React scripts. If the issue persists, debug further by temporarily switching to a default theme.