You don’t actually state what the issue is!
There were some issues with is_page a while back that I dimply remember being addressed but wasn’t aware of any current ones.
Do describe the issue so we have a chance to try and replicate.
Sorry. This is what happens when you write posts at the end of a long day!
is_page( $page ) is returning true for any value of $page on all buddypress pages. It’s fun 🙂
@tobyhawkins
Not sure how you’re running your checks, where or to what end, but I wouldn’t use is_page() where BP is concerned, but it sort of depends on what exactly your theme is trying to do, BP has template tags such as bp_current_component() & bp_current_action() that can provide very specific checks for screens.
This ticket and the links to a a sister ticket might help in understanding how is_page() is working and the changes effected a while back, of course this doesn’t rule out the possibility there is something else wrong that needs further investigation.
https://buddypress.trac.wordpress.org/ticket/5307
Having said all that is_page() will return true, is_page(‘blah-blah’) will return false if for example your running that on the members directory screen, bp_current_component() will return ‘members’
What templates are you working with, theme compatibility?
Yeah I had a read through the ticket before posting.
What’s confusing me is something has changed in v2.2.0 and I’m not sure how to mitigate it. It may well be that the conditional logic has been broken since I took over the site and just worked by mistake, but is_page() is being used in functions.php to drive some redirection/login stuff (not 100% why – no documentation!), changing page headers, as well as enqueue/dequeue different scripts. The main one that has caused a nightmare is:
if( ! is_user_logged_in() )
{
// code removed
}
else
{
if( is_page( 'login' ) || is_page( 'register' ) || etc.. )
{
wp_redirect( '/home/' );
die();
}
}
The site is working fine in Buddypress v2.1.1 but in v2.2.0 every single Buddypress page now redirects to home. This one is actually quite easy to work around, but then I fall foul of the others. There probably needs to be a large scale rewrite, but it’s a big site with no documentation and it’s just me working on it and there’s no budget for that kind of development.
Well you could and probably should be using tags like bp_is_register_page() although logged in BP will or is supposed to redirect to the home page if you try and access a page registered to the BP registration template.
So the issue then is that if you have is_page(‘about’) in that else clause then any bp page you land on would return true for that, which isn’t right but not sure why that is the case suddenly for you, it certainly doesn’t look like that would be happening on my trunk install I’m testing on.
Additionally there are a lot of posts covering re-direct scenarios on the forum, it might be worth checking a few of those and building a more robust redirect function, the one you have is a bit basic.
There are a lot of other redirect bits and pieces. The site is locked down to just users with emails from set domains. I’m a bit hesitant at the moment trying to rebuild what’s already been built on the site because I don’t know what else I’ll break.
I don’t have is_page(‘about’) in that if clause. I’ve tested with single is_page() values and even is_page(‘rehkjvabwdvarv’) is returning true on Buddypress pages for me.
‘about’ was simply an example to point out that if I dump that in a BP page it will return false, so that it wouldn’t in your case tends to point to something up with your install, quite what I’m not sure at this stage.
Actually I should clarify, this isn’t happening on members or groups index pages. It’s subpages of these. It seems to be something to do with get_queried_object()? I’m starting to show my hideous ignorance at this point though.
So outputting the content of $page_obj in the public is_page function in query.php at the same point for my site in v2.1.1 and v2.2.0:
v2.1.1:
WP_Post Object ( [ID] => 834 [post_author] => 1 [post_date] => 2013-09-13 12:38:31 [post_date_gmt] => 2013-09-13 12:38:31 [post_content] => CONTENT REMOVED [post_title] => Groups [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => groups [to_ping] => [pinged] => [post_modified] => 2014-08-18 09:39:45 [post_modified_gmt] => 2014-08-18 08:39:45 [post_content_filtered] => [post_parent] => 0 [guid] => REMOVED [menu_order] => 0 [post_type] => page [post_mime_type] => [comment_count] => 0 [filter] => raw [is_404] => 1 [is_page] => [is_single] => [is_archive] => [is_tax] => ) 1
v2.2.0:
WP_Post Object ( [ID] => 0 [post_author] => 0 [post_date] => 0 [post_date_gmt] => 0 [post_content] => [post_title] => [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => [post_password] => [post_name] => [to_ping] => [pinged] => [post_modified] => 0 [post_modified_gmt] => 0 [post_content_filtered] => [post_parent] => 0 [guid] => [menu_order] => 0 [post_type] => page [post_mime_type] => [comment_count] => 0 [filter] => raw [is_404] => 1 [is_page] => [is_single] => [is_archive] => [is_tax] => ) 1
That was for a buddypress group’s home page, i.e. site.com/groups/group-name/
Yep dumping an is_page(‘about’) on a single group does return true, I would suggest a thorough trawl through tickets for 2.2 to see what might have changed behaviour if indeed that’s the case other than that a test case of some description so people can see exactly what is attempted and how it breaks, however I suspect in reality the original code is possibly weak and needs re-factoring.
Thanks @Hugo. Appreciate your time on this. I’ll have a look and see what I can do.
I’m trying hard not to think about the original code at the moment. I took over the site in May last year and knew php/mysql but had very limited experience with WordPress and hadn’t even heard of Buddypress. It’s been a steep learning curve, and I’ve managed to work out a lot and fix a bunch of stuff and even make some timid suggestions here, but a thorough re-factoring of the code is a step too far both time and probably skill wise at this point unfortunately.
In BuddyPress 2.2.0, we set all BP pages to page ID of zero.
This showcases the “is_page( 'ANYSLUG' ) returning true” bug in WordPress when the page ID is zero:
https://core.trac.wordpress.org/ticket/24674
I would recommend applying this simple one-word patch to WP core temporarily:
https://core.trac.wordpress.org/attachment/ticket/24674/24674.2.diff
Or you can use is_buddypress() to test if you’re on a BP page as well.
@r-a-y what tickets and changes are relevant to this issue? I’ve tracked back and through all I can find on is_page() and can’t locate this last change, this may be a bug with WP but I now have an issue with perfectly legitimate is_page & is_singular() checks on screens/CPT’s slugs that have nothing whatsoever to do with BP and manage loading of assets, I now find that those assets are loading on all bp_is_user() screens so even if this is a WP bug it feels like we’ve aided and abetted the problem somehow.
@hnla – It’s related to this changeset:
https://buddypress.trac.wordpress.org/changeset/9322
This issue was also noted on the following ticket about buddypress.org:
https://buddypress.trac.wordpress.org/ticket/6108#comment:2
In BP 2.2, I tested is_singular() on BP pages and it returns true. bp_is_user() also works as expected.
If there are any other issues outside of is_page(), please let me know specifically what the issues are, as I do want to address these.
@r-a-y no I guess I couldn’t get my head around how or why this was happening, get it now, but it’s a pretty horrible issue 🙂
@r-a-y’s WP core patch seems to solve the issue I was having. Thanks!
Yep we thank r-a-y for his due diligence on the mater and for patching WP core, which was committed a few days back so will roll out with next WP version.
Closing this thread as resolved then.
