Make WordPress Core

Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#53565 closed defect (bug) (duplicate)

Split packages and blocks into separate Weback configs

Reported by: desrosj's profile desrosj Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords: has-patch
Focuses: Cc:

Description

This was originally attempted in [51259] on #53397, but there were some issues that warranted a revert before packaging 5.8 RC1 (see [51268]).

WordPress/wordpress-develop-1412 was used to build the patch applied in [51259]. From @gziolo on that PR:

We need to add handling for JavaScript files that are going to be used with blocks on the frontend. They don't work quite well with the current setup for entry points created for packages because of reasons like

  • the output path is different
  • frontend scripts should not be exposed under wp globals

In general, it looks like the split is a good strategy because it nicely separates two independents parts: packages and blocks. There isn't that much overlap between configs anyway.

After committing, the following notice was seen in Core when visiting a page with a core/file block:

Notice: register_block_script_handle was called incorrectly. The asset file for the "viewScript" defined in "core/file" block definition is missing. Please see Debugging in WordPress for more information. (This message was added in version 5.5.0.) in /var/www/src/wp-includes/functions.php on line 5535

An attempt was made to fix this in [51267]. This appeared to fix the issue when visiting the site. However, automated tests still displayed the notice, and it caused failures in some environments. This was also reverted.

Gutenberg-33082 was opened as a follow up to the attempted fix, but after looking further, the lines being changed may have an intentional reason to be how they are.

Change History (6)

#1 @SergeyBiryukov
3 years ago

Just noting that I'm currently seeing these notices in WordPress trunk with Gutenberg 11.2.1 active:

Notice: register_block_script_handle was called incorrectly. The asset file for the "viewScript" defined in "core/file" block definition is missing. Please see Debugging in WordPress for more information. (This message was added in version 5.5.0.) in S:\home\wordpress.test\develop\build\wp-includes\functions.php on line 5537

Notice: register_block_script_handle was called incorrectly. The asset file for the "viewScript" defined in "core/navigation" block definition is missing. Please see Debugging in WordPress for more information. (This message was added in version 5.5.0.) in S:\home\wordpress.test\develop\build\wp-includes\functions.php on line 5537

It looks like core/file and core/navigation are the only two blocks that have a viewScript defined:

"viewScript": "file:./view.min.js"

Pretty much like in comment:44:ticket:53397, I've tracked this down to register_block_script_handle():

  • $script_asset_path is assigned the value returned by realpath() on this path: S:\home\wordpress.test\develop\build\wp-content\plugins\gutenberg\build\block-library\blocks/file/./view.min.asset.php
  • realpath() returns false, because the file does not exist.
  • The file_exists() check below also returns false.

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


2 years ago

#3 follow-up: @gziolo
2 years ago

The bug report shared by @SergeyBiryukov should be fixed in #55311.

#4 @gziolo
2 years ago

By the way, this issue can be closed because we were able to split the webpack config in WordPress 5.9 release cycle. Relate commit [51501]. Related track issue #53690.

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

#5 @gziolo
2 years ago

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

#6 in reply to: ↑ 3 @SergeyBiryukov
2 years ago

  • Milestone Future Release deleted
  • Resolution changed from fixed to duplicate

Replying to gziolo:

The bug report shared by @SergeyBiryukov should be fixed in #55311.

Perfect, thanks!

Seems like this one can be closed as a duplicate of #53690 then.

Note: See TracTickets for help on using tickets.