David Sader

@r-a-y
@tivus

If you are interested in continuing the discussion for this plugin, and you have more free time to code as I do, I could certainly use the distraction, and the connection.

Excellent, share links to your forks of the plugin via github. I’ll have a look at it sometime. Sorry that I can’t be specific about a timeframe.

I continue to use WordPressMU daily, I just haven’t had much need to jiggle with coding the plugins I use for a while.

The plugin does indeed fire of an email to the SuperAdmin when a blog visibility setting is changed from old value to new value.

I find the function useful on a k-12 education site I manage.

If you want the email to cease comment out the line that adds the email hook:

//email SuperAdmin when privacy changes
add_action( 'update_blog_public', array($this,'ds_mail_super_admin'));

becomes

//email SuperAdmin when privacy changes
//add_action( 'update_blog_public', array($this,'ds_mail_super_admin'));

I can’t see why you couldn’t just disable or delete the old and activate the new.

Turn off the old, turn on the new. You should be good to go.

Having both running at the same time could be bad and throw errors or white screen of death.

If you are worried about losing privacy in the time it takes to switch plugins, it would only be mere seconds. How fast can you click? lol. Otherwise enable maintenance mode or take the site offline for the minutes you need to swap out the plugin. Verify it does what you need, then bring everything back online.

I use the current version of the plugin on the most current version of multisite network wordpress and it still works just fine.

1. The plugin will make a new user “is_user_member_of_blog”. The user will get a role on the subsite. That part of the original post can be resolved.

2. However, every user will always be “is_user_logged_in” on every other site in the network. In a WP network users need only be “logged in” to be able to comment, right? In a single WP instance, a user must exist as a subscriber role to be able to be logged in. In a network, a user can be logged in without having a subscriber role. The OP wants “access only to site2”, but in a network, no user can both be logged into one subsite and not logged into the rest. That part of the original post cannot be resolved.

Just deactivate and uninstall – nothing else to undo. This plugin is lightweight and doesn’t add anything to the database.

I’ll offer my preference:

Child themes work slick in a multisite.

https://codex.www.ads-software.com/Child_Themes

You can network enable each child theme, or enable each child theme on a site by site basis via Network->Sites->Edit-> Themes tab.

Setting up the Child theme initially is cumbersome, but in the end you’ll be a-tinkerin’ with each site’s unique style.css soon enough. (Individual blog admins will be restricted to using a plugin, though). SuperAdmin can use built in theme editor ??

Uninstall the plugin. And try some troubleshooting.

I can’t reproduce the error you see with the steps you’ve described.

Perhaps you have installed the plugin incorrectly, or your multisite is not setup right.

Otherwise, I can’t imagine how this plugin could activate then deactivate itself then throw fatal errors.

I use a simple approach for my needs:
https://codex.www.ads-software.com/Function_Reference/is_user_member_of_blog

Managing site visibility by role other than Admins and Superadmins I don’t have a use for, sorry.

Redirecting an already logged in user to the login page would loop. SO we can’t do that.

Redirecting to a custom page on another blog could be done by removing the actions the plugin uses and add your own. I don’t need the plugin to do that, though.

Well, you have already concluded rightly that there is no user interface to alter via the dashboard. SO I can only really confirm there is no “easy” way.

If you are only wanting to edit the language strings, then you can do that using a localization or mo/po editor plugin.

Now, altering the “appearance” of any particular page can be done with CSS. Use your favourite browser add-on to figure out the id and class of the containers. I offer that you can alter all kinds of CSS using the Jetpack plugin:
https://jetpack.com/support/custom-css/

The problem you see once your snoop into page source generated by this plugin is the id and class names are the same as the login page. That means that altering CSS on this specific page you ask for may have the side-effect of altering the appearance of every page using the login form id and class names.

If you just want to “fork” this plugin (dupe it, then uninstall original), then you can edit its code. If you choose this route, you can tinker away with the function ds_login_header to edit the top half of the login form and then tinker with the functions that generates the bottom half, i.e., ds_members_authenticator.

If you would rather leave the plugin as is, you can add a plugin of your own to remove actions and then replace with your own.
https://codex.www.ads-software.com/Function_Reference/remove_action

So to start,
https://www.ads-software.com/support/topic/small-plugin-to-override-on-a-single-site/#post-8188641

But look/compare closely comments for changes since WP 4.7:
https://wordpress.stackexchange.com/questions/36013/remove-action-or-remove-filter-with-external-classes

• This reply was modified 8 years ago by David Sader.
• This reply was modified 8 years ago by David Sader.

Sorry, no. I have no use for this plugin.

I offer a couple ways to override or update an option on every site:

Both require a bit of courage and precision to use snippets willy-nilly – practice in a sandbox first.

First, a pre_option snippet so plugin settings do not go to db at all on sub sites:

https://codex.www.ads-software.com/Plugin_API/Filter_Reference/pre_option_(option_name)

https://www.ads-software.com/plugins/code-snippets/

Second,
wpmu_upgrade_site is a nice hook to send a mu-plugin snippet through every blog once, too.

function my_option_updates( $blog_id ) {
//$option
//$value 
update_blog_option( $blog_id, $option, $value ) ?>
}
add_action( 'wpmu_upgrade_site', 'my_option_updates' );

When you click “Upgrade Sites” in the network backend this hook will fire on each blog one after the other till it does them all.

• This reply was modified 8 years, 5 months ago by David Sader.
• This reply was modified 8 years, 5 months ago by David Sader.

In a Network there is only one location for the wp-signup.php (all links to Register i.e. /wp-login.php?action=register redirect to it). NetworkAdmin controls signups at one location /wp-admin/network/settings.php

Registration to a network of sites will allow all users that are logged in to pass the “is_user_logged_in” check. The “global pool” is what it is. Can’t change that. Network users are network users while logged in. So your Support site’s Discussion Settings (“Users must be registered and logged in to comment”) won’t restrict anyone but non-logged in visitors.

https://developer.www.ads-software.com/reference/functions/is_user_logged_in/

So, to restrict visibility on a “members only” support site you will need to use a function such as “is_user_member_of_blog” instead to wrap protected content. If you put a wrapper around certain parts of a theme file, only members will see that part of the page.

if ( is_user_member_of_blog() ) {
    /*
    * The user is a member of this blog.
    * We could do stuff here, like show them a link, etc.
    */
}

https://developer.www.ads-software.com/reference/functions/is_user_member_of_blog/

I offer my own plugin as an example, since I somewhat do what you are after:
https://www.ads-software.com/plugins/more-privacy-options/

Get users into the “members only pool” of the Support site and assign a role in the usual WordPress methods under the Support site’s “Dashboard->Users” menu.

This should get you most of the way to what you are after, I figure.

Network users do not register on subdomains, they signup to the entire network. They can login to any and all sites at once because all sites belong to one network.

Perhaps the following two core functions in WordPress will help or hinder your quest for a plugin solution:

https://developer.www.ads-software.com/reference/functions/is_user_logged_in/
https://developer.www.ads-software.com/reference/functions/is_user_member_of_blog/

In a WP Multisite network these two functions may not return the same True/False value when checked. In a network, a user can be logged in AND NOT a member of a site. To isolate sites from the prying eyes of other logged in users of the network, the plugin check should use the is_user_member_of_blog check vs is_user_logged_in I offer.

Here is a case use example I can offer: Commenting
Let’s say you want to restrict commenting on a blog to logged in users, all users of the network can comment when logged in. The Discussion Settings on each site can be toggled to handle this case. To restrict commenting to “members only”, you need a plugin for that. And would also then need to build the “member list of Users” on that site manually or via plugin as well.

In a network, a logged in user is logged in to every site/subdomain created in the network. Membership status is handled at the site level. Login status handled at the main network level. It will not be possible in a network to keep a user “logged in” to one site, and somehow “unlogged in” when visiting a second site on the network in the same browser/cookie session.

So, I offer that using the function “is_user_member_of_blog” will offer some creativity as you look into coding your own plugin, or cobbling together broken/unsupported code/plugins you have found for your project already.

Creating a 2nd child theme is a process identical to the first:

https://codex.www.ads-software.com/Child_Themes

When creating your child directories and stylesheet header just change the name is all.

myfavtheme
myfavtheme-child
myfavtheme-child2
myfavtheme-child3
myfavtheme-child4

In multisite, you need to visit the Network Themes panel to make themes “Network enabled” first:

/wp-admin/network/themes.php

then visit the site’s theme panel “activate” the child theme

/wp-admin/themes.php

• This reply was modified 8 years, 5 months ago by David Sader.