[DO NOT MERGE] Use category registration utility file in the patterns dir #124
Conversation
…egistration calls to file
…k that register_block_pattern_category exists
…g logic to new function
…e core store to get registered categories instead of hydration
| // Add the utility file for custom category registration. | ||
| create_category_registration_file(); |
There was a problem hiding this comment.
The registration file is written to /patterns/utilities/ each time the pattern is saved to file.
Maybe there is a more efficient way to approach this kind of idea.
There was a problem hiding this comment.
Yeah, I think it's too much to maintain a separate utility file like this.
Also, it invites questions, like "Is it insecure that PM writes PHP to my theme?"
It's not insecure, but this is writing a lot of logic to PHP files.
I think a simple register_block_pattern_category() in a pattern file is fine.
But this is too abstract, in my opinion.
There was a problem hiding this comment.
Yeah you might be right — this might be getting a bit too abstract unnecessarily.
I like the idea of having a separate utility for this kind of thing, but we are actually writing this to themes, and a theme-maker might view this as being a bit overbearing.
There was a problem hiding this comment.
Still, it's cool to know this is possible!
| /** | ||
| * Module Name: Pattern Category Utilities | ||
| * Description: This module contains functions for registering custom pattern categories. | ||
| * Namespace: PmPatternCategoryUtilities | ||
| * | ||
| * @package pattern-manager | ||
| */ |
There was a problem hiding this comment.
This long of a header for the utility file might not be needed, but I do think it should be clear where the file came from (and that, ideally, it should not be deleted from the theme).
| /^pm_custom_category_/.test( | ||
| category.value | ||
| ); |
There was a problem hiding this comment.
Parsing to find which registered categories are custom (and from PM) is a bit tricky.
Initially, I tried adding another array item called pm_meta to the registration call, but querying registered categories from either the core data store (or via a PHP call to the category registry) does not always return the custom item.
Prepending the value (registered as name) with a custom string and checking against it has been the only reliable method I've found to fix this issue for now.
There was a problem hiding this comment.
The drawback to this method — if the utility file is deleted for some reason, custom category labels will be ugly.
|
Closed in favor of #123. |
This is a modified approach built off #123. Instead of directly inserting the pattern registration calls in pattern files, this PR uses a utility file.
With this PR, when adding custom categories, the added code in the pattern file would look something like this:
Inserting registration calls directly in the pattern file (a la #123) would look something like this instead:
No testing needed yet. This is intended as experimentation to see if something like this is worth pursuing.