Make WordPress Core

#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 20 months ago.
patch file

Download all attachments as: .zip

Change History (12)

@lovor
20 months ago

patch file

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


20 months ago

#2 @gziolo
20 months 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
20 months 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
20 months 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
20 months 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
20 months ago

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

#7 @gziolo
19 months 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
19 months 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
19 months 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 19 months ago by gziolo (previous) (diff)

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


19 months ago

#11 @audrasjb
19 months 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.