Context Navigation

← Previous Ticket
Next Ticket →

#5241 closed defect (bug) (fixed)

Notices occur when BP_ENABLE_ROOT_PROFILES is enabled

Reported by:	henrywright	Owned by:	r-a-y
Milestone:	2.1	Priority:	normal
Severity:	minor	Version:	1.7
Component:	Core	Keywords:	needs-refresh has-patch
Cc:	mpa4hu@…

Description

I am getting the same 3 PHP notices at various times when using BP with WordPress SEO:

On successful avatar upload
After clicking the submit button when searching private messages

The notices are:

Notice: Trying to get property of non-object in /htdocs/wp-content/plugins/wordpress-seo/frontend/class-frontend.php on line 548

Notice: Trying to get property of non-object in /htdocs/wp-content/plugins/wordpress-seo/frontend/class-frontend.php on line 840

Notice: Trying to get property of non-object in /htdocs/wp-content/plugins/wordpress-seo/frontend/class-frontend.php on line 843

After speaking with one of the plugin's contributors in the WP forum see the WP forum thread, they suggested I raise a BP ticket due to the notices being caused by BuddyPress doing something to the $post object which causes it to not be an object.

Attachments (1)

5241.01.patch (2.6 KB) - added by r-a-y 10 years ago.

Download all attachments as: .zip

Change History (25)

#1 @boonebgorges
11 years ago

Keywords reporter-feedback added

henrywright - What theme are you using? Is it using BP's theme compat?

I'm dubious that BP is wiping out the $post global - we use it in a number of important ways. I've just done a bit of testing using Twenty Twelve as a theme, and was not able to reproduce the notices. Are there any special settings I need to activate in WordPress SEO?

#2 @henrywright
11 years ago

I was using a child theme of bp-default.

Considering the attempts to get the $post property are all wrapped in a is_singular() check (see lines 548, 840 and 843 in class-frontend.php), should that particular piece of plugin code be running at all at the point of change-avatar or private message search? The change-avatar and private message pages are not any of is_single(), is_page() or is_attachment() are they?

UPDATE: I've been doing some investigation and can see an is_singular() check is being used around the code attempting to get the $post property. is_page() seems to return true for the change-avatar and private message pages (where there notices are displayed) but the $post variable seems to be null here. Could this be the reason why toys are being thrown out of the push buggy?

Last edited 11 years ago by henrywright (previous) (diff)

#3 @boonebgorges
11 years ago

Keywords reporter-feedback removed
Milestone Awaiting Review deleted
Resolution set to wontfix
Status changed from new to closed

: I've been doing some investigation and can see an is_singular() check is being used around the code attempting to get the $post property. is_page() seems to return true for the change-avatar and private message pages (where there notices are displayed) but the $post variable seems to be null here. Could this be the reason why toys are being thrown out of the push buggy?

Thanks for the additional investigation. This is related to the fact that you're using a bp-default descendant. In a nutshell: Because BP content is not WP content, it's not found by WP's initial parse_request() -> query chain. So there is a portion of the load process where WP thinks that requests for BP content are 404s. BP manually unsets this 404 before loading its template, and where/how this happens depends on whether you're using theme compat. The pre-theme-compat switch happens here http://buddypress.trac.wordpress.org/browser/tags/1.8.1/bp-core/bp-core-catchuri.php#L378. We manually flip is_page and is_singular to true, as well as turning off the 404. But we don't do anything to the $post global.

In contrast, theme compat fakes the entire content of a "dummy" post. See http://buddypress.trac.wordpress.org/browser/tags/1.8.1/bp-members/bp-members-screens.php#L407. So if you switch to a theme that utilizes theme compat, the notices should go away.

(FWIW, I switched to bp-default to test and I *still* didn't see the notices. So this is mostly an educated guess.)

Given that the old method is being abandoned, and given that the notices shouldn't actually cause any real problems (aside from some non-optimized robots/meta tags in wordpress-seo), I'm going to close this as wontfix. My apologies to the wordpress-seo devs for the inconvenience - this issue will disappear as people stop using the old BP themes.

#4 @henrywright
11 years ago

boonebgorges, thanks for the detailed explanation of what is happening, you've made sense out of a situation that was confusing me all morning. The guys at wordpress-seo suggested they can add some validation at their end - which will resolve the issue until people migrate away from bp-default.

#5 @henrywright
11 years ago

Resolution wontfix deleted
Status changed from closed to reopened

Please feel free to re-close this ticket but I wanted to make you aware that notices have increased after upgrading to 1.9 beta 1. This is the set of notices displayed when visiting a member's profile page. Some notices seem to be displayed more than once: