mycbhcomwebsites

Ditto!

Thanks for your replies! I was unaware that nginx servers required that version. The host did migrate my account onto a different server / setup which coincided with the different output. The funny thing is that not all the sites are producing that output.

Was fearing a hack especially since google searches did not verify the validity of the deny (IP) format. Thanks again for a great relief!

I did it again and remembered that I needed to use a “normal” username.
The latest install that didn’t work had a hardened username (I previously said not to use one).

So this time, it worked.

I’d like to know what others experience who share some of the conditions I have described above in my posts and does my final resolution work in your case?

Sorry guys, I thought two tests would be enough and sure enough the third time I tried it broke again!
This seems an inconsistent issue at least for my situation.
Hit and miss!

I have contacted my host to see if the techs can test and put their brains to work on this one…..

OK, I’ve made many tests and here is what I found in MY SCENARIO.

Over the years, I have gotten into the habit of changing WP prefixes for database and tables.

I believe that all my standing multi-sites were so customized.
The host did a fresh upgrade to their server sides but Softaculous would still produce broken multi-sites (with add-ons and prefixes moded).

So I just did straight forward installs of new multi-sites without add-ons, without changing prefixes Nothing except ticking the multi-site on and I created 2 working multi-sites.

My recommendation is that WP either inform users that changing prefixes is no longer a security enhancement option or to fix this issue in future updates so that we can add the prefix customization option as well as other add-on options to the install of a multi-site.

Hope this helps.

OK, I did some testing and comparative multisite installs. it seems that either a hardened username and/or the installs including softaculous loginizer plugin, and settings for auto upgrade and all such pre-install options causes the break in my case.

I will attempt new installs adding options one by one and report back as to which add-on reproduces the break.

Quickest fix is to export your pages and posts for each site/sub-site and do a fresh install without any add-on options, add your sub-sites and Import your posts and pages again.

My .htaccess file looks like this:

RewriteEngine On
RewriteBase /wordpress/
RewriteRule ^index\.php$ – [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Are there any issues anyone can see for a 4.4.2 Multi-site enabled install?

Hi Bernard_F,
Since the recent update 4.4.2, my multisites have lost plugin directory tab, access and other admin navigation disruption (can’t see or access usual plugins)

Your fix creates the following issue for my situation:
I already have an .htaccess file
I also have a .htaccess.ninjaxxxxx file for the ninja firewall plugin I use.

Now you say to “add” another .htaccess file – do you mean:
To place a new standard .htaccess file named ?
Or to replace the original .htaccess file with a new non-modified one?

Or what exactly? Thank you and anyone else for your valued contributions.