Support » Requests and Feedback » Blog-Post vs CMS-Page – Why Not More Separation?

  • As I have learned more and more about WordPress, it seems to me that since WordPress was originally designed as a blog tool and not a CMS tool, the mentality that every piece of content on a WordPress site needs to be thought of as a ‘Post’ prevails.

    Why is there little effort to make the use of WordPress as a CMS significantly more intuitive and functional by Letting ‘Posts’ be ‘Posts’ and ‘Pages’ be ‘Pages’?

    Currently, ‘Pages’ are just another kind of ‘Post’, even in the database schema. ‘Pages’ should have their own table in the schema in order to separate that data entirely from ‘Posts’ to avoid data corruption and to allow for database calls relating solely to ‘Pages’.

    When I want a ‘Page’ title to come up on a given ‘Page’ I have to call for ‘post-title’. Really?

    When attempting to use ‘Permalinks’ to enforce user and SEO friendly URLs, there is %postname% to use for pretty links to individual ‘Posts’ but there is no %pagename% to call on? Seriously?

    ‘Pages’ are not ‘Posts’. ‘Pages’ CONTAIN ‘Posts’. This blurring and bleeding of the conceptual nomenclature, trying to use the ‘Post’ architecture to handle ‘Pages’ is both counter intuitive to administrators/users/designers, but also seems to have been causing all sorts of mischief on the functionality side with quirky behavior on sites where WordPress is being used as a CMS.

    I am curious to know why there is not a clear differentiation and hierarchy established between ‘Pages’ and ‘Posts’.

    This, in my opinion, is WordPress’ greatest failing.

    I am curious to know if this is recognized as an issue by other members of the community and if it is something that is slated for refinement in later releases.

Viewing 10 replies - 1 through 10 (of 10 total)
  • Actually having Pages as post_types solves many architecture problems, not the least of which is it makes custom post types possible. It’s the same architecture that Drupal uses although Drupal calls them “Nodes” instead of “Posts.” The fact Drupal uses the same indicates in part that this is an architecture that works well for content management systems.

    Why do you need a %page_name% for URLs? To be able to create custom URLs for Pages? If yes, I’d ask if maybe you’d not be better off creating custom post types because the URL routing for Pages really makes perfect sense to stay as is; if the URLs don’t work for Pages then again that indicates they should be a custom post type and you can do more with custom post type URL routing, albeit in code vs. in the admin.

    As far as “Pages” containing “Posts”, well that’s not how WordPress was designed. Pages that contain posts are typically not “Pages” in WordPress vernacular but instead routed to an archive theme template. I wish that list of posts were not called “Archives” and I wish that list of posts were something that could easily be configured by URL, but it’s not hard to get around it in a theme. Besides I’m working on something to address this (read below.)

    Personally I think the structure you criticize as one of “WordPress’ greatest failings” is actually one of its best architecture choices. But, if there is something to criticize I think what you really want to criticize is the URL routing system in WordPress; it was hard-coded for Posts, extended for Pages and then further hacked for Custom Post Types such that it is now a mess. It all together too rigid and inflexible IMO. OTOH, it’s not hard to fix and I am actually have a pre-alpha URL Routing replacement plugin that I can let anyone who wants to beta test it in the near future.



    Thanks for the reply Mike.

    My only follow up to your statements is this…

    You say :: “As far as “Pages” containing “Posts”, well that’s not how WordPress was designed.”

    I say :: “But it is how people think.”

    My frustration with this comes in the form of attempting to latch onto one common element of any given page (be it a Page or be it the Blog Page) of a WordPress site, and use that identifying marker to make things happen on that page based on conditional PHP statements.

    Right now I use $wp_query->post->post_title; to get the name of my Pages. It works just fine everywhere except the main “Blog” page, which of course yeilds the title of the latest “Post” of the “Blog Page”.

    Is there a simple solution to this? Is there a common identifier that I am not aware of that I can call on that indicates where in the overall site structure the user is that works for “Pages” and the “Blog Page”?

    Moderator Ipstenu (Mika Epstein)


    You say :: “As far as “Pages” containing “Posts”, well that’s not how WordPress was designed.”

    I say :: “But it is how people think.”

    There’s a fun one 🙂 You’re both right, here. JK’s right that the tool is ‘wrong’ if people don’t understand how to use it, but Mike’s right in that we do, sometimes, need to use a tool as intended and learn new terms.

    Is there a common identifier that I am not aware of that I can call on that indicates where in the overall site structure the user is that works for “Pages” and the “Blog Page”?

    Possibly. Are you talking about Breadcrumbs, though? I think I’d need a concrete example (instead of hypothetical) in plain English to know for sure 🙂



    Thanks Ipstenu. Very diplomatic.

    It doubt that it is lost on you fellows that people who have used the web for years have been essentially taught by web designers that “(1)Web Sites” are made of “(2)Web Pages”, any of which may or may not be forums which contain “(3)Posts”.

    These are not new terms. They are old terms which, in this particular case, have been reapplied in the hierarchical order of (1)(3)(2).

    That is why there is a frustrating cognitive disconnect.


    As for my current issue that relates to this…

    Lets define a simple Web Site Structure

    I’m using graphical Nav buttons.

    I want those graphical buttons to be in Up State unless the user is on the Page that nav button corresponds to.

    I can use $wp_query->post->post_title; to get the “Title” of each ‘Page’, then feed that “Title” into a variable.

    I am using PHP to tell each nav button to be in upstate unless that button’s title matches the variable.

    The Blog Page however has no title.

    So, hopefully that is both concrete enough, and in plain enough English to illustrate the issue for you.



    Could it be as simple as creating the Blog Page, not selecting it to be the page for “Posts” in the Reading section of Settings, then creating and using a Blog template?

    Mike Schinkel


    You being frustrated about it is not going to change it. Believe me, I’ve been there and it doesn’t solve your issue. But, ask specific how-to questions like you did and you might get what you need.

    Anyway, don’t use titles, they are too easy to be changed by users who will then break your site structure.

    If you want to tell if your blog page is the current page use:

    $wp_the_query->post->ID == get_option('page_for_posts')

    For the other pages, it depends on how you are trying to build your menu as there are several ways to get the info you need, some more robust than others. Are you using WordPress menus, or your own menu system (or one from a theme?)



    Thanks again Mike.

    The menu system is my own.

    Moderator Ipstenu (Mika Epstein)


    Oh a lot changes 😉 But WordPress started as a blog, and no matter how CMS it gets, it’s going to keep using those terms because everyone who uses WP as a blog (and they do still outnumber the CMS folks) thinks like this:

    Blog post
    Static page

    And then we have Custom Post Types and that throws it all out the door 😉

    If you use the WordPress menus, I THINK it grabs the page name and will change as you change it, but I’ve not played with it extensively.

    Mike Schinkel


    You could use this function which you could call like this jkd_is_current_page('about-us') for your “About Us” page, assuming your URL slug for the page is 'about-us':

    function jkd_is_current_page( $url_path ) {
      global $wp_the_query;
      return $url_path == $wp_the_query->post->post_name;

    But I don’t really like that approach because it’s too easy for the end-user to decide they want to change the page URL slug, i.e. from 'about-us' to 'about', for example, and then they complain that your site is broken (because it is.) Here is a more robust version of that function that requires you to explicitly assign a “Page Key” to each page that is represented in your menu. It uses a hidden custom field with the meta_key of '_page_menu_key':

    function jkd_is_current_page( $this_key ) {
      global $wp_the_query;
      list( $path ) = explode( '?', $_SERVER['REQUEST_URI'] );
      $page = get_page_by_path( $path );
      return $this_key == get_post_meta( $page->ID, '_page_menu_key', true );

    With the 2nd approach you’d typically initially set '_page_menu_key' to the same as your URL slug, but if the user changes the slug it doesn’t break the menu. BTW, I just picked the name '_page_menu_key' because it seemed reasonable; it is not a “special” name or anything.

    Hope this helps.


    (p.s. for these type of questions you might get more answers over at; just sayin…)



    Ok, that looks very interesting, Mike. My day is done here, but I am going to give this a whirl over the next couple of days and get back with ya and give some feedback and ask some questions.

    Many thanks for taking the time to offer a solution.


    (p.s. I will pay a little more attention to stackexchange. I have been there a few times while surfing for solutions to things and had some good results.)

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Blog-Post vs CMS-Page – Why Not More Separation?’ is closed to new replies.