Opened 14 months ago

Last modified 3 months ago

#20335 new enhancement

Make Default Post Listing Mode Filterable

Reported by: ericmann Owned by:
Priority: normal Milestone: Awaiting Review
Component: Administration Version: 3.3.1
Severity: trivial Keywords: has-patch
Cc: mike@…, xoodrew@…

Description

Inspired by a question on the WordPress Answers Stack Exchange.

By default, WordPress displays the post list in the admin as a list view. There's an option to switch to an excerpt view that many people use and some would like to set this as the default mode.

Unfortunately, the default is hard-coded into WordPress and is not filterable. I propose we add a basic filter to allow developers to override the default "list" setting for the view mode.

Attachments (3)

20335.diff (616 bytes) - added by ericmann 14 months ago.
Filter the default mode for the posts list table.
20335-2.diff (801 bytes) - added by ericmann 14 months ago.
Check/set a user option.
20335-3.patch (732 bytes) - added by azaozz 14 months ago.

Download all attachments as: .zip

Change History (11)

Filter the default mode for the posts list table.

comment:1 follow-up: ↓ 2   jane14 months ago

This is really a personal preference, just like rearranging dashboard widgets, using Visual editor or HTML tab, or hiding columns in list view, which is why it should remember the user's choice (so they only ever hit excerpt once). Is there a reason make this more of a developer choice instead of a user choice? At that point, would think the request would be for filters on everything that is currently a user view choice?

comment:2 in reply to: ↑ 1   ericmann14 months ago

Replying to jane:

It should remember the user's choice (so they only ever hit excerpt once).

I'm in agreement with you on this point.

Is there a reason make this more of a developer choice instead of a user choice? At that point, would think the request would be for filters on everything that is currently a user view choice?

In context, I was approaching this from the perspective of a developer setting up the initial environment for a client. But from a user perspective I think having persistent, user-based defaults would be a better approach. I'll revisit this after I have some time to think about a cleaner implementation than just calling get_user_meta() on everything.

This is really a personal preference, just like rearranging dashboard widgets, using Visual editor or HTML tab, or hiding columns in list view, which is why it should remember the user's choice (so they only ever hit excerpt once).

Yeah, what's weird with the list/excerpt choice is that it doesn't remember the user's choice. It certainly should. Turning in into a proper user option is all developers will need to be able to hook in and do what they wish. Though, there should probably be some hooks available as well, because some post type screens may wish to force one or the other just based on how that post type may be stored.

OK, I'm sold on making this a user option. New patch checks for a user option if "mode" isn't passed in as a query arg. If it is, the user option is updated.

Devs can still filter on the user option if they want, but it's not required.

Check/set a user option.

  • Cc mike@… added

+1 on this user option patch

Agree with @nacin that hooks are needed too, but this seems like it could be added cleanly now. Could hooks could be planned & added in a different ticket?

  • Cc xoodrew@… added

Perhaps better to use the "user_settings" API for this, that's the "proper" place for storing these settings and it would make that available/changeable from JS if we ever need it.

20335-3.patch is similar to 20335-2.diff but uses the user_settings API and doesn't store the $_REQUEST value directly (security is always a good thing :) ).

related #22222

Note: See TracTickets for help on using tickets.