Make WordPress Core

Opened 5 years ago

Last modified 17 months ago

#39666 new enhancement

Put front page on top of "All pages" list

Reported by: Presskopp Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: needs-patch dev-feedback 2nd-opinion
Focuses: administration Cc:


I'd like to see the front page and blog page as first elements in the pages list (if such are set of course), no matter what priority they may have.

What do you think?

Screenshot follows.

Attachments (6)

pages.jpg (108.3 KB) - added by Presskopp 5 years ago.
home_blog_yellow.jpg (30.4 KB) - added by Presskopp 4 years ago.
homepage-postspage-example.jpg (17.4 KB) - added by birgire 4 years ago.
39666.patch (1.3 KB) - added by toddhalfpenny 3 years ago.
Screenshot from 2018-04-14 16:04:45.png (27.7 KB) - added by toddhalfpenny 3 years ago.
Showing with date filter
Screenshot from 2018-04-14 16:04:28.png (33.2 KB) - added by toddhalfpenny 3 years ago.
Without a date filter

Download all attachments as: .zip

Change History (21)

5 years ago

#1 @SergeyBiryukov
5 years ago

  • Component changed from Administration to Posts, Post Types
  • Focuses administration added

#2 @lukecavanagh
5 years ago


Makes sense to give those post ID when defined as that, priority in the page list on load.

This ticket was mentioned in Slack in #core by presskopp. View the logs.

4 years ago

#4 @SergeyBiryukov
4 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

#5 in reply to: ↑ description @philmcdonnell
4 years ago

I like the idea, but perhaps delineate those two pages from the rest with an <hr> or something also.

#6 @Presskopp
4 years ago

or maybe just a little highlight

#7 @birgire
4 years ago

Another suggestion would be to add the Homepage and the Posts Page as a table filter, if they are set.

Example in homepage-postspage-example.jpg

The Mine filter is e.g.


so the Homepage filter could be like:


but currently it looks like the tables don't support filtering by a single post ID.


I tested page_id, p and post without luck, but finally tested subpost_id, that seems to work:


Last edited 4 years ago by birgire (previous) (diff)

3 years ago

#8 @toddhalfpenny
3 years ago

  • Keywords has-patch added; needs-patch removed

First stab at a patch.
I have tested with date filters and works OK. Screenshots coming.

I have not yet thought of a good way to put a visual line between any Front/Blog pages. Perhaps if either exist an extra attribute could be given to the first non-front/blog page, and that used to add an extra CSS class to be used (e.g. styling border-top).

3 years ago

Showing with date filter

3 years ago

Without a date filter

#9 @toddhalfpenny
3 years ago

  • Keywords needs-patch added; has-patch removed

So it seem, after talking to gurus (at WordCamp London), that the initial patch would not be sufficient to handle pagination scenarios where Front Page and/or Home Page are not in the fist page of posts.

Believe that this scenario could be handled in a different way, perhaps similar to how sticky-posts work. The thinking is to maybe have a method that can take a list of posts/ids to prioritise, and therefore can be used more widely, beyond just Front and Blog pages.

#10 follow-up: @birgire
3 years ago

The sticky posts are displayed in a post list table with:

if ( ! empty( $q['show_sticky'] ) ) {
	$query['post__in'] = (array) get_option( 'sticky_posts' );

in wp_edit_posts_query() (src), where the link text is e.g. Sticky(3).

One suggestion could be to use a similar approach for the static pages, like:

if ( ! empty( $q['show_static'] ) ) {
	$query['post__in'] = array_filter( 
			array( get_option( 'page_on_front' ), get_option( 'page_for_posts' ) ) 

where the link text could be Static(2) (with a dynamic count), instead of using two links Front Page (1) and Posts Page (1).

Last edited 3 years ago by birgire (previous) (diff)

#11 in reply to: ↑ 10 ; follow-up: @toddhalfpenny
3 years ago

  • Keywords dev-feedback 2nd-opinion added

Replying to birgire:

The sticky posts are displayed in a post list table with:

if ( ! empty( $q['show_sticky'] ) ) {
	$query['post__in'] = (array) get_option( 'sticky_posts' );

Yes, I was thinking similar, but this would reduce the query to just sticky posts, no?

I feel that the logic would need to be something like this;

  1. Pass in priority_ids
  2. Fetch the posts
  3. If on Page 1 AND there is something in priority_ids then re-run query with retrieved Ids and the priority_ids.

This will mean that maybe 1st page has (posts_per_page + 2) pages shown, I think.
I think desired behaviour should be agreed on, in terms of pagination.

#12 in reply to: ↑ 11 @birgire
3 years ago

Replying to toddhalfpenny:

yes, this suggestion would only be for the filter link approach, not the "sticky" admin posts approach.

But I think the "sticky" approach on the front-end can be rather confusing regarding the pagination (just as you mention). For example if one sets the posts per page as 2 and then 4 can be displayed on the first page. Similar for the possible sticky posts duplication.

Otherwise, if the sticky admin posts approach is taken, then they could be pre-pended to the resulting posts array, on the first page, with a secondary query? There might be ways to avoid the extra query, by checking if all static pages are already displayed on the first page (similar to your patch in 39666.patch ). Further one could restrict it to the page post type, to avoid running extra queries on all post list tables, but there might be tickets to expand static pages to custom post types? Maybe implement this via filter, to avoid modifying the list table class too much, as it might be used by plugins.

Last edited 3 years ago by birgire (previous) (diff)

#14 @zodiac1978
17 months ago

I have found a working solution on StackExchange:

Maybe we could go this way?

#15 @zodiac1978
17 months ago

#49439 was marked as a duplicate.

Note: See TracTickets for help on using tickets.