Support » Plugin: Members » Trying to get property ‘post_parent’ of non-object in template.php on line 95

  • Hi,

    I get the following error when making a REST request and members plugin is installed:

    NOTICE: PHP message: PHP Notice: Trying to get property 'post_parent' of non-object in /var/www/html/htdocs/content/plugins/members/inc/template.php on line 95

    I’ve fixed the issue by making the following change:

    
            // Set to <code>FALSE</code> to avoid hierarchical checking.^M
            if ( ! empty( $post_id) && apply_filters( 'members_check_parent_post_permission', $check_parent, $post_id, $user_id ) ) {
    

    ( to clarify, I added ! empty( $post_id) && at line #95)

    System setup is:

    WordPress Version: 4.9.4
    PHP Version: 7.2.1
    Pods 2.7.1 (for managing CPTs etc)

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author Justin Tadlock

    (@greenshady)

    WordPress God

    It sounds like you have a plugin or theme that’s incorrectly applying the the_content filter (or a related) hook outside of The Loop context. By default, that check in Members is only run on hooks that should be executed within The Loop and the global $post is available.

    A check wouldn’t hurt in Members, but it wouldn’t address the underlying issue. And, whatever’s breaking will most certainly break with other plugins running on the_content and other Loop-only hooks.

    Yep, you’re right.

    The issue is the ElasticPress plugin (https://github.com/10up/ElasticPress). I’ll report the bug to them.

    Cheers!

    Just one other things. Is it correct that any loop/template stuff should be triggered at all for REST requests?

    Link back to ElasticPress bug report for future reference – https://github.com/10up/ElasticPress/issues/1025

    Plugin Author Justin Tadlock

    (@greenshady)

    WordPress God

    Generally speaking, the_content should only ever be called within The Loop (typically via the_content() function). However, it’s possible to work around this by calling setup_postdata() and overwriting the global $post variable for some other use cases. Either of those times are what I’d call valid times the_content can be called.

    Plugins that hook into the_content must rely on the global $post variable being an actual post object.

    And, here’s one of the lead WordPress developers explanation for it: https://core.trac.wordpress.org/ticket/24330#comment:3

    To answer your question, this can certainly be triggered at any point, including a REST request. But, that code should abide by WP conventions.

    I was just asking a closer look at the code in template.php and I have a further question/suggestion….

    I’m wondering, could the following assumption be the cause of this bug (line #31 of inc/template.php)?

    // If no post ID is given, assume we're in The Loop and get the current post's ID.
    	if ( ! $post_id )
    		$post_id = get_the_ID();

    I only see this bug when either updating a post in WP Admin or via REST Api – and AFAIK, neither use the loop.

    Seems that this check could be made more robust by changing it to:

    	// If no post ID is given, assume we're in The Loop and get the current post's ID.
    	if ( in_the_loop() && ! $post_id )
    	{
    		$post_id = get_the_ID();
    	}

    I suppose that the subsequent code would need wrapping in if( ! empty( $post_id ) ){} too…?

    Plugin Author Justin Tadlock

    (@greenshady)

    WordPress God

    I could easily add some additional error checking for when others don’t follow the conventions. However, that’s sort of like putting a Band-Aid on a bullet wound. Yeah, it temporarily solves the problem. However, what you really need is a surgeon to go in, pull the bullet out, and correct things under the surface.

    By not changing this, I’ve seen dozens of plugins get fixed over the years now. Bugs should be exposed and not hidden away. It’s a little short-term discomfort for a few people in exchange for better code for everyone involved.

    Anyway, I’ve already created a ticket for addressing this in a more useful for developers but less disruptive for users manner: https://github.com/justintadlock/members/issues/183

Viewing 7 replies - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.