Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DataViews: Add sync filter in patterns page #57532
DataViews: Add sync filter in patterns page #57532
Changes from 2 commits
252a076
a8a3ce3
b86cbd2
5ed07e9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
How do I trigger a situation in which the category type is
PATTERN_TYPES.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.
To test
I see this new category is listed in the patterns page, though it works as any other:
Gravacao.do.ecra.2024-01-04.as.14.27.03.mov
Should I do anything differently?
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.
This is for later, but making
sync
visible and changing the listing hide the field (this is: the sidebar is not using the views yet, like the pages page).Gravacao.do.ecra.2024-01-04.as.14.32.12.mov
Though, this makes me think that I wouldn't want the
sync
field to be removed from the view. Consider the following case: a user is navigating through the categories to see what patterns are available, though they are only interested in "not synced" patterns:sync
field is shown in the layoutsync
filter is also shownWhat happens when the user visits a user-provided category and then a theme provided category?
The consequences are that 1) visual jumps in the layout and 2) the user preferences (hiddenFields and filter statuses) are cleared once they visit a user-provided category.
It sounds it's to always render the
sync
field and its filter.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.
Did you encountered something unexpected that is different from the old patterns page?
I'm not really sure but that param contains the value
wp_block
. Maybe @talldan or @aaronrobertshaw can shed some light here?We discussed this a bit with Riad here and for now we reset the whole view. It does resemble the
custom
views we have in pages list. We can revisit later if we need to..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.
I don't know, because I don't know how to trigger a situation where type is not
PATTERN_TYPES.thems
:)From what I gathered, my suggestion here is to always render the
sync-status
field and its filter.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.
Taking a look. What's confusing is there are two
PATTERN_TYPES
consts that seem to have different values.One is used in the inserter for inserter items:
gutenberg/packages/block-editor/src/components/inserter/block-patterns-tab/utils.js
Lines 7 to 14 in 6f61d8b
One is used by most of the other patterns code:
gutenberg/packages/patterns/src/constants.js
Lines 6 to 9 in 6f61d8b
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 the majority of the codebase uses the first variable, wherePATTERN_TYPES.user === 'user'
.It seems you're using the second variable where
PATTERN_TYPES.user === 'wp_block'
, it doesn't seem to be used much in the codebase.I think the first variable is the one you'll want to use, though I think it's still not great as the one object seems to mix and match lots of different concepts (syncing, pattern source, and I'm not sure what 'all' is).Ignore that, my assumption was wrong.
This definitely needs some improvement!
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.
So I think sometimes we're working with one kind of pattern item (where type isuser
) and other times a different type of item (where type iswp_block
).I've started looking into improving the code quality. First PR here - Rename patternBlock to patternPost
I've made another PR that renames the inserter constants to better indicate that they're for inserter items - Code Quality: Improve inserter pattern constants.
I think the goal should be to have a single normalized pattern item data structure (even if the data is sourced from different places) with consistent values, then hopefully we'll be able to tidy up the constants.
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.
I think I have a full understanding of what the code is doing now.
There's a
categoryType
sprinkled across the codebase, but this is purely for routing and can be one of two values,pattern
(for any time of pattern) orwp_template_part
(for template parts). It's confusing thatPATTERN_TYPES
is often used to check this in addition to being used to check the pattern item types. The category type values are also unusual with one being a post type and the other not.I'll follow up with another PR that improves this, but it'll be next week.
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, thanks for looking into this, Dan.