Skip to content
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

Data views: Editing default views can lead to awkward results #56204

Closed
jameskoster opened this issue Nov 16, 2023 · 4 comments
Closed

Data views: Editing default views can lead to awkward results #56204

jameskoster opened this issue Nov 16, 2023 · 4 comments
Labels
[Feature] Data Views Work surrounding upgrading and evolving views in the site editor and beyond Needs Design Needs design efforts. [Type] Enhancement A suggestion for improvement.

Comments

@jameskoster
Copy link
Contributor

jameskoster commented Nov 16, 2023

Currently it's possible to go to the bundled Trash view in Pages and change the status filter. It's also possible to click the 'Reset filters' button to remove the status filter altogether.

Screenshot 2023-11-16 at 13 00 59

In the screenshot above it's strange for "Trash" to be highlighted in the Navigation, and for the corresponding view to show only published pages.

A couple of potential solutions:

  1. Lock filters for default views. IE when viewing Trash it is not possible to change (or reset) the status filter. This would be closest to the wp-admin implementation.
  2. Sync the Navigation and the state of the current view. For instance if you viewed Trash and changed the status filter to draft then "Drafts" becomes active in the sidebar.

The first approach seems simpler. The second would be more involved in terms of design as we'd need to think about how to represent unsaved view configurations in the sidebar.

cc @ntsekouras @jorgefilipecosta @youknowriad @oandregal @WordPress/gutenberg-design for thoughts on this.

@jameskoster jameskoster added [Type] Enhancement A suggestion for improvement. Needs Design Needs design efforts. [Feature] Data Views Work surrounding upgrading and evolving views in the site editor and beyond labels Nov 16, 2023
@youknowriad
Copy link
Contributor

I agree that we need to do better now. That said, I don't think the solutions are satisfying for me, for a few reasons. I think before coming up with solutions to this potentially confusing behavior, we need to first understand and implement the full store about the "default views". In other words, answer questions like:

  • Who provides the default views?
  • Can plugins provide extra default views? and what would the API look like?
  • Do we want to allow saving changes to these default views (like for instance allowing switching to grid and saving...)? If yes, how do we handle core and/or plugin updates. What happens if the default view is updated and we have a modified saved view.

The other thing that is important is that, the same issue about filter can actually apply to any property (not just filters). For instance I can see us providing a "grid" default view and a "list" one (maybe not for pages but this could happen). In that case, what's the story: It can be as confusing to switch "grid" to "table".

And the solution to "compare" the view with its definition to mark it active or not is not good either because a view that is named "drafts" should probably rename active when you switch its layout from "grid" to "table" but a view that is named "post grid" should probably do. In that sense, there's no possible way to generalize this comparison.

@ntsekouras
Copy link
Contributor

ntsekouras commented Nov 16, 2023

I agree with Riad and personally I'm not seeing much value to these drafts or trash views. Like Riad mentions, even with a custom created view, the name could be misleading after saving some more changes in the future.

Maybe we don't need these views at all and only provide the all view, in conjunction with the ability for users to create custom views. For plugins maybe we could provide a way to register a view that users cannot edit at all - a fixed specialized view.

@jameskoster
Copy link
Contributor Author

jameskoster commented Nov 16, 2023

Good questions.

I feel there is a reasonable case for additional default views beyond "All". Status is a good example because it exists right now, there's also comment management where providing a 'Pending' view seems standard. That said, they don't necessarily need to be hard-coded defaults per the current setup – perhaps there's an on-boarding experience where users install 'recommended custom views'. Edit: Or they could be installed automatically when WP is installed or updated.

Whether plugins can extend or modify the default views... I imagine that level of flexibility would be useful in some circumstances but it's hard to say for sure. I don't know if it's 100% relevant to this, but I can imagine plugins providing default views for CPTs they register, and that they might want to allow plugins to extend those views. Product type in Woo is a good example – if you install an extension that adds a new type of product, it might be handy for that extension to also add a view to the main products list.

Do we want to allow saving changes to these default views (like for instance allowing switching to grid and saving...)?

I would imagine that saving a default view would essentially result in a new custom view. A bit like editing patterns/templates. We might provide a shortcut to "Duplicate and edit" default views.

There's also a question about whether view options like layout and filters are saved together, or if they're separate. For example in wp-admin screen options persist while filters reset between sessions.

I'd love to get @SaxonF's thoughts on this.

@jameskoster
Copy link
Contributor Author

Closing, better tracked in #60468

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Data Views Work surrounding upgrading and evolving views in the site editor and beyond Needs Design Needs design efforts. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

3 participants