-
Notifications
You must be signed in to change notification settings - Fork 6
Allow adding new categories in Editor UI #123
Conversation
…egistration calls to file
…k that register_block_pattern_category exists
$formatted_registration_string = "if ( function_exists( 'register_block_pattern_category' ) ) { | ||
" . implode( "\n ", $custom_category_registrations ) . ' | ||
}'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here — this is ugly but should allow linting to pass for the user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any time register_block_pattern_category()
isn't defined?
It was introduced in WP 5.5.0.
Though maybe its file wasn't included when this code runs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good question!
My thinking was that we can't really know what version of WP an end-user of the theme might be using, but it's possible that we don't need to even worry about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, if it's only a question of the WP version, I think we can assume they have 5.5 or later.
PM requires 6.2
(though even then, it shouldn't require 6.2, as it's not released).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like register_block_pattern
was also introduced in 5.5.
Maybe it's worth investigating if the patterns
directory is even checked for versions older than that. If they aren't, there is no reason to leave this check imo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upon investigating this further by testing with 5.4.12 — the registration block should not need to check that either WP_Block_Pattern_Categories_Registry
or register_block_pattern_category()
exists before calling them.
Both were introduced in WP 5.5, and previous versions of WP do not glob the patterns
folder in a given theme.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good find!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @mike-day,
This approach looks good. It'd be nice to simplify the JS logic if possible, but this is a high-level review.
Pro
- Single source of truth (PHP file). That's a huge plus.
- This works even without PM active, like you showed.
- By registering the custom category in the pattern's PHP file, a custom category only has to know about its own custom categories. If we registered all custom categories in a
categories.php
file, we'd have to tree shake unused categories after every save. It'd be much more complex.
Con
- The JS logic here is really complex and untestable. Maybe it's too early to judge that, though 😄
- Every pattern a user edits will have a 'Custom Categories' value in the header, even if they didn't add one. They might wonder why. Still, we could work on avoiding that.
Great feedback, @kienstra! As for |
Great feedback, @kienstra!
Yeah, that sounds good. It's only a minor criticism. We could also refactor how we output the pattern file headers. |
Are you ready for feedback on whether this should check whether a category is already registered, and conditionally register it? (Not implementation details, but the idea of whether it should have a conditional.) Don't want to nitpick if it's too early. |
It might be a bit early! I just tried building from this PR to use a utility file instead of inserting registration calls in the pattern file with #124. We also might want to try Mike's idea as an alternative as well. My thought is that we can try a few proof-of-concept methods like this to gauge if it's worth pursuing custom category registration at all — it's going to add complexity to the app no matter what. |
Sounds good! |
…e core store to get registered categories instead of hydration
@kienstra I made a few small changes (including using a prepend with the new category Let's get into the conversation around checking against the category registry! We don't really need to check against the registry. Core will only register a given pattern category once, regardless of how many times that call is made. We could get rid of some boilerplate if we didn't make that check. On the other hand, it's hard to know whether that behavior in core is a feature or a bug. Otherwise, it does feel "right" to me to conditionally register, but I can't really articulate why. |
That's a good point. Let me think about this. |
Looking at the Instead, if the name of the new category matches an existing category, the existing category is simply overwritten: $category = array_merge(
array( 'name' => $category_name ),
$category_properties
);
$this->registered_categories[ $category_name ] = $category; So, while it initially appears that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @mike-day,
The tests look really good. Very good coverage, and good work extracting into pure functions.
( matchedCategory ) => | ||
matchedCategory.value === category | ||
) | ||
value={ getSelectedOptions( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice extraction to a pure function
/** | ||
* Tests maybe_add_custom_category_header. | ||
*/ | ||
public function test_maybe_add_custom_category_header() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice test. It's simple, but covers the 2 important cases: where there is a header, and there isn't.
$this->normalize( create_formatted_category_registrations( $custom_categories ) ), | ||
); | ||
|
||
$this->assertEmpty( create_formatted_category_registrations( [] ) ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another nice test. It's simple, and covers the main cases.
|
||
return $custom_category_registrations; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a future PR, let's split this file into another. It's getting long.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed — we could clean up this file dramatically by splitting things up.
[ 'Second Category', 'Third Category' ], | ||
], | ||
] )( | ||
'should get the custom categories created by Pattern Manager', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice test coverage, from []
, to matched categories that don't have pm_custom
, to matched categories that do have pm_custom
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @mike-day,
The tests look really good. Very good coverage, and good work extracting into pure functions.
…into try/add-new-categories-in-editor-ui
…into try/add-new-categories-in-editor-ui
This is really impressive @mike-day! I've found a bug which we might want to fix. The desired intention is that custom categories registered in a theme do not get written to a pattern file. But they do in this scenario:
I think to fix this, we'll need to add some logic to the |
Upon digging into this, it's a bit harder than I first thought. Because pattern files are actually being |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since trying to prevent category registration has only cosmetic benefits right now, I think we can merge this as-is.
…into try/add-new-categories-in-editor-ui
Sorry, I accidentally merged #199. Reverting now. |
Sorry, I won't commit to this PR anymore. Just wanted to undo my accidental merge of #199. |
…-input Validate new categories on input
…into try/add-new-categories-in-editor-ui
This PR allows the registration of custom pattern categories from within the editor UI.
Add a new category by simply typing in the categories dropdown.
Note: this PR should probably not be merged until #175, #177, and #180 are merged.
Registration is done in the pattern file itself, with the registration calls added just below the pattern header:
Using this method is almost akin to each pattern file being kind of like its own tiny plugin, with no patterns relying on each other for registration and each remaining their own source of truth.