Make WordPress Core

Opened 3 years ago

Closed 2 years ago

#56470 closed defect (bug) (fixed)

viewScript setting does not set front end scripts for dynamic blocks

Reported by: lovor's profile lovor Owned by:
Milestone: 6.1 Priority: normal
Severity: normal Version: 6.1
Component: Script Loader Keywords: has-patch needs-testing needs-dev-note
Focuses: ui, javascript, administration Cc:

Description

I discovered that in dynamic blocks viewScript does not work (i.e. does not enqueue script in front end). I discovered a code responsible in class-wp-block.php and attached proposed removal of condition that prevented loading frontend script for dynamic blocks.

I see no reason that front end scripts should be prevented for dynamic blocks.

Attachments (1)

remove_viewScript_constraint.diff (529 bytes) - added by lovor 3 years ago.
patch file

Download all attachments as: .zip

Change History (12)

@lovor
3 years ago

patch file

This ticket was mentioned in Slack in #core-editor by lovor. View the logs.


3 years ago

#2 @gziolo
3 years ago

I agree it's confusing because it doesn't work like that for the script in block.json. The best way to move forward is to allow customizations for assets in block.json as explained in https://core.trac.wordpress.org/ticket/54018#comment:5 and align the default behavior that existed for the script. This way, block authors could still opt in to defer to render_callback when the script should get enqueued.

#3 @lovor
3 years ago

I am not sure if I follow you. Do you propose to align behaviour of script and viewScript in block.json to be the same for dynamic and static blocks (that is my idea) or you think both script and viewScript should be disabled for dynamic blocks?

#4 @gziolo
3 years ago

  • Focuses css removed

Do you propose to align behaviour of script and viewScript in block.json to be the same for dynamic and static blocks (that is my idea)

Yes, your idea.

#5 @lovor
3 years ago

No, sorry, I am not a native speaker, I did not mean to communicate my ownership of idea, just to signal that I am inclined to that solution.

#6 @gziolo
3 years ago

No worries @lovor. We are both inclined to pivot to that approach. I like that idea.

#7 @gziolo
2 years ago

@davidbaumwald, I'm reporting that [54367] effectively resolves this issue. It will have to be included in the dev note for Block API changes in WordPress 6.1. We should also update the following section in the documentation:

https://github.com/WordPress/gutenberg/blob/trunk/docs/reference-guides/block-api/block-metadata.md#frontend-enqueueing

In particular, the following section must be updated to reflect the changes applied:

viewScript (when the block defines render_callback during registration in PHP or a render field in its block.json, then the script is registered but the block author is responsible for enqueuing it)

#8 @davidbaumwald
2 years ago

  • Keywords needs-dev-note added
  • Milestone changed from Awaiting Review to 6.1

@gziolo Thanks for the report! I'm tagging for a Dev Note to ensure this is picked up by the Docs leads for 6.1.

#9 @gziolo
2 years ago

I started the dev note for Block API changes in WordPress 6.1:
https://make.wordpress.org/core/wp-admin/post.php?post=98762&action=edit

@bph and @milana_cap, we could include the note about changes from this ticket in the "Allow registering multiple items for all supported asset types" section.

Last edited 2 years ago by gziolo (previous) (diff)

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


2 years ago

#11 @audrasjb
2 years ago

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

Let's close this ticket as fixed, since the issue was fixed with changeset [54367].

Thanks everyone!

Note: See TracTickets for help on using tickets.