is_page() does not work on BP pages and class names are different

[juggledad]

1) create a page in WP called 'member'
2) activate the theme twenty twelve
3) edit the 'style.css' and add

body.home-page, body.page {background-color: blue;}

4) edit content-page.php and add the following before line 11 (the <article id=…)

<?php echo 'is_page()='.is_page().'<br>'; ?>

5) view the home page, you will see the background is blue
6) view the page you will see the background is blue and you will see 'is_page()=1'

7) activate BuddyPress
8) go to dashboard->settings->BuddyPress->pages set the Members Directore to the page 'member'
9) view the home page - you will see the background is blue
10) view the 'member' page - you will see the background is no longer blue and and you will see 'is_page()= '

11) go to dashboard->settings->reading->Front page displays

• select ' A static page (select below)' and set Front Page as 'member' - hit save

12) 10) view the 'member' page - you will see the background is no longer blue and and you will see 'is_page()= '

BP is changing the classes passed on pages and not setting the is_page() when viewing the pages it uses. This can cause issues with themes.

This did not happen in version 1.7.1

[hnla]

This did not happen in version 1.7.1

As far as I'm aware BP's theme compat layer never did set is_page(), tested quickly in 1.7 & 1.7.2 and is_page() returns false.

#5204 was added with a patch to address the body class issue.

#4954 May well address the is_page() part? but haven't looked at how WP tests for this condition, so guessing a bit.

[henry.wright]

Can confirm stuff like if ( is_page( 'members' ) ) isn't working in 1.9.1

I'm 96.73% sure it worked in BP 1.8 because I had functionality in my install which relied on the outcome of the condition. I noticed today this functionality no longer works which must be because of the is_page check.

[hnla]

@henrywright

theme compatibility is the issue and as far as I'm aware has never been able return a value via is_page().

If you have been using is_page() then are you sure you hadn't been overloading bp templates directly to the parent theme root e.g running my-theme/members/index.php should effectively disable the theme compat class and you are no longer operating in that mode where BP looks for the the_content() to directly inject bp output to.

In bp 1.7 if you run the bp-default theme and add is_page('members') to the members index template it will return true and in all versions past and future would continue to do so.

[juggledad]

I guess the point is that BuddyPress should be supporting ALL WordPress conditionals. If every plugin can change the way you would expect wordpress to normally work then chaos could result.

BuddyPress 1.7.2 declared theme independence…and it has a setting for Pages. If they are 'Pages' then the is_page() should work. If they are not 'Pages' then call them something else.

[hnla]

@juggledad that is a given, I and more importantly the core devs understand the importance of this and are striving to bring BP into parity with WP behaviour as things move forward and indeed tickets addressing things like user registration usernames demonstrates this, and the task jjj is tackling in re-factoring to use re-write rules is a major step in this direction, but all this takes time, BP was built originally to serve a specific case and did things it's way, untangling that is a pretty complex task but it's getting there with every iteration.

[henry.wright]

Replying to hnla:

In bp 1.7 if you run the bp-default theme and add is_page('members') to the members index template it will return true and in all versions past and future would continue to do so.

Got ya! That's exactly it. I decided to move away from bp-default when I upgraded to 1.9.1 this week ( call me a laggard :) ). That explains why I could use is_page successfully in 1.8

[hnla]

call me a laggard

You're a laggard! :)

With the additions to the template hierarchy for theme compat introduced in 1.8 there is almost no scenario I can think of where one would want to run template files directly in theme root thus disabling theme compat where new builds are concerned.

[r-a-y]

The commits to fix ticket #5301 should also address this ticket.

If you feel like testing, please pull the latest bleeding version or apply r7735 and see if this fixes the problem.

[hnla]

As I can confirm that is_page() or is_page('members') now returns true on bp theme compat templates we can close this ticket.

We still have no body class generated though so it may be time to re-visit #5204 and add this little patch to compliment #5301 ?

[henry.wright]

Hi r-a-y and hnla

I've given this a regression test and came across an issue. As Hugo confirms, with the patch in place, is_page returns true. However, when I navigate to a page such as members/username/messages, my header and footer area seem to be replaced with white space. See attached screen grab. As you can see that's my custom theme - I'm just about to test on a standard install...

Anybody else seeing the same?

Note: In the screenshot below, there should be a header above the grey bar which has the inbox, sent and compose links. There should also be a footer at the bottom of the page.

[henry.wright]

It seems the reason for the white space is a check I have in header.php

if ( is_page( 'login' ) ) {
    // do something
} else {
    // output header
}

This seems to be returning true when on the members/username/messages page. Also seems to be returning true when on members/username/settings

[r-a-y]

henry.wright - Are you saying that is_page( 'login' ) returns true on a user's "Messages" or "Settings" page? I tested your conditional in Twenty Twelve's header.php, but could not duplicate your problem. is_page( 'login' ) returns false for me.

I don't think your issue is related to the change in r7735 because your is_page() conditional is checking a non-BuddyPress page. There might be an issue with the way you have set up your conditional.

[henry.wright]

Replying to r-a-y:

henry.wright - Are you saying that is_page( 'login' ) returns true on a user's "Messages" or "Settings" page?

Yes. In fact, it is any BP component page - activity, settings, messages etc.

It doesn't matter which page I check for i.e. 'login', 'contact', 'hello' - they all return true when on one of these BP component pages.

Non-BP component areas of the site are unaffected. So for example, it returns false on the about me page example.com/about/

I'm sure the conditional is set up properly.

Could it be something like root profiles causing the problem? They're enabled.

[r-a-y]

Could it be something like root profiles causing the problem? They're enabled.

That sounds about right. Thanks for mentioning this. Can you turn root profiles off temporarily to see if the problem disappears?

[henry.wright]

r-a-y

Problem is gone with root profiles disabled! These root profiles do love to misbehave!

[r-a-y]

Problem is gone with root profiles disabled! These root profiles do love to misbehave!

Thanks for testing! They do love to misbehave! Once we move over to rewrite rules, this should hopefully resolve itself.

One thing though, is this a big-enough problem that we need to fix in the interim (BP 1.9.2)?

Perhaps you can workaround this by checking if the current page is a BP page with the is_buddypress() conditional and then doing checks for the login page?

[henry.wright]

Replying to r-a-y:

One thing though, is this a big-enough problem that we need to fix in the interim (BP 1.9.2)?

No problem r-a-y, I can work around it until the move over to rewrite rules.

I wonder how many people will be using is_page with root profiles? I doubt there will be many but it will cause issues for them so maybe it will be a good idea to make people aware of it?

[hnla]

I wonder how many people will be using is_page with root profiles?

Extremely few I would have thought and those that might would probably simply drop in another solution.

I'm not sure I would be using is_page() as a conditional in this manner? Tending to wonder whether I would use it at all in BP terms, yes in other WP scenarios perhaps.

Also I'm wondering whether your use case isn't covered by the work done in 1.8 to further refine the template hierarchy in theme compat templates?

[henry.wright]

Replying to hnla:

I'm not sure I would be using is_page() as a conditional in this manner? Tending to wonder whether I would use it at all in BP terms, yes in other WP scenarios perhaps.

I tend to use conditionals quite a lot throughout my themes, probably indicating that I need to break my templates into parts a little bit more than I already do. I use the Theme My Login plugin and use is_page in my theme's header.php file to identify when a user is on what I call an entry page (register, login, reset password etc). If the current page is an entry page I don't output the header and footer navbars - so I'm just using is_page to remove the clutter from the page. Of course a better way of doing it would be to use template parts - which I'm thinking of doing going forward. Less conditionals will make everything easier to read too.

[r-a-y]

henry.wright - You might also want to check the patch in #5241.

[r-a-y]

Marking this as a duplicate of #5301.

henry.wright's issue can be tracked in #5241.