Multisite Privacy default settings not deploying to new blogs

I have Multisite Privacy installed and activated on my Multi-Network/Multisite installation. We have chosen to initially restrict access on all new sites created to registered users but allow them to change the settings at their discretion.

We tested this and everything worked correctly back in November and December.

This past week we upgraded the systems to WordPress v4.7 and the distribution of the default settings does not seem to work any longer. Has there been any reports about this?

I've done some searches through the support blogs but have not found anything similar. the only other item that caught my eye was multisite privacy compatibility with Pro sites (which we also run). It was an older article.

Any thoughts on this??

    Adam Czajczyk

    Hello David,

    I hope you're well today and thank you for your question!

    We didn't have any reports of such issue since WP 4.7 came out (I think the last compatibility report related to WP release was for 4.3!) and I have just tested the plugin on my end and it seems to be carrying all the settings over to newly registered sites as expected.

    It's possible though that I missed some vital step/aspect during testing so would you mind granting me a support access to your setup so I could review configuration of your site in order to replicate that on my sandbox for further testing?

    Here's a guide on granting support access: https://premium.wpmudev.org/manuals/wpmu-dev-dashboard-enabling-staff-login/

    Let me also know please if that applies to all the new sites that are created or to the sites of certain Pro Sites level or e.g. sites created by logged-in/logged out users etc.

    Best regards,
    Adam

    David

    Adam,

    Thanks for the quick response. Things are great here, how you had a great new year.

    As I noted this is a Mult-Network, multisite configuration which consists of
    wp.odu.edu
    fs.wp.odu.edu
    student.wp.odu.edu
    sites.wp.odu.edu.
    I've given you access on all 4.

    We have the wp.odu.edu and fs.wp.odu.edu setup to allow public access on any new sites. but have the student.wp.odu.edu and sites.wp.odu.edu networks configured to push registered users only to new sites.

    Let me know if you have any questions.

    Dave

    Adam Czajczyk

    Hello David!

    Thank you for granting access and I'm sorry for keeping you waiting. Since I work on weekends, I'm taking my days off on Mondays and Tuesdays instead so I wasn't around. While usually one of my colleagues would jump in, it seems we've been a bit overloaded with questions recently. Once again, I apologize for keeping you waiting.

    I have accessed and reviewed two sites: "wp.odu.edu" and "student.wp.odu.edu". The configuration seems fine however I'd like to ask you following questions:

    1) I noticed that the registration is disabled on both sites; the issue happens if you create a new site as super-admin then?
    2) Should I go through Pro Sites checkout page or through "Network Admin -> My Sites -> Add new"?
    3) Have you tried to temporarily disable the "Shibboleth" and/or "oduwpmysites" plugins as they both seem to hook to login/signup procedure? I'm not sure also what the "oduwpoverrides" plugin does; I'm asking about that because it's often the case that plugins that do work together well suddenly stop working well along after updates so it would be worth checking
    4) Finally, since it's complex and live setup - I suppose while I wouldn't make changes to the configuration (without your prior consent) I would be allowed to create some test sites (that I would remove later) there to test the issue?

    Looking forward to your replay,
    Adam

    David

    Adam,

    Thanks for the quick reply. I hope you had some great days off!!

    Here is the info you asked for:
    1) We use SAML authentication here (Shibboleth) and we only allow registered users access to the admin areas (although some external access is available through Facebook/twitter plugins). The Shibboleth plugin creates user accounts as they log in and access the system. So the account system is fairly controlled.
    2) We only use the Pro Sites plugin to control plugin distribution. A couple of the plugins such as Domain Mapping have limited distribution. I've tested the issue as a network admin by going into Sites > add new, creating a new site and the issue remains and is consistent. The student.wp.odu.edu and sites.wp.odu.edu networks are the two with restrictions on access for new site creation.
    3) For information: the oduwpmysites and oduwpoverride plugins were locally developed. The oduwpmysites plugin is the default landing page and provides user access to create sites on any network that they have rights based on their role at the University (faculty, staff or student). The oduwpoverride plugin is designed to maintain authentication through cookies so that each individual user can jump from one network to another without having to re-authenticate. Both make the environment more seamless for the user. To answer your question - I have not tried that yet. We have a testing environment that is a mirror of the one you have access to that is behind our firewalls. I can accomplish that test by tomorrow on the test environment. I'll let you know the results.
    4) Yes it is live and classes began today - so definitely active. You can certainly create some sites to test. I'd prefer notification ahead of time for configuration changes so we can coordinate here. There are workshops and other activities around the campus that go on all the time, I wouldn't want to impact those.
    Let me know if you have any other questions. I'll let you know on #3 by tomorrow.

    Dave

    Dimitris

    Hey there Dave,

    hope you're doing good and don't mind chiming in here!

    I really appreciate the extended feedback you've provided.

    We could really use a conflict test here between your plugins, starting from Shibboleth service.
    You can find a nice flow chart that can help you out with this here
    https://premium.wpmudev.org/manuals/using-wpmu-dev/getting-support/
    (just scroll down a bit to see the image)
    As long as you have a mirrored environment you can safely proceed.

    We could then proceed by testing new sites, maybe if we could have access to this staging environment, it would be best for us too!

    Looking forward for your results!
    Warm regards,
    Dimitris

    FYI and in case we need to coordinate our actions in the future, I'm located in a UTC+2 timezone.

    David

    Dimitris/Adam,

    Thanks for the info and I apologize for the delay in responding.

    We did lots of testing this past week on this, trying different stuff to see what we could come up with. Originally, I thought maybe it was related to the 4.7 upgrade we did recently, however, I have found it is not.

    We ran two different set of testing setups:

    1. Our test system (mirror to the one you accessed in production) is RHEL 2.6, running Apache 2.2 with PHP 5.3.3. We are fairly fastidious about patching so everything with the sytem should be up to the latest released by RHEL (patching just done through our Satellite server on 12/28). We are also running WP 4.7.1 with the Shibboleth plugin v1.7 and WPMUDev Multisite Privacy plugin v1.1.8.6. System configured for MultiSite.

    On this test system, we removed all plugins except shibboleth and Multisite Privacy. Logging in with a Shibboleth/admin account, we validated the default settings section of Multisite Privacy had the correct settings that we wanted (Only Registered users have access). We then created a new site by going to Sites > add new and completing the required information. After the site was created we went to the new site dashboard then looked under Settings > reading and the Site visibility setting was "allow search engines" which implies public access.

    2. We also kicked off a Mac OS X system running Yosemite v10.10.5, on the built in apache server v2.4.16 with PHP 5.5.36 and an older version of WordPress 4.6.2 with Multisite Privacy 1.1.84 - no other plugins. We use this for development and testing. System configured for Multisite. We then logged in with a local admin account, went to Sites > add new and created a new site. After the creation we went to the dashboard for the new site and looked at Settings > reading and the Site Visibility defaults were at "Allows search engines to index .. " which means public.

    The last thing we did was to investigate what is really happening in the background code. what/ and where it is storing stuff and if anything is going wrong. Here is what we found:

    In the main file for the plugin - sitewide-privacy-options.php, the action below:
    add_action('wpmu_new_blog', 'additional_privacy_set_default', 100, 2);
    is called but the callback function seems to have some issues.

    Some of the issues are:
    -The option "privacy_default" is not created beforehand, even if there is a default privacy option set in the admin panel. This implies to us that we loose the default setting from the network admin panel. I’m guessing it’s not getting the network default option although it searches for the option in the actual site options.
    -This in turn, makes the privacy default always 1 (public) which is not the value we want (I believe in our case it should be -2)

    Here's the callback function in question:
    function additional_privacy_set_default($blog_id, $user_id) {
    global $wpdb;
    $privacy_default = get_site_option('privacy_default');//not created in the database
    if (!$privacy_default) {
    $privacy_default = 1; //always defaults to 1
    }
    if (get_blog_option($blog_id, "blog_public", 2) == 2) {
    update_blog_option($blog_id, "blog_public", $privacy_default); //always 1
    update_blog_status($blog_id, "public", $privacy_default);//always 1
    }
    }

    We've found that we can actually generate the data value we want from out internal processes, but that means we a kind of ignoring the fact that the Multisite Privacy plugin isn't pulling the data correctly for new sites.

    Let me know what you think or maybe this indicates somewhere else we should look for a potential conflict/problem on our systems??

    Dave

    Adam Czajczyk

    Hello Dave!

    Thank you for that in-depth testing and feedback. I think you might be on a right path with but I admit that it gets to a level where I'll need to consult the developer of the plugin (or some other one suggested by him).

    I have already messaged him directly and am waiting for his response. Hopefully he'll be able to get us on a right track. Please keep an eye on this thread and I'll update it once I only get a response.

    Kind regards,
    Adam