WordPress.org

Make WordPress Core

Opened 5 weeks ago

Closed 3 weeks ago

Last modified 3 weeks ago

#51330 closed enhancement (fixed)

Allow more granular control over enqueuing editor scripts and styles

Reported by: zieladam Owned by: zieladam
Milestone: 5.6 Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch
Focuses: Cc:

Description (last modified by zieladam)

As discussed in https://github.com/WordPress/gutenberg/issues/15644, block scripts and styles are being loaded only when $current_screen->is_block_editor() === true. The experimental widgets and navigation editor should provide access to custom block types but should not use a "block editor screen" mode which comes with more than just scripts and styles. In my opinion, having a way to control just the script&styles enqueuing aspect would be a good solution here.

See proposed solution in https://github.com/WordPress/wordpress-develop/pull/537

Change History (19)

#1 @zieladam
5 weeks ago

  • Component changed from General to Editor
  • Type changed from defect (bug) to enhancement

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


5 weeks ago

  • Keywords has-patch added

As discussed in https://github.com/WordPress/gutenberg/issues/15644, block scripts and styles are being loaded only when $current_screen->is_block_editor() === true. The experimental widgets and navigation editor should provide access to custom block types but should not use a "block editor screen" mode which comes with more than just scripts and styles. In my opinion, having a way to control just the script&styles enqueuing aspect would be a good solution here.

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

#3 @zieladam
5 weeks ago

  • Description modified (diff)

#4 @andraganescu
5 weeks ago

  • Keywords 2nd-opinion dev-feedback added

IMO adding more granularity is only a good thing in a future with more editors in the wp-admin so this is a needed filter.

@zieladam could you share steps to test the effect of this change?

#5 @zieladam
5 weeks ago

@andraganescu I added test plan to the PR:

  1. Confirm the post and page editors are still full-screen and the admin sidebar remains hidden.
  2. Confirm the widgets and navigation editors are unchanged after applying this PR - they should NOT be full-screen editors and the admin sidebar should remain visible.

#6 @noisysocks
4 weeks ago

Hey @zieladam. The PR works great in my testing. Just one minor note about whether or not to make the function a part of the public API.

#7 @noisysocks
4 weeks ago

  • Keywords 2nd-opinion dev-feedback removed
  • Milestone changed from Awaiting Review to 5.6

#8 @noisysocks
4 weeks ago

In 49080:

Editor: Add should_load_block_editor_scripts_and_styles

Adds a new should_load_block_editor_scripts_and_styles filter which can be used
by plugins including Gutenberg to more precisely customise when block editor
scripts and styles should be loaded by script-loader.php. Previously, plugins
had to fiddle with $current_screen->is_block_editor().

Props zieladam.
See #51330.

#9 @noisysocks
4 weeks ago

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

#10 @SergeyBiryukov
4 weeks ago

In 49081:

Docs: Add missing @since entry for _should_load_block_editor_scripts_and_styles().

Follow-up to [49080].

See #51330.

#11 @Frank Klein
3 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Thanks for working on this, because _should_load_block_editor_scripts_and_styles is an improvement over having to check WP_Screen:: is_block_editor. Especially because is_block_editor() is poorly designed, see https://core.trac.wordpress.org/ticket/45037#comment:21.

But is_block_editor is a public method, and therefore a public API. The newly introduced function on the other hand is private--and there's no reason for that. It's only a getter function with a filter, and should therefore follow the established WordPress pattern of being public.

Last edited 3 weeks ago by Frank Klein (previous) (diff)

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


3 weeks ago

https://github.com/WordPress/wordpress-develop/pull/537 introduced the _should_load_block_editor_scripts_and_styles function. While it got generally good feedback, one comment noted it would be useful to make it a public function. This PR does just that.

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

#14 @noisysocks
3 weeks ago

In 49093:

Editor: Rename _should_load_block_editor_scripts_and_styles to wp_should_load_block_editor_scripts_and_styles

Follow-up to [49080].
Props zieladam, frank-klein.
See #51330.

#15 @noisysocks
3 weeks ago

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

#16 @noisysocks
3 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

We should not call should_load_block_editor_scripts_and_styles on non-admin screens. Doing so makes it easy to introduce errors such as this one:

https://github.com/WordPress/gutenberg/pull/25826#issuecomment-705252901

#17 @noisysocks
3 weeks ago

In 49102:

Editor: Only call should_load_block_editor_scripts_and_styles on admin screens

Do not call the should_load_block_editor_scripts_and_styles filter on non-admin
screens. This makes it less likely that one will accidentally call
get_current_screen() when it doesn't exist.

Follow-up to [49080].
Props noahtallen.
See #51330.

#18 @noisysocks
3 weeks ago

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

#19 @noisysocks
3 weeks ago

In 49104:

Tests: Fix dependency tests

Fixes test_block_styles_for_editing_with_theme_support and
test_block_styles_for_viewing_with_theme_support by partially reverting [49102]
and only calling wp_should_load_block_editor_scripts_and_styles() when on an
admin screen.

Props TimothyBlynJacobs.
See #51330.

Note: See TracTickets for help on using tickets.