Wordpress-seo: WP Multisite: Yoast SEO title, description, focus keywords, etc not saving for non subsite admins

Created on 21 Nov 2016  路  10Comments  路  Source: Yoast/wordpress-seo

What did you expect to happen?

What happened instead?

How can we reproduce this behavior?

Can you provide a link to a page which shows this issue?

Technical info

  • WordPress version:
  • Yoast SEO version:
multisite

Most helpful comment

Hi there,

I just stumbled over this while reading my pull request (due to another support issue).

It might be the case that some plugin (or your theme) did something on another site (i.e., call switch_to_blog( $new_site_id )), and did not properly restore the site (i.e., call restore_current_blog()) but just used switch_to_blog( $old_site_id ).

If possible, can you deactivate all other plugins, and maybe even temporarily switch to a default theme?

You could also check if this is the case by (temporarily!) replacing the above condition with this:

if ( is_multisite() && ms_is_switched() && get_current_blog_id() !== (int) $GLOBALS['blog_id'] ) {
    return false;
}

If you are able to save metadata with this new condition, then you have been on the _right_ site, but in the _wrong_ way.

I didn't used this in the original pull request just because WordPress is not in the default context for the current site.

I hope that makes sense...? :)

All 10 comments

Hi,
Seems we are having an issue where the a customer / Pro Site user is unable to modify it's yoast seo settings on a page.

When we login from admin it works well and we can update it for the client, but the client logged in can not change any settings or any page tags by themselves.

Can you please advise on that if we go for Yoast SEO Premium then will Subsite admins be able update these SEO page settings [title, description, focus keyword] or not?

What kind of rights do these users have? Users that are allowed to edit pages should be able to set the values of the Yoast metabox.

If you login as a user, do you see any errors in the JavaScript console?

Users have administrator rights and all these users are able to edit pages but not able to set values of the Yoast metabox.

No we didn't see any errors in the JavaScript console.

Hi

I've debug and find out the problem.

There is a problem in code in class-metabox.php under wp-content\plugins\wordpress-seo\admin\metabox\class-metabox.php under function save_postdata in following block.

// Bail if this is a multisite installation and the site has been switched.
if ( is_multisite() && ms_is_switched() ) {
return false;
}

So whe I commented out this block the metabox is saving correctly under multi site installation otherwise it return false and rest of the code is not worked and consequently metabox is not updated successfully.

I've compare this file with older version 3.2.5 that upper block of code is not exist so can you please advise now what is the purpose of this multisite condition there in new updated version?

If I commented out this block will be there any effect on the plugin???

This code was implemented for this issue: https://github.com/Yoast/wordpress-seo/pull/4557 that was added in 3.3.
I haven't been able to reproduce this yet, but we should look into it to see if we can solve conflicts on multisite.

Hi there,

I just stumbled over this while reading my pull request (due to another support issue).

It might be the case that some plugin (or your theme) did something on another site (i.e., call switch_to_blog( $new_site_id )), and did not properly restore the site (i.e., call restore_current_blog()) but just used switch_to_blog( $old_site_id ).

If possible, can you deactivate all other plugins, and maybe even temporarily switch to a default theme?

You could also check if this is the case by (temporarily!) replacing the above condition with this:

if ( is_multisite() && ms_is_switched() && get_current_blog_id() !== (int) $GLOBALS['blog_id'] ) {
    return false;
}

If you are able to save metadata with this new condition, then you have been on the _right_ site, but in the _wrong_ way.

I didn't used this in the original pull request just because WordPress is not in the default context for the current site.

I hope that makes sense...? :)

Yes it works for us, thanks for your quick response to provide a temporary solution. We are looking forward for a permanent solution in your next update.

Did any different solution was found?
Nothing wasn't changed in last updates=(

Thanks @tfrommen
With your suggestion I was able to find an instance where switch_to_blog() was used and later in that code there was switch_to_blog($currentBlogId).
That was easily replaced with restore_current_blog();

Based on the feedback in this thread i presume that the OP had a plugin or theme with code that was behaving according 'other' coding standards. Since this issue has not produced a lot of feedback in the 3 years it has been opened and the fact that this issue is not reproducible on a clean WordPress installation, I will be closing this thread.

If similar issues arise, please verify their persistence by disabling all other plugins other than Yoast. If so, please open a new issue with your findings so that we may have a look at it.

Was this page helpful?
0 / 5 - 0 ratings