Making WordPress.org

Opened 6 years ago

Closed 6 years ago

#3735 closed defect (bug) (fixed)

Frontenberg broken on Rosetta websites: Block "core/shortcode" is not registered.

Reported by: audrasjb's profile audrasjb Owned by:
Milestone: Priority: normal
Component: International Sites (Rosetta) Keywords:
Cc:

Description

Hello,

Hello, fronteberg seems to be broken.
This error appear in browser console: Block "core/shortcode" is not registered.
Examples:

Change History (8)

#1 @audrasjb
6 years ago

  • Priority changed from highest omg bbq to normal

The issue seems to be fixed now, thanks :)

#2 @netweb
6 years ago

  • Resolution set to fixed
  • Status changed from new to closed

This ticket was mentioned in Slack in #meta by garrett-eclipse. View the logs.


6 years ago

#4 @garrett-eclipse
6 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

This issue continues to persist and seems to be a RACE condition so doesn't always surface

#5 @aduth
6 years ago

Still seeing this happen as of today, August 3, 2018.

I commented in Slack with a suspected cause.

The white screen is caused by this line: https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/gutenberg/functions.php?rev=7584#L158
Probably a race condition with the initialization of the editor, which is slightly more involved https://github.com/WordPress/gutenberg/blob/9ae5aa223ef80c48f2352e4b90ffaefc37bc5258/lib/client-assets.php#L1292-L1298
Instead of wp.domReady, it should probably be using window._wpLoadGutenbergEditor.then

Version 0, edited 6 years ago by aduth (next)

#6 @obenland
6 years ago

In 7592:

Gutenberg: Don't unregister block until after editor initialized.

Props randerson, aduth.
See #3735.

#7 @dd32
6 years ago

In 7593:

Gutenberg: Override wp.domReady with a version which doesn't contain a race-condition, this fixes the whitescreen on frontendberg on first load.

wp.domReady() is incorrectly regisering callbacks (such as the Gutenberg init function) to be fired on DOMContentLoaded AFTER that event has already fired, causing the callbacks to never run.
This replaces it with a version which does work, calling the callback immediately when document.readyState is at interactive (which is what fires DOMContentLoaded) or complete (when styles/images/etc are loaded, which the Gutenberg wp.domReady does).

See #3703, #3735.

#8 @obenland
6 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.