You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On the WordPress.org Pattern Directory, when you click on a category, the current community/curated and orderby GET parameters are not retained in the URL, causing the selected curation and sorting order to be lost.
Additionally, when performing a search, only the ?s= parameter is used, without including the curation and sorting order filters. The category links should append these parameters, and it's worth considering whether the search functionality should also retain them or not.
Detailed
On the WordPress.org Pattern Directory, there are four different filters available:
Category (e.g., "All", "Featured", "Posts", etc.)
Search (input field for searching patterns)
Curation (toggle between "Community" and "Curated")
Sorting Order (dropdown to select sorting, e.g., "Newest")
Currently, the curation (community/curated) and sorting order (orderby) filters are managed through GET parameters in the URL. However, there are a couple of issues with how these parameters are handled when interacting with the UI:
Category Links:
When a user clicks on a category (e.g., "Featured", "Text", etc.), the link navigates directly to the category page without appending the current community/curated and orderby GET parameters.
Expected Behavior: The category links should retain the current curation and sorting order parameters, appending them to the URL.
Search Functionality:
When a user performs a search, the current community/curated and orderby parameters are not added to the search query. The search query only uses the ?s= parameter.
Expected Behavior: It's debatable whether the curation and sorting order should persist in the search results. However, consistency would suggest these parameters should be preserved unless there's a strong reason not to.
Steps to Reproduce
Navigate to the WordPress.org Pattern Directory.
Apply a specific curation (e.g., "Community") and sorting order (e.g., "Newest").
Click on a category (e.g., "Text") or perform a search.
Expected Outcome
Category Links: The URL should include the current community/curated and orderby parameters along with the category slug.
Search Functionality: The URL should potentially include the community/curated and orderby parameters in addition to the ?s= parameter.
Actual Outcome
Category Links: The community/curated and orderby parameters are not appended, leading to a loss of the selected curation and sorting order.
Search Functionality: The search query also does not retainin the other filters.
Possible Solution
Update the links for categories to include the current community/curated and orderby GET parameters.
Consider whether the search functionality should also retain these parameters and update accordingly.
The text was updated successfully, but these errors were encountered:
Currently, this is intentional— the filters build as you move through the content, and clear if you apply something in a filter area before it. So you can select "Headers" then search "full width", but if you click "Footers" it clears the search. Same with the dropdown filters, you can apply those, but searching or selecting a category resets them.
This is how the filters work on all WordPress.org sites (Patterns, Themes, Showcase, etc), but there's been plenty of feedback. I've added this issue to the discussion WordPress/wporg-mu-plugins#603, where we've been collecting feedback for a future improvement.
Summary
On the WordPress.org Pattern Directory, when you click on a category, the current community/curated and orderby GET parameters are not retained in the URL, causing the selected curation and sorting order to be lost.
Additionally, when performing a search, only the ?s= parameter is used, without including the curation and sorting order filters. The category links should append these parameters, and it's worth considering whether the search functionality should also retain them or not.
Detailed
On the WordPress.org Pattern Directory, there are four different filters available:
Currently, the curation (community/curated) and sorting order (orderby) filters are managed through GET parameters in the URL. However, there are a couple of issues with how these parameters are handled when interacting with the UI:
Category Links:
When a user clicks on a category (e.g., "Featured", "Text", etc.), the link navigates directly to the category page without appending the current community/curated and orderby GET parameters.
Expected Behavior: The category links should retain the current curation and sorting order parameters, appending them to the URL.
Search Functionality:
When a user performs a search, the current community/curated and orderby parameters are not added to the search query. The search query only uses the ?s= parameter.
Expected Behavior: It's debatable whether the curation and sorting order should persist in the search results. However, consistency would suggest these parameters should be preserved unless there's a strong reason not to.
Steps to Reproduce
Navigate to the WordPress.org Pattern Directory.
Apply a specific curation (e.g., "Community") and sorting order (e.g., "Newest").
Click on a category (e.g., "Text") or perform a search.
Expected Outcome
Category Links: The URL should include the current community/curated and orderby parameters along with the category slug.
Search Functionality: The URL should potentially include the community/curated and orderby parameters in addition to the ?s= parameter.
Actual Outcome
Category Links: The community/curated and orderby parameters are not appended, leading to a loss of the selected curation and sorting order.
Search Functionality: The search query also does not retainin the other filters.
Possible Solution
Update the links for categories to include the current community/curated and orderby GET parameters.
Consider whether the search functionality should also retain these parameters and update accordingly.
The text was updated successfully, but these errors were encountered: