Charles Fulton

I can confirm that @kkatpcc’s fix resolves the session issues that we reported earlier. We’ve published a git clone of the SVN repository containing the fix, the PHP 8 fixes that Jesse Loesberg authored, and a few local changes: https://github.com/LafColITS/wp-cassify. We don’t use gateway mode either so I can’t speak to whether it’s affected.

We installed and activated it prior to going to 5.0 so that Gutenberg was never presented to our users.

With one exception, all the differences are explained by integration tools and unit tests. It makes sense to include those in the repository of record (GitHub) but not a publishing repository like the WordPress plugins repository. The exception is wpcom-helper.php, but I don’t think that’s ever been included here. The active code for the plugin appears to be the same whether you’re getting it here or from GitHub.

Apologies, we had an older version of the plugin installed and this issue was resolved in the 4.6 release.

Thanks, that makes sense.

It’s a solution, but I think the plugin should have worked in either scenario.

I’ve opened a bug report on GitHub with a candidate fix: https://github.com/Automattic/wp-super-cache/issues/380.

I’m seeing this as well, and it’s almost certainly not a permission issue. I’m investigating further.

We’re experiencing a related problem with wp-login.php. I think the root issue is that wp_cassify_get_service_callback_url relies on home_url() to build the callback, but home_url can’t be relied on to return a login page over HTTPS. See https://core.trac.www.ads-software.com/ticket/16822 for why. I think you can safely replace home_url() with site_url() to achieve the desired behavior.

@meitar I didn’t wind up trying that because I ran into the issue that get_sites returns objects instead of an array (which I see you’ve addressed). I tried passing null to the limit parameter for wp_get_sites but that didn’t work. Raising it to 1200 did, though it took a little bit. I expect with an even larger installation there’s a risk of a timeout.

Oddly, I got this message at the end:

Fatal error: include(): Cannot redeclare class wp_multisite_directory in ../wp-admin/includes/plugin.php on line 1882

Despite that, it did network-activate.

I’ve encountered the same problem. I have a development environment with approximately 1,000 sites. These were all created manually. On network activation the plugin created entries for 98 of them. Looking at the code, I think the problem is that wp_get_sites (now just get_sites), returns a maximum of 100 sites by default. You can override that with the number parameter.

It looks like this was fixed on GitHub (https://github.com/phillord/mathjax-latex/issues/18) but it would nice to get a formal release here as well before April 30.

I think I’m missing something here. I wouldn’t expect an authorization plugin to make decisions about who gains access to what site in a multisite instance. If I network-activate this plugin I’m doing so because I want every site to my institution’s CAS instance, not because I want every user at my institution to have access, however limited, to every single site in that multisite instance. This sounds like a massive security hole and completely unexpected behavior.

A user should have a role in the main site, and any other sites to which they are explicitly granted access. I don’t think a user would expect to suddenly have access in every site in that instance, and I can see it leading to mass confusion, even panic, in some cases.

It should be possible to turn it on or off at the network level. At the very least this should be filterable so that one doesn’t have to hack the plugin to disable this functionality. Have you tested this behavior at all in large environments? My institution has several 1000 site+ installations, I have to wonder what would happen when several students logged in at once (and they got access to all the class blogs which they weren’t members of, leading to angry phone calls from instructors). I’d say this use case is a deal-breaker for higher education.

Same as everyone else. I’m running the latest wp-cli from github; and I don’t have this problem with other 4.4 sites.

We’re seeing this issue with about 90% of our file imports. At least in our use case, the problem is that the upload script creates a zero-length placeholder and downloads the headers for the upload, but the compares the filesize of the placeholder against the content-length header of the actual file. If they mismatch, it errors. I’m not sure what this conditional is meant to accomplish, but it feels wrong.