Allow patterns files to be divided into sub folders inside the main "patterns" folder

[juanfra]

Copy of ​https://github.com/WordPress/gutenberg/issues/50144 - Opening this ticket as the changes need to happen in core.

What problem does this address?

With a growing number of patterns inside a theme, dealing with a long list of files inside the "patterns" folder is becoming inconvenient.

What is your proposed solution?

Allowing the organization of the patterns in sub-folders. For example, all header patterns are added to the "header" folder, all footer patterns into the "footer" folder, testimonials patterns into the "testimonials" folder, and so on.

Trac ticket: https://core.trac.wordpress.org/ticket/62378
Gutenberg issue: ​https://github.com/WordPress/gutenberg/issues/50144

---
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See ​GitHub Pull Requests for Code Review in the Core Handbook for more details.

Description

I'm changing the initial $dirpath to avoid having the trailing slash, as the file exist can behave differently in different file systems.

Then, I'm making use of the static method scandir to check for php files in the directory recursively. Finally, adding the trailing slash so that this ​str_replace leaves only the required slashes in the $pattern_data array.

I followed the testing instructions and the update works well for me.
In addition, I moved some existing patterns to different nested subfolders, without issues.

• [x] Templates or other patterns that includes the patterns that were moved still works
• [x] The patterns are listed in the inserter
• [x] The patterns are listed in the pattern DataViews
• [x] The patterns can be duplicated from the pattern DataViews

I would love to see this PR get merged!

[poena]

@flixos90 @mukesh27
I would like to hear if there are any blocking performance concerns with this proposed change or if there are any additional changes needed, for example any changes related to the caching of the patterns.

Any updates here? This seems to be a lightweight feature to be added, once that theme developers would love.

[poena]

@juanfra Is there a reason why the dirpath is only updated in get_block_patterns, not _register_theme_block_patterns?

@bgardner All the reviews and commits etc are public, if you don't see any updates then there are none :)

[juanfra]

@poena There were a few reasons for making this change in get_block_patterns():

• Calling scandir with a trailing slash causes it to include the slash in the array index (e.g., $array['/my-pattern.php']), which could lead to unexpected issues.
• It checks whether the ​dirpath exists, and on certain rare filesystems, this can behave unpredictably.

To address this, I thought it was safer to leave scandir() as it is and instead adjust the $dirpath in the relevant part of the get_block_patterns() method. This approach avoids additional implications, as the trailing slash is added immediately after the scandir() call.

Regarding _register_theme_block_patterns(), it looks like $dirpath is only used to concatenate and store the pattern filename, not to check if the directory exists. If we also want to modify $dirpath there, we’d need to add the slash when generating the $file_path a ​few lines later in the foreach loop.

[flixos90]

@poena I think supporting subdirectories of the patterns directory sounds reasonable, also from a performance perspective.

Any potential overhead it might add should be very small, and the performance optimizations for this should be made at another point in the system anyway, e.g. at the caching layer.

[audrasjb]

As per today's bug scrub: since 6.8 beta 1 is next week, let's move this ticket to milestone 6.9 to ensure it can ship on Gutenberg'side and be tested before final commit.

[audrasjb]

(if the proposed patch can be successfully tested in the next couple days, please feel free to move it back to milestone 6.8)

[joemcgill]

Just tested this since it only requires changes to the logic in WP_Theme::get_block_patterns(). Waiting for tests to pass again and I'll handle committing this change.

I will look into refreshing the Gutenberg compatibility PR.

I will look into refreshing the Gutenberg compatibility PR.

get_block_patterns() is in a class that is marked as Final.
The only way I believe I would be able to update the path in Gutenberg, is by replacing _register_theme_block_patterns.
I asked about this function in the Trac ticket earlier, https://core.trac.wordpress.org/ticket/62378#comment:8
and I am reading the response as that change should be made to _register_theme_block_patterns.

But I think the only consequence of doing nothing in Gutenberg, is that patterns that are in subfolders will not work if Gutenberg is active on WP 6.6 and 6.7. Right? There would not be a regression, and there would not be an issue if Gutenberg is activated on WP 6.8 + either?

@carolinan I don't think anything should need to be updated in the GB repo as this is only changing the behavior of the method of the WP_Theme method, so as soon as this is merged, any site running GB on WP trunk should have the same behavior. _register_theme_block_patterns() makes use of the WP_Theme::get_block_patters() method to retrieve the file path, so I don't think any changes are needed there either. Is there something that I'm missing that you're concerned wont be addressed once this is merged?

But I think the only consequence of doing nothing in Gutenberg, is that patterns that are in subfolders will not work if Gutenberg is active on WP 6.6 and 6.7. Right? There would not be a regression, and there would not be an issue if Gutenberg is activated on WP 6.8 + either?

This is correct. Without a shim of some sort (e.g., a filter, etc.) Only WP 6.8+ will support patterns in folders.

Is there something that I'm missing that you're concerned wont be addressed once this is merged?

No :)

This is correct. Without a shim of some sort (e.g., a filter, etc.) Only WP 6.8+ will support patterns in folders.

I think that is perfectly fine

[joemcgill]

In 59872:

Themes: Allow pattern files to be organized into sub-folders.

This allows theme pattern files located in a theme's /patterns/ directory to be organized into sub-folders and will automatically be located by WP_Theme::get_block_patterns() method.

Props juanfra, joemcgill, poena, flixos90.
Fixes #62378.

[webmandesign]

Hi,

Since testing WP6.8 RC1 I get this PHP notice:

Notice:
Function get_block_patterns was called incorrectly.
Could not register file "./themes/theme-slug/patterns/affected/file.php" as a block pattern ("Slug" field missing)
Please see Debugging in WordPress for more information.
(This message was added in version 6.0.0.) in ./wp-includes/functions.php on line 6121

Could you please modify the code to skip all PHP files without "Slug" defined in theme-slug/patterns folder?

As maybe that file is not a pattern registration file on purpose.
That way the notice is not triggered.

---

My usecase for explanation:

In my theme I register most of the patterns with proper file metadata.

However, one of the patterns runs dynamic PHP code that has to be registered later on front-end (during wp action hook) to receive proper data from WordPress. I need to register this pattern using PHP ​`register_block_pattern()` function instead of setting the pattern file metadata.

To fix the new WP6.8 PHP notice I would need to move the affected pattern from patterns/ folder to other folder, such as patterns-other/, which creates inconsistency in my theme code organization.

Another alternative solution for me would be to register all patterns with register_block_pattern() function and not use patterns/ folder at all...

Pre-WP6.8 solution was to have pattern files with metadata as direct children of patterns/ folder and use subfolders for the patterns registered via register_block_pattern() function.

---

Please let me know if this is the correct place to ask for this or whether I should log a new ticket for this improvement to be included in WP6.8 release. Thank you.

[webmandesign]

FYI: I've logged #63212 for my issue.