#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 )
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
@
4 years 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.
4 years ago
#2
- Keywords has-patch added
#4
@
4 years 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
@
4 years ago
@andraganescu I added test plan to the PR:
- Confirm the post and page editors are still full-screen and the admin sidebar remains hidden.
- 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
@
4 years 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
@
4 years ago
- Keywords 2nd-opinion dev-feedback removed
- Milestone changed from Awaiting Review to 5.6
#11
@
4 years 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.
This ticket was mentioned in PR #570 on WordPress/wordpress-develop by adamziel.
4 years ago
#12
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
#13
@
4 years ago
@frank-klein good note! See https://github.com/WordPress/wordpress-develop/pull/570
#16
@
4 years 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
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