Universal listings (search and filtering) #10446
Replies: 15 comments 17 replies
-
That looks really really good! |
Beta Was this translation helpful? Give feedback.
-
Yes please! |
Beta Was this translation helpful? Give feedback.
-
Superb :) Request for multi-lingual sites - please add 'results limited to current listed locale' in considerations. Thanks! |
Beta Was this translation helpful? Give feedback.
-
This is looking superb @benenright! Especially loving the filters 😍! A couple of thoughts that occurred to me are:
|
Beta Was this translation helpful? Give feedback.
-
I like this! I have a site that doesn't have a particularly main content tree but we do have years of imported news and events pages so we have built custom versions of what you are proposing here (though not as nice because I don't have your design skilz). From that perspective, it would be great if the filtering component were configurable since sites like ours will have immediate uses for custom filters - and because all snippet listings that eventually use this will want to set up their own filtering options. |
Beta Was this translation helpful? Give feedback.
-
Just thought of another challenge that isn't explicitly addressed in the designs so far... What does the switch between "only show children of the current explorable page" and "show matches from anywhere" look like? And how does that work for multisite / translated projects? Maybe we need two completely separate "Page explorer" and "All pages" menu items, and the latter would go to somewhere with a completely different header and site / language filters? |
Beta Was this translation helpful? Give feedback.
-
Just wanted to capture another use case we discussed with colleagues today (cc @helenb) – for QA purposes, it’s really common to need to find a page of a given page type. And potentially doing that for multiple page types. I believe the current designs as proposed would cater for that scenario well – go to the root level, filter by page type, pick the first one. But it’s such a common scenario I thought it’d be worth mentioning anyway. |
Beta Was this translation helpful? Give feedback.
-
Another use case from us, we have a site where the page tree is not very relevant: some editorial pages like "Legal mentions" and another page-based model (a bit like landing pages) for which we want page features like workflow, previewing, and so on, along with our business configuration. In our case the Page explorer is too far-fetched for this kind of site structure so we would love to get rid of it entirely. So far we are stuck with it, but by using ModelAdmin we have a kind of basic list so this feature would help a lot. |
Beta Was this translation helpful? Give feedback.
-
Hi folks, I've just submitted a PR for a new built-in report focusing on page types, which answers the following questions:
It can also show a list of all the pages of a particular type. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Just a note that a request has come up to add "is a parent page or not" to the set of filtering options. (That should be a simple one to implement - filter on the 'numchild' field being greater than 0.) |
Beta Was this translation helpful? Give feedback.
-
Discussed this week with Ben – it’d be nice to have a way to view the "treeless" version of a specific view without having to trigger a search or applying a filter. For example, if I’d like to see all of the site’s pages. |
Beta Was this translation helpful? Give feedback.
-
Not sure if this is the right place for this - It would be a great boost in UX if the current view settings were retained after performing an action on the listing page. This applies to all the listing views I've seen so far (i.e. pages, snippets, users, forms ...). Currently, after performing an action, the returned page is the first page of the default view. This can be quite frustrating when you've got a filtered, ordered or paginated view you're working with. The view could be all pages created after X, user list sorted by last login date or page x of submitted forms for instance. Ideally, you'd want all those attributes of the view retained after performing the menu action (delete, unpublish etc.). |
Beta Was this translation helpful? Give feedback.
-
Hi all, Per the Migrating from ModelAdmin to Snippets guide:
I'm not clear where we're at based on this thread. I can see that it's possible to filter by page type in Universal Listings but it's not clear to me how one would replicate the ModelAdmin functionality of creating a custom menu item e.g., Marketing -> Blog Posts so that staff can jump right to the page types that matter to them. Another use case we could handle with ModelAdmin was to add custom filters to this index view. For example, the Blog Posts ModelAdmin might have Blog Category filters on the right. With Universal Listings, the filters appear to be limited to fields that are common to all page types. Is the solution to make a custom view/template and wire up the URL(s) using |
Beta Was this translation helpful? Give feedback.
-
Tracking the progress to date on universal listings:
Here is the work we believe still remains. Sharing this as a table rather than GitHub issues as we’ve not specified exactly what needs to happen beyond the high-level task label
@laymonage is keen to do quite a bit of this but we’re leaving open the exact time frame for now. |
Beta Was this translation helpful? Give feedback.
-
Summary
Exploring design solutions for making sites / sections with 1000s of pages and little to no tree structure easier to navigate in the CMS.
The aim is to enhance the searching / filtering capabilities of the main page listing view (and to eventually roll out the same patterns and functionality to all listings within the CMS).
Background
Considerations
Design approach
Default page listing
Search results
Item hover state
Filter dialogs
Filter pills
Save view
Open questions
Welcome all feedback and thoughts people would like to contribute.
Beta Was this translation helpful? Give feedback.
All reactions