Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gutenberg 3.1 breaks Real Media Library (on Wordpress Media Library screen) #7488

Closed
opicron opened this issue Jun 22, 2018 · 3 comments · Fixed by #7566
Closed

Gutenberg 3.1 breaks Real Media Library (on Wordpress Media Library screen) #7488

opicron opened this issue Jun 22, 2018 · 3 comments · Fixed by #7566
Labels
[Feature] Media Anything that impacts the experience of managing media [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes.

Comments

@opicron
Copy link

opicron commented Jun 22, 2018

Describe the bug
With the latest Gutenberg update (3.1) the Wordpress Media Library does not load and shows an blank screen. I narrowed this down to an plugin I use which is no longer working after the update. The plugin in question is Real Media Library (RML). It fails with the following errors in the console:

ReferenceError: wpApiSettings is not defined: rml.js:1:47210
TypeError: window.rml is undefined: script.js:10:5
TypeError: e is undefined: load-scripts.php:277:1538

On the previous Gutenberg 3.0.1 (?) there was no issue. Also when I disable RML and use only Gutenberg 3.1 all works as intended.

To Reproduce
Steps to reproduce the behavior:

  1. Install Gutenberg 3.1
  2. Install Real Media Libary
  3. Open Wordpress Media Library
  4. See error

Expected behavior
Expected behavior is to not interfere with other plugins.

Screenshots
I can upload the error or blank screen if requested.

Desktop (please complete the following information):
OS: Windows 10
Browser: Firefox

Additional context
I am not sure if this bug report belongs here or at Real Media Library. At the moment the issue report has been posted both to RML and Gutenberg.

@jorgefilipecosta jorgefilipecosta added [Feature] Media Anything that impacts the experience of managing media [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes. labels Jun 22, 2018
@matzeeable
Copy link

Hi! The RML plugin developer here. I can not have a look at this atm, unfortunely. RML is using the global window.wpApiSettings. Has Gutenberg changed something for the global variable? My guess is that the wpApiSettings object is wp_localize_script'd after RML enqueues scripts.

Can you try to navigate to wp-content/plugins/real-media-library/inc/general/Assets.class.php and replace:

$this->enqueueScript('real-media-library', 'rml.js', array('react-dom'));

with

$this->enqueueScript('real-media-library', 'rml.js', array('react-dom', 'wp-api'));

@opicron
Copy link
Author

opicron commented Jun 23, 2018

Thanks, no rush to fix this-- I tried the adjustment but the error remains.

Related issue: #7455

@opicron
Copy link
Author

opicron commented Jun 23, 2018

Adding the following code before enqeueScript solves the issue for now. Same as in the other issue thread.

gutenberg_extend_wp_api_backbone_client();

@youknowriad youknowriad reopened this Jul 17, 2018
svn2github pushed a commit to svn2github/wordcamp-mu-plugins that referenced this issue Jul 19, 2018
Starting in Gutenberg 3.1, the 'wp-api-request' script gets de-registered
and re-registered with a Gutenberg-specific version. Unfortunately, the
script doesn't also get re-localized with the `wpApiSettings` variable that's
needed for wp-api.js, unless the current screen contains an editor instance.

The bug was reported here:
WordPress/gutenberg#7488

And it should be fixed once the changes in this pull request get released:
WordPress/gutenberg#7566

In the meantime, this hotfix should ensure that `wpApiSettings` is available
regardless of the presence of an editor instance.



git-svn-id: https://meta.svn.wordpress.org/sites/trunk/wordcamp.org/public_html/wp-content/mu-plugins@7476 74240141-8908-4e6f-9713-ba540dce6ec7
iandunn pushed a commit to WordPress/wordcamp.org that referenced this issue Nov 15, 2018
Starting in Gutenberg 3.1, the 'wp-api-request' script gets de-registered
and re-registered with a Gutenberg-specific version. Unfortunately, the
script doesn't also get re-localized with the `wpApiSettings` variable that's
needed for wp-api.js, unless the current screen contains an editor instance.

The bug was reported here:
WordPress/gutenberg#7488

And it should be fixed once the changes in this pull request get released:
WordPress/gutenberg#7566

In the meantime, this hotfix should ensure that `wpApiSettings` is available
regardless of the presence of an editor instance.



git-svn-id: https://meta.svn.wordpress.org/sites/trunk/wordcamp.org@7476 74240141-8908-4e6f-9713-ba540dce6ec7
vedanshujain pushed a commit to WordPress/wordcamp.org that referenced this issue Nov 29, 2018
Starting in Gutenberg 3.1, the 'wp-api-request' script gets de-registered
and re-registered with a Gutenberg-specific version. Unfortunately, the
script doesn't also get re-localized with the `wpApiSettings` variable that's
needed for wp-api.js, unless the current screen contains an editor instance.

The bug was reported here:
WordPress/gutenberg#7488

And it should be fixed once the changes in this pull request get released:
WordPress/gutenberg#7566

In the meantime, this hotfix should ensure that `wpApiSettings` is available
regardless of the presence of an editor instance.



git-svn-id: https://meta.svn.wordpress.org/sites/trunk/wordcamp.org@7476 74240141-8908-4e6f-9713-ba540dce6ec7


git-svn-id: https://github.com/WordPress/wordcamp.org.git@1266 a64dc54a-4538-25e2-d9ce-ce57b7db7bff
vedanshujain pushed a commit to WordPress/wordcamp.org that referenced this issue Nov 29, 2018
Starting in Gutenberg 3.1, the 'wp-api-request' script gets de-registered
and re-registered with a Gutenberg-specific version. Unfortunately, the
script doesn't also get re-localized with the `wpApiSettings` variable that's
needed for wp-api.js, unless the current screen contains an editor instance.

The bug was reported here:
WordPress/gutenberg#7488

And it should be fixed once the changes in this pull request get released:
WordPress/gutenberg#7566

In the meantime, this hotfix should ensure that `wpApiSettings` is available
regardless of the presence of an editor instance.



git-svn-id: http://meta.svn.wordpress.org/sites/trunk/wordcamp.org@7476 74240141-8908-4e6f-9713-ba540dce6ec7
vedanshujain pushed a commit to WordPress/wordcamp.org that referenced this issue Dec 6, 2018
Starting in Gutenberg 3.1, the 'wp-api-request' script gets de-registered
and re-registered with a Gutenberg-specific version. Unfortunately, the
script doesn't also get re-localized with the `wpApiSettings` variable that's
needed for wp-api.js, unless the current screen contains an editor instance.

The bug was reported here:
WordPress/gutenberg#7488

And it should be fixed once the changes in this pull request get released:
WordPress/gutenberg#7566

In the meantime, this hotfix should ensure that `wpApiSettings` is available
regardless of the presence of an editor instance.



git-svn-id: https://meta.svn.wordpress.org/sites/trunk/wordcamp.org@7476 74240141-8908-4e6f-9713-ba540dce6ec7
vedanshujain pushed a commit to WordPress/wordcamp.org that referenced this issue Dec 6, 2018
Starting in Gutenberg 3.1, the 'wp-api-request' script gets de-registered
and re-registered with a Gutenberg-specific version. Unfortunately, the
script doesn't also get re-localized with the `wpApiSettings` variable that's
needed for wp-api.js, unless the current screen contains an editor instance.

The bug was reported here:
WordPress/gutenberg#7488

And it should be fixed once the changes in this pull request get released:
WordPress/gutenberg#7566

In the meantime, this hotfix should ensure that `wpApiSettings` is available
regardless of the presence of an editor instance.



git-svn-id: https://meta.svn.wordpress.org/sites/trunk/wordcamp.org@7476 74240141-8908-4e6f-9713-ba540dce6ec7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Media Anything that impacts the experience of managing media [Type] Plugin Interoperability Incompatibilities between a specific plugin and the block editor. Close with workaround notes.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants