Front page custom title not working

Does it work with the twentyeleven without touching the code? Don’t bother with get_queried_object().

Grrrrr (-:

3.7.1., Twenty Thirteen, installing plugin…, activating plugin, setting starting page to last posts, checking plugins settings: both markers for Automatically generate… are set, setting frontpage description to “TEST DESCRIPTION” saving settings… reloading website, opening source – damn it’s there!!!

<!– BEGIN Metadata added by Add-Meta-Tags WordPress plugin –>
<meta name=”description” content=”TEST DESCRIPTION” />
<meta name=”keywords” content=”testwas” />
<!– END Metadata added by Add-Meta-Tags WordPress plugin –>

And

var_dump( get_queried_object() );

still return null.

Ah! Plugin Version is 2.3.7. The version i loaded this morning is 2.3.6. What did you change?

In other words get_queried_object() does not return a $post object because there isn’t one such object to return when visiting the default latest posts front page.

In that case the plugin uses other information to display in the metatags, for example the description you have set in the settings.

Actually, I did not change anything related to this in 2.3.7, but some other minor things.

I’m glad it finally works for you and there is no bug involved. The fact that get_post_type($post) returned post instead of false made me initially think that we are dealing with a bug here.

I strengthened some checks in the code, but there is no bug involved. The plugin should have worked from the beginning.

Kind Regards,
George

Also I am marking this topic as resolved. Thanks for your feedback. ??

It works in my clean version only. The project where the problem occurs originally still does not work. But I understand that you cannot do research for a problem you cannot reproduce.

Did I understand you right: If your $post is null then get_post_type() returns ‘post’? Mine returns false.

That is correct. Double checked it. Returns post if $post is NULL.

In your case does it happen to both the clean installation and your project? I guess it is on the project only.

Hello George!

My problems rely on my old wordpress-version 3.4.2. We are still using this version because we have dozens of websites running on it and cannot chance the version without adapting all the themes, own plugins etc.

In the old version get_post_type() return false. The new version uses global $post if an empty post is passed and therefore has a valid post to get the type for.

I’m sorry I did not mention this earlier. As the problem could by solved by a simple addition of is_home() I did not expect this to be a version conflict.

Thanks for your help and sorry for the miss-information.

Grettings

Bodo

I see. I did not expect that either! It’s a good thing to know about this difference in the functionality. I’ll try to test the new version of the plugin on 3.4.2 and see if it works fine.

Again thanks for your feedback. ??

George

In the old version get_post_type() return false. The new version uses global $post if an empty post is passed and therefore has a valid post to get the type for.

In Add-Meta-Tags it is essential to use get_queried_object(), since the plugin mostly operates outside the loop and cannot rely on the global $post. For example, if a static page is used as the “posts page”, the global $post is set to the last post that was loaded by the loop, while the plugin needs access to the $post object of the static page, which contains the loop.

But, I think it can be solved using your workaround.

George

Adding is_home() seems to solve the one problem but i’m sure I’d encounter new ones later.

I also thought about setting the query-object manually by calling

$wp_query->queried_object = $post;

but this could have side-effects at many places – bad idea.

Instead I replaced all your calls to get_post_type() by my own theme_my_get_post_type() and implemented this as:

function theme_my_get_post_type( $xPost ) {

    global $post;

    if ( empty( $post ) ) {
         $xPost    =   $post;
    }

    return get_post_type( $post );

}

This works fine and solve exactly the reason without changing the logics of your plugin.

Best wishes!

// Get current post object
    $post = get_queried_object();
    if ( is_null( $post ) ) {
        // Allow metadata on the default front page (latest posts).
        // A post object is not available on that page, but we still need to
        // generate metadata for it.
        if ( ! is_home() ) {
            $do_add_metadata = false;
        }
    } else {
        // Check if metadata should be added to this content type.
        $post_type = get_post_type( $post );
        if ( ! in_array( $post_type, amt_get_supported_post_types() ) ) {
            $do_add_metadata = false;
        }
    }

This is how I intend to fix. This should be the block that gets the $post object and checks the type in the amt_get_metadata_head() and amt_get_metadata_footer functions.

Would be really helpful if you could test it whenever possible.

George

This way a null $post would never reach get_post_type() so I guess we are set.

You have plenty calls to get_queried_object() and to get_post_type(). Not just one. Is it enough to chance one?

I’d rather suggest a my_get_queried_object() which returns either get_queried_object() oder – if not set – global $post.

Yes, I’ll give the new version a try. Inform me as you’r done.

Good night ??

I’ve strengthened the checks in all relevant places. The important ones are those two functions I posted above and also the template tags for the description and keywords (low priority as they should never be used in places where a post is not available).

Also there is amt_custom_title_tag(), but that is not affected even without a fix.

I’m really hesitant to create a wrapper function like the my_get_queried_object() as suggested, because the plugin does not consider the global $post as a reliable object to get outside the loop, especially on pages where (is_singular() === false).

All right. I’ll let you know when it’s out.

Tested Add-Meta-Tags versions 2.3.6, 2.3.7 and the development version (2.4.0dev) with WordPress 3.4.2.

I confirm that when using AMT versions 2.3.6 and 2.3.7 the metatags **are not** generated on the latest posts front page.

Using AMT v2.4.0dev the metatags are generated correctly in the latest posts page.

All AMT versions work as expected on the latest version of WP (currently 3.7.1)

George