rvbinder

@ipstenu – there is no inter-site sharing I’m aware of. The second site is intentionally set up to allow new users to register a new site.

Here’s a graph that shows the “mesas”.
CPU Usage Graph

I’m also trying to get HTTPS plugin going on Multisite 4.1. The main landing site is https://sitedomain.com, and the https works fine for admin and public access to it. I have a wildcard cert for the main site.

New users may register a new subdomain blog, which I want to accessed via HTTPS for editing and viewing:

https://subdomain1.sitedomain.com
https://subdomain2.sitedomain.com
etc.

I don’t want the subdomain sites to be able to alter this configuration – plan to hide the HTTPS menu from them to do that.

I’ve RTM and tried several combinations of HTTPS settings in Network Settings for the entire site, but the new sites are set up as
https://subdomain1.sitedomain.com.

How can I get the new sites to be automatically registered as https?

I’m seeing this on 4.1 – seems to be version-related.

If a file hasn’t changed since the last time it was scanned it seems to me you don’t need to scan it again, unless you suspect the file date/time can be corrupted. So, scanning an unchanged file is needless. You don’t even need to maintain a list. Scan everything when the scan is first enabled, save that timestamp, then only rescan files that change after that.

I monitored cron, etc. Not the cause.

I unchecked the WordFence scan images option. This resulted in a dramatic drop in CPU utilization shown in the graph.

Here’s the actual CPU utilization graph.

Looks like some performance tuning of WordFence is called for.

My ISP claims that I have exceeded my CPU seconds quota this month. Google Analytics shows that the total page views for the month is very near the average of the year and well under the max of several months ago (which did not exceed that quota.) Besides upgrades to the newest WP version and plugins, the only substantive change I made to my site this month was to set the above scan option. Does the scan result in much high CPU utilization?

Yes. In case others want to do this, go to WordFence.options.Scans to include, then check “Scan image files as if they were executable”.

Thanks

Here’s an update.

1) I was able to determine the cause of the cookie error message and correct it. The problem occurred immediately after I added a new site in Multisite, which I have configured in “sub-domain” mode, but in which each site is presented as a unique full domain (a.com, b.com – not a.c.com, b.c.com) Each such domain is “parked” at my ISP. The last step in establishing a new domain is to obtain the well-hidden site id, then enter this into the panel presented by WordPress MU Domain Mapping plugin. I’d simply forgotten to do this last step. When I backtracked and did that, the login worked normally.

2) So, I’ll retract my characterization of this as a “bug” in the core. However, it certainly seems to me that the existing implementation is flawed in its handling of this situation and could provide better diagnostic information.

@sader I started this thread to let you know that the problem was not related to your plugin.

There seem to be many reports that are not in the “usually” category. Would you call this a “feature”?

There are hundreds of posts about this behavior, which seems to be triggered by routine use. I think that’s a bug.

And now, I cannot log into the site at all, using network admin credentials that I created it with.

Tried network deactivate, cannot login.

Tired deleting the plugin files, cannot login.

I get the “ERROR: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress” in all cases.

I just installed your plugin 3.7.1 into MS 3.8.1. I’m seeing the same confusing behavior reported by @computerkitten.

Per your suggestion, I made the hack on the plugin code.

The //add_action(‘login_form’ appears three times.

I commented out in all three – is that what you intended?

BTW, commenting out code to alter behavior is not good programming practice.

@mjn666’s approach would probably be a cleaner solution, but each of my sites uses a different theme and/or child theme, so that would be gnarly.

However, after making the suggested change to the plugin and attempting to login, I get
“ERROR: Cookies are blocked or not supported by your browser. You must enable cookies to use WordPress”

Although cookies are enabled, I get this in Chrome, IE 10, and Safari.

Please advise.

I’m trying to enable plugins on member sites. I checked the “Pludins” box, but member site admins cannot install site-specific plugins. So, it looks like the documentation is both out of date and wrong.

I’m having the same problem with 3.5.1 — none of the D&D controls or drop downs in the Widgets panel respond. I’ve tried deactivating plugins, switching themes, etc.

I’ll try a downgrade. Can I suggest you do better testing before your next release?

I’ve got the same problem, using “Twitter Feed for WordPress” plugin.

Having RTM, I see that you recommend client-side code to deal with this problem.

Can anyone recommend a twitter feed plugin that uses client-side code?

tia