Make WordPress Core

Opened 12 years ago

Closed 11 years ago

Last modified 8 years ago

#21620 closed enhancement (wontfix)

Add conditional tag to check if current page is any of the blog-related pages

Reported by: grantnorwood's profile grantnorwood Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: dev-feedback has-patch
Focuses: Cc:

Description

The current is_home() function returns true when the blog's home page (or paged > 2) is viewed, but I propose we should also have a convenient tag to determine if the currently viewed page is any of the blog-related pages. (Excludes custom post types.)

This would be a new function called is_blog_page(), and would return true if the current post type is 'post', and if is_home(), is_archive(), or is_single() also return true.

This is tangential but still related to the confusing names and implementations of the is_home() and is_front_page() functions (see #18705, #10158, #21237). However, I'm seeking to add a new function that aligns with the existing (or future) names, but still gives the additional functionality of detecting whether the current page is any of the blog post pages, which is_home() does not do.

An example of the proposed new function is below:

/**
 * WordPress' missing is_blog_page() function.  Determines if the currently viewed page is
 * one of the blog pages, including the blog home page, archive, category/tag, author, or single
 * post pages.
 *
 * @return bool
 */
function is_blog_page() {
    
    global $post;
    
    //Post type must be 'post'.
    $post_type = get_post_type( $post );
    
    //Check all blog-related conditional tags, as well as the current post type, 
    //to determine if we're viewing a blog page.
    return (
        ( is_home() || is_archive() || is_single() )
        && ( $post_type == 'post' )
    ) ? true : false ;
    
}

I'm happy to attach a patch if that's helpful! I'd love to contribute to core for the first time.

Attachments (1)

21620.patch (1.2 KB) - added by grantnorwood 12 years ago.
Patch containing new function.

Download all attachments as: .zip

Change History (9)

@grantnorwood
12 years ago

Patch containing new function.

#1 @grantnorwood
12 years ago

  • Keywords has-patch added

#3 @greenshady
12 years ago

  • Cc justin@… added

Neither is_single() nor is_archive() will work here. Those check for any type of single view or archive for any post type. Your checks would need to be:

is_home()
is_singular( 'post' )

is_author()
is_date()
is_time()

Only the first two are pretty sure bets though. The others are all used in a myriad of ways with various post types.

Your use of get_post_type() won't work as needed in the function. It should only be used within The Loop in the manner that you're using it. Of course, you could pass the queried object on single views, but that's not the problem area. So, the check's not really needed.

Archives are where you run into trouble and anything goes.

Honestly, I don't think we need a function for this because it can actually be pretty custom from site to site. But, for your basic user, just tell them to use:

if ( is_home() || is_singular( 'post' ) )

That should cover most of their needs.

#4 @grantnorwood
12 years ago

Thanks Justin, I'm understanding better. I get why is_single() and is_archive() won't work, and I'll look into how the others work with my custom post types, as that happens to be next on my dev list after the blog section.

I'd like to provide a little context, in case that helps you decide whether it's a valuable addition to core or not.

For the current site I'm working on, I would like to apply different themes to different pages, and groups of pages, using additional CSS classes on the body element. This seems like something that many theme developers could use for conditional loading of styles/scripts/content, but it would be convenient to abstract the complexity of multiple is_xyz() calls for the various blog pages/templates. Example below:

<?php

//Theme color.  get_theme_color_class() uses my proposed is_blog_page() 
//function to determine which page is being viewed and returns a CSS class 
//as a string.  Also shown below.
$theme_color_class = get_theme_color_class();

?>
<body <?php body_class( $theme_color_class ); ?>>
<?php

/**
 * Get the CSS class name for the current page's theme color.  The theme
 * color is set using the "theme_color" custom field.
 */
function get_theme_color_class() {
    
    global $post;
    $top_page_id = null;
    
    //Check for exceptions.
    if (is_blog_page()) {
        
        //Get the dummy blog page so we can get its custom fields.
        $top_page_id = get_page_by_path('blog')->ID;
        
    } /*else if () {
        
        //Some other exception ...
        
    }*/ else {
        
        //Check for ancestors.
        if ($post->post_parent)	{
            
            $ancestors = get_post_ancestors($post->ID);
            $root = count($ancestors) - 1;
            $top_page_id = $ancestors[$root];
            
        } else {
            
            //This page is top-level.
            $top_page_id = $post->ID;
            
        }
        
    }
    
    if (!empty($top_page_id)) {
        $theme_color = get_field('theme_color', $top_page_id);
        
        if (!empty($theme_color)) {
            return $theme_color . '-theme';
        }
    }
    
    //No theme color specified for this page or its parents.
    return 'no-theme-color';

}

Above is just for context, please ignore any other dumb mistakes or non-WP code formatting :)

As you can see, get_theme_color_class() calls my proposed is_blog_page() to determine the current page, but is doing so outside the loop. This seems to work well in the few use cases I've tried, and correctly sets a "red-theme" class on all blog-related pages (author, date, cat, tag, single), but this probably isn't reliable for all use cases.

I understand your concern that with archives and custom post types, this might get hairy! I'll continue to test with those for my own purposes, but also for the community if it's helpful.

If you and/or others think there is value in a function like this, which simplifies detecting whether any of the post-related page templates are being viewed, then I'm happy to keep working on this ticket until it would be both useful and reliable.

Maybe there are more use cases I should be thinking about for other WP developers?

#5 @meloniq
11 years ago

  • Cc meloniq@… added

#6 @dcowgill
11 years ago

  • Cc dcowgill@… added

#7 follow-up: @scribu
11 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I don't think it's a good idea to mix up is_single() and is_archive() into a new function. The conditional flags should largely be orthogonal, i.e. not overlap.* Then, you could construct whatever composite flags you need, outside of Core.

When I see is_blog_page(), I only think of the "page for blog posts" you can set in WP Admin -> Settings -> Reading. If someone wants to propose something like that, please open a new ticket.

  • Yes, I know it's a mess with is_single() vs. is_singular() and is_front_page() vs. is_home()

#8 in reply to: ↑ 7 @SergeyBiryukov
8 years ago

Replying to scribu:

When I see is_blog_page(), I only think of the "page for blog posts" you can set in WP Admin -> Settings -> Reading. If someone wants to propose something like that, please open a new ticket.

Follow-up: #34487

Note: See TracTickets for help on using tickets.