David Sader

Each site’s outgoing RSS has built in hooks/filters.

The usual template tags can be used to echo whatever you like in the outgoing feed title:

I offer the following mu-plugin snippet:

<?php
add_filter('the_title_rss', 'ds_rss_post_title');

function ds_rss_post_title($title) {
   $blogname = bloginfo( 'name' );
   $title = $blogname . ': ' . $title;
	return $title ;
}
?>

That’ll get you [Blog name]: [Post Title] in each site’s own RSS feed.

However, what plugin is used to generate your “main RSS feed”?
I use Donncha’s MU Sitewide Tags Plugin to generate my network feed.
So I offer for your consideration a plugin snippet I use only on the “Tags Blog”:

<?php 

add_filter('the_title_rss', 'ds_rss_post_title');

function ds_rss_post_title($title) {
global $post;

list( $post_blog_id, $post_id ) = explode( '.', substr($post->guid, 7));
//$blogname = bloginfo( 'name' );
//$blogname = $post_blog_id . ': ' . $post_id;
//$blogname = get_blog_permalink($post_blog_id,$post_id);

  $blog_details = get_blog_details($post_blog_id);
  $blogname = $blog_details->blogname;

$title = $blogname . ': ' . $title;

	return $title ;
}
?>

That gets me [Blog name]: [Post Title] in my Network RSS feed.

I do not use this plugin to decline new users. Users are going to be added to the network – whether or not they have an active blog is the issue.

You are right, if SuperAdmin never approves, potentially the queue gets pretty full of blogs awaiting moderation. Sending out an email hooked to the blog delete action is possible. I don’t have a need for a “the blog you never quite finished creating has been deleted” email.

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

Exactly that snippet above inside a *.php file in your mu-plugins folder.

When you upgrade, mu-plugins will still be there. All kinds of WP trickery can be loaded from there.

I use my own plugin with default settings for it and a gazillions of others in this or similar ways.

First, the wordpress functions can’t send mail if your server can’t.

Second, the error is curious. The error in the ms-load.php is new, and not caused by the plugin as near as I can figure out. There have been recent changes to code in that core file. Hmmm.

A workaround until ms-load.php is fixed is to build your own /wp-content/blog-inactive.php file and add the following (or your own custom message)

wp_die( sprintf( __( 'This site has not been activated yet. If you are having problems activating your site, please contact <a href="mailto:%1$s">%1$s</a>.' ), str_replace( '@', ' AT ', get_site_option( 'admin_email', 'support@' . get_current_site()->domain ) ) ) );

FYI, the ms-load.php error on line 103 goes away replacing:
%s with %1$s

Do not edit core files.

The following snippet works in a drop-in blog-inactive.php plugin too.

$admin_email = str_replace( '@', ' AT ', get_site_option( 'admin_email', 'support@' . get_current_site()->domain ) );
			wp_die(
				/* translators: %s: admin email link */
				sprintf( __( 'This site has not been activated yet. If you are having problems activating your site, please contact %s.' ),
					sprintf( '<a href="mailto:%1$s">%1$s</a>', $admin_email )
				)
			);

https://core.trac.www.ads-software.com/changeset/35453

Here is a non-coder plugin to set all sorts of options by default for new blogs:

https://www.ads-software.com/plugins/wpmu-new-blog-defaults/

The wpmu-new-blog-defaults plugin is not current, but it might still work.

However, creating your own mu-plugin to set your own default settings/options is what I do recommend:

<?php
add_action('wpmu_new_blog', 'ds_new_blog_settings');
function ds_new_blog_settings($blog_id) {
update_blog_option($blog_id, 'blog_public', '-1' );  // 1, 0, -1, -2, or -3
}
?>

Users should already have received an activation and welcome emails. The content of the welcome note can be edited in your Network->Settings page:

You could resend the same newblog_notify_siteadmin email automagically when you do (re)activate the blog by using a plugin to hook the activate_blog action :

<?php
	function ds_activate_email($id) {
        	newblog_notify_siteadmin($id);
	}
	add_action( 'activate_blog', 'ds_activate_email');
?>

I do not see a need for the additional automatic email. Requests for manual activation come via email, so I just reply to email in the usual way.

Thanks for the report.

Also:

You said
“Before activating “More Privacy Options” on subsites”

and

” after activating “More Privacy Options” on subsites”

The plugin activation is done only once in the Network admin of the main site. It must be “Network Activated”. It should not appear as a plugin anywhere else in the subsites – only as additional Reading settings.

The plugin header has Network: true

Therefore the plugin is only visible and activatable at the Network Admin page in a correctly configured Multisite Network.

I think I can smell what you are stepping in if you can explain more clearly how you did this:

” the “main” site is placed at root level. Subsites are in subdirectories.”

Sounds like you have more than one instance of WP running. The plugin calls auth_redirect, which is a function run by the core files, not the plugin – if auth_redirect borks – there is something wonky in the vanilla install.

The plugin is designed for a WordPress Multisite Network, created according the the following instructions: https://codex.www.ads-software.com/Create_A_Network

It will not work as expected in a cobbled together patchwork of single instances, if that’s what you have.

Typical usage of this plugin is to keep the main site visible, only the subsites would then have an option to be less visible.

If everything is to be hidden, manual blog/user creation is best option, no?

At any rate, the plugin should not be causing the wp-signup.php page to be “unfound”. Something is amiss there. WordPress Multisite should redirect requests for the register page to wp-signup.php. Do you have other plugins altering reading/visibility settings?

You sure you have installed the plugin on a WordPress Multisite and network activated it?

Anyway, in my case, I want the plugin to have the option to limit access to new blog signup to logged in users. I do have a need to have the plugin limit new blog creation to admins only as well, but not the general public, subscribers, etc. During the season where signups to the public are open, privacy of the main blog is also public, then. When public signups are closed, I can still allow blog creation by members only, see?

Or delv into code by adding your own plugin to remove_action. Examples to do that are in the plugin already connected to wp-activate.php hooks.

I do not have all the answers for toolbar responsiveness. And I have not created a “hamburger” icon in the toolbar.

Not really certain what would work for your site/theme, but here is a bit o’ style that might work when the admin bar links disappear:

#wp-toolbar > ul > li {display:block;}

So,

function mytoolbar_style() {
        echo '<style type="text/css" media="all">
        body {
                padding-top: 30px !important;
                }
        #wp-toolbar > ul > li {
                display:block;
                }
        </style>';
}

You will need to open other threads or discussion topics for more help on making the default toolbar more responsive on smaller devices. You are not alone in your attempts to make the default toolbar more responsive. I wager however, most prefer to disable it altogether on small screens. Those menu links start getting pretty tiny, if you try to fit them into a 2 inch wide display.

Anyway, test the toolbar by itself without any customizations for responsiveness, first. Notice what cruft WP is chucking out as the screen reduces first. Pretty tough to do more with less.

Look at the built-in admin-bar.php and its admin-bar.css to see if you can figure out what is happening when WP detects the various screen sizes in the first place.

Lots of voodoo in the code there. If WP hides the hooks you are plugging into, then there is not much you can do.

Add the meta and class when adding menu nodes one at a time. Trial and error.

Oh, and have a close look at your original post example, bbcamerica.com for its responsiveness. The toolbar we were trying to replicate goes bye-bye there.

Do not edit core files. But it looks like you have figured that out, hopefully.

Create plugins. The hook and filters you are writing in the code snippet are for WordPress “plugin” API. Plugin.

Read “how to make a wordpress plugin“. But it looks like that is a lot for your first plugin. There are gazillion tutorials out there for simple, minimalist WordPress plugins. (Look at the source code of the “Hello Dolly” plugin).

But an even more minimalist method I prefer for such customized bits of plugin code is to create an “mu-plugins” folder and then create a *.php file in there to add your own custom php snippets.

So, the snippet I started in the pastebin above could be pasted into a php file you create in your own mu-plugins folder. That is where mine is and it looks pretty much like the snippet I shared above.

Here’s a start:

https://pastebin.com/ZNtCM516

I offer the following approach:

https://codex.www.ads-software.com/Toolbar
https://generatewp.com/toolbar/

Step One: Enable the built in toolbar for visitors
show_admin_bar: enable the showing of the toolbar on the front site for guests to see.

Step Two: add your menu items to it
wp_before_admin_bar_render: action to modify menu items

Step Three: tweak your style
wp_head: action hook to add style/css

auth_redirect is a WordPress function called in this plugin. In contrast to calling wp-login.php directly where user goes through to the dashboard, auth_redirect should send user back to the request url. SO yeah, something appears amiss as you describe it.

auth_redirect function is also pluggable and hookable and may be altered by other plugins.

This plugin does not alter auth_redirect … so perhaps some other login redirect is at play there.