Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#53569 closed defect (bug) (fixed)

Block widgets editor is hidden if a block enqueues 'wp-edit-post' stylesheet

Reported by: dlh's profile dlh Owned by: zieladam's profile zieladam
Milestone: 5.8 Priority: normal
Severity: normal Version: 5.8
Component: Widgets Keywords: has-patch dev-reviewed fixed-major commit
Focuses: Cc:

Description

On a client site of mine, a custom block has been developed whose editor_style includes wp-edit-post as a dependency.

When this block loads in the block widgets editor, and the wp-edit-post stylesheet is enqueued, then a CSS rule is added that causes the editor to be hidden. Specifically:

body.block-editor-page #wpbody-content > div:not(.block-editor):not(#screen-meta) {
    display: none;
}

This example block registration should demonstrate the issue:

<?php

add_action(
        'init',
        function () {
                wp_register_style(
                        'my-block-style',
                        'https://example.com',
                        array( 'wp-edit-post' )
                );

                register_block_type(
                        'my-namespace/my-block',
                        array(
                                'editor_style' => 'my-block-style',
                        )
                );
        }
);

Although it also seems to be as simple as:

<?php

add_action(
        'init',
        function () {
                wp_enqueue_style( 'wp-edit-post' );
        }
);

I'll defer to the editor team as to whether using wp-edit-post as a style dependency is doing it wrong.

Attachments (2)

Screen Shot 2021-06-30 at 11.04.55 PM.png (180.0 KB) - added by dlh 3 years ago.
The "blank" block widgets editor
53569.patch (176.9 KB) - added by manzurahammed 3 years ago.

Download all attachments as: .zip

Change History (22)

@dlh
3 years ago

The "blank" block widgets editor

#1 @desrosj
3 years ago

  • Milestone changed from Awaiting Review to 5.8.1

Thanks for this report, @dlh! I've flagged this in the #feature-widgets-block-editor room on Slack for attention.

I'm moving this to 5.8.1 for now, but we can consider including a fix in 5.8 if we find that this is a common practice.

@manzurahammed
3 years ago

#2 @manzurahammed
3 years ago

  • Keywords has-patch added

#3 follow-up: @noisysocks
3 years ago

I'll defer to the editor team as to whether using wp-edit-post as a style dependency is doing it wrong.

Yes I think so. wp-edit-post (@wordpress/edit-post) is the package containing scripts and styles that implement the post block editor (edit.php). It shouldn't be enqueued in the widgets block editor (widgets.php).

#4 in reply to: ↑ 3 @dlh
3 years ago

wp-edit-post (@wordpress/edit-post) is the package containing scripts and styles that implement the post block editor (edit.php). It shouldn't be enqueued in the widgets block editor (widgets.php).

Enqueuing wp-edit-post would be one thing, but, in this case, the offending block only declared it as a dependency so as to define the load order of stylesheets in the editor.

True, under the hood, declaring it as a dependency amounts to the same thing as enqueuing it. Until now, it has been harmless to do so, and if there's documentation from previous releases advising against it, then I just missed it.

So, if providing backwards compatibility is as straightforward as the patch by @manzurahammed suggests, then I would still hope that core could provide that affordance to developers to save them a surprise.

Alternatively, if core knows that wp-edit-post shouldn't be enqueued in the widgets block editor, perhaps there should be protections in core against that happening, although I don't know what kind of precedent there is for such protections.

Last edited 3 years ago by dlh (previous) (diff)

This ticket was mentioned in PR #1481 on WordPress/wordpress-develop by adamziel.


3 years ago
#5

## Description
Solves https://github.com/WordPress/gutenberg/issues/33203
Related to https://core.trac.wordpress.org/ticket/53569

Situation: packages/editor is exposed as window.wp.editor in wp-admin

Problem: there is quite some code expecting to see a different (legacy) object under window.wp.editor

Proposed solution: export all the members of legacy window.wp.editor from this new module to maintain backward compatibility

As @noisysocks noticed in https://github.com/WordPress/gutenberg/pull/33228:

Makes me wonder if a “fix” could be to add code to Core which fires off doing_it_wrong() if you enqueue wp-editor or wp-edit-post in the widgets screen.

This PR contains no such code, I will spin a new one to add these deprecations as there may be some discussion needed about the best way of adding them.

## How has this been tested?

  1. Activate classic widgets plugins.
  2. Insert text widget
  3. Add some text to widget.
  4. Deactivate classic widgets plugins.
  5. Go to widget screen.
  6. There is an error message if this PR is not applied.
  7. There are no error messages if this PR is applied.

## Screenshots

<img width="1904" alt="124498441-3f40df80-ddb4-11eb-99e1-581b287f96de" src="https://user-images.githubusercontent.com/205419/124633716-d9bd2380-de85-11eb-9228-742facbacaf9.png">

(Credits for the screenshot and the test plan to @spacedmonkey)

## Types of changes
Bug fix (non-breaking change which fixes an issue)

#6 @zieladam
3 years ago

I proposed a way of allowing wp-editor and wp-edit-post on the new widgets editor screen https://github.com/WordPress/wordpress-develop/pull/1481

It has certain shortcomings and I think we should be deprecating wp.editor, but I think it's our best shot at improving the situation in 5.8.

Last edited 3 years ago by zieladam (previous) (diff)

#7 @desrosj
3 years ago

  • Milestone changed from 5.8.1 to 5.8

Moving to 5.8 for consideration, though I am a bit hesitant to make this change so late. I defer to @noisysocks' judgement on this one.

#8 @noisysocks
3 years ago

  • Owner set to zieladam
  • Status changed from new to assigned

#9 @noisysocks
3 years ago

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

In 51388:

Widgets: Warn when wp-editor script or wp-edit-post style is enqueued in widgets editor

It is common that plugins erroneously have wp-editor or wp-edit-post as a
dependency in a script that is loaded in the new widgets editor. This is a smell
since both @wordpress/editor and @wordpress/edit-post assume the existence
of a global "post" object which the widgets editor does not have.

[51387] fixes the user-facing errors typically caused by this mistake, but we
can go a step further and warn developers about this by calling
_doing_it_wrong() when we detect that the wp-editor script or wp-edit-post
style is enqueued alongside wp-edit-widgets or wp-customize-widgets.

See #53437.
Fixes #53569.
Props zieladam, spacedmonkey, TimothyBlynJacobs, andraganescu, dlh.

#10 @SergeyBiryukov
3 years ago

In 51390:

Docs: Some documentation improvements for wp_check_widget_editor_deps():

  • Add missing short description for the function.
  • Correct function names in _doing_it_wrong() calls.
  • Document the usage of $wp_scripts and $wp_styles globals.
  • Update syntax for multi-line comment per the documentation standards.

Follow-up to [51387], [51388].

See #53437, #53569.

#11 @SergeyBiryukov
3 years ago

In 51391:

I18N: Translate _doing_it_wrong() messages in wp_check_widget_editor_deps().

This makes them consistent with other similar messages in core.

Follow-up to [51387], [51388], [51390].

See #53437, #53569.

#12 @desrosj
3 years ago

  • Keywords dev-reviewed fixed-major commit added

Reopening to backport [51388] and [51390].

#13 follow-up: @desrosj
3 years ago

In 51393:

Widgets: Warn when wp-editor script or wp-edit-post style is enqueued in widgets editor

It is common that plugins erroneously have wp-editor or wp-edit-post as a
dependency in a script that is loaded in the new widgets editor. This is a smell
since both @wordpress/editor and @wordpress/edit-post assume the existence
of a global "post" object which the widgets editor does not have.

[51387] fixes the user-facing errors typically caused by this mistake, but we
can go a step further and warn developers about this by calling
_doing_it_wrong() when we detect that the wp-editor script or wp-edit-post
style is enqueued alongside wp-edit-widgets or wp-customize-widgets.

Props zieladam, spacedmonkey, TimothyBlynJacobs, andraganescu, dlh, noisysocks.
Merges [51388] to the 5.8 branch.
Fixes #53569. See #53437.

#14 @desrosj
3 years ago

In 51394:

Docs: Some documentation improvements for wp_check_widget_editor_deps():

  • Add missing short description for the function.
  • Correct function names in _doing_it_wrong() calls.
  • Document the usage of $wp_scripts and $wp_styles globals.
  • Update syntax for multi-line comment per the documentation standards.

Follow-up to [51387], [51388].

Props SergeyBiryukov.
Merges [51390] to the 5.8 branch.
See #53437, #53569.

#15 @dlh
3 years ago

#53767 was marked as a duplicate.

#16 @dlh
3 years ago

#53768 was marked as a duplicate.

#17 in reply to: ↑ 13 @seanvarnham
3 years ago

@desrosj, thanks for this! I've spent the last couple hours trying to find out any information on this - presumably as it's new.

Could you point us in the direction of a fix please? I've narrowed the issue down to the code in our agency's blocks plugin:

add_action( 'enqueue_block_editor_assets', 'enqueue_editor_assets' );
function enqueue_editor_assets() {
    wp_enqueue_script(
        'block-editor-assets',
        plugins_url('dist/editor_script.js', __FILE__),
        array(
            'wp-blob',
            'wp-block-editor',
            'wp-blocks',
            'wp-components',
            'wp-compose',
            'wp-data',
            'wp-date',
            'wp-dom-ready',
            'wp-edit-post',   // this looks like the problem ??
            'wp-element',
            'wp-hooks',
            'wp-html-entities',
            'wp-i18n',
            'wp-keycodes',
            'wp-plugins',
        ),
        BGB_VERSION
    );
}

Replying to desrosj:

In 51393:

Widgets: Warn when wp-editor script or wp-edit-post style is enqueued in widgets editor

It is common that plugins erroneously have wp-editor or wp-edit-post as a
dependency in a script that is loaded in the new widgets editor. This is a smell
since both @wordpress/editor and @wordpress/edit-post assume the existence
of a global "post" object which the widgets editor does not have.

[51387] fixes the user-facing errors typically caused by this mistake, but we
can go a step further and warn developers about this by calling
_doing_it_wrong() when we detect that the wp-editor script or wp-edit-post
style is enqueued alongside wp-edit-widgets or wp-customize-widgets.

Props zieladam, spacedmonkey, TimothyBlynJacobs, andraganescu, dlh, noisysocks.
Merges [51388] to the 5.8 branch.
Fixes #53569. See #53437.

#18 follow-up: @ArtGoddess
3 years ago

Hi all, I'm afraid I still see this message.

With debug mode activated, I can see this PHP warning in /wp-admin/widgets.php:

<?php
Notice: wp_enqueue_script() was called incorrectly. "wp-editor" script should not be enqueued together with the new widgets editor (wp-edit-widgets or wp-customize-widgets). Please see Debugging in WordPress for more information. (This message was added in version 5.8.0.) in /home/user/domain.com/wp-includes/functions.php on line 5663

No plugins activated.

PHP 8
WordPress 5.8.2
Twenty Twenty-One 1.4
Twentig plugin 1.3.8

Last edited 3 years ago by ArtGoddess (previous) (diff)

This ticket was mentioned in Slack in #themereview by utz119. View the logs.


2 years ago

#20 in reply to: ↑ 18 @xshaz
2 years ago

I am experiencing this problem as well and wondering if a solution has been identified. My apologies if it is listed here already.

Thank you.

Replying to ArtGoddess:

Hi all, I'm afraid I still see this message.

With debug mode activated, I can see this PHP warning in /wp-admin/widgets.php:

<?php
Notice: wp_enqueue_script() was called incorrectly. "wp-editor" script should not be enqueued together with the new widgets editor (wp-edit-widgets or wp-customize-widgets). Please see Debugging in WordPress for more information. (This message was added in version 5.8.0.) in /home/user/domain.com/wp-includes/functions.php on line 5663

No plugins activated.

PHP 8
WordPress 5.8.2
Twenty Twenty-One 1.4
Twentig plugin 1.3.8

Note: See TracTickets for help on using tickets.