Michael

I had the same problem with Shortcodes Ultimate 5.13.3.

It broke the Full Site Editor and Manage Patterns with a white screen of death.

Turning on PHP errors gave me a similar error to the above, except mine said Undefined constant “SECURE_AUTH_COOKIE”

Googling that error says that this has been known to happen on sites with Yoast installed, which I do have installed.

As @canarystudio stated, reverting to version 5.13.2 resolved my issue.

For us, the problem is that because WP Cassify sets that PHP Session cookie on every single page for every single visitor, that busts the cache for every page, so we are getting zero percent cache hit rate in Pantheon.

https://pantheon.io/docs/cookies#cache-busting-cookies

We have worked around it being a PHP Session cookie (not supported on Pantheon) by using the WP Native PHP Sessions plugin, but that just changes how the cookie is stored, we still have the problem of it being on every page.

I had hoped that turning off Gateway Mode (auto login) in WP Cassify would limit the session cookies to just certain pages, but no.

I would welcome any of the options mentioned by @kkatpcc

Thank you. After upgrading to WP Cassify 2.2, I am now able to activate the MailPoet 3 plugin.

I was also unable to edit the Testimonial text, but I think the problem is just in Safari. I first tested on my primary WordPress environment. Then I spun up a fresh poopy.life site and only installed the Astra theme and then the Ultimate Addons for Gutenberg plugin. Then I updated to WordPress 5.2.1. I edited the Sample Page, inserted a Testimonial block, but I could not edit the text. I was using Safari under macOS Mojave.

When I switched to Google Chrome, everything was fine.

Ysintos,

Your CAS server probably has at least two endpoints, a CAS-2-compatible one that doesn’t have attributes (other than username) and a CAS-3-compatible one.

If your CAS server is configured correctly (ours is not, unfortunately, but that is another story), you should be able to point to the CAS 3 version protocol endpoint and get attributes.

https://apereo.github.io/cas/5.0.x/protocol/CAS-Protocol.html
“Among all features, the most noticeable update between versions 2.0 and 3.0 is the ability to return the authentication/user attributes through the new /p3/serviceValidate response, in addition to the /serviceValidate endpoint from CAS 2.0 protocol.”

Most CAS servers also have a third CAS endpoint, a SAML 1.1 one (with attributes returned in an XML SOAP response) at /samlValidate; however, WP Cassify doesn’t support the SAML one.

Michael

Unfortunately, there are Composer dependencies for Swift Mailer in WP Cassify that makes its removal problematic. I will see if the plugin author for WP Cassify can fix this, otherwise I will need to hack the plugin before I can move to MailPoet 3.

The main reason why I mentioned it in the forum for this plugin is because MailPoet 2 was fine with it, but MailPoet 3 won’t even activate.

Yes, as the title and topic tags suggest, it is the presence of Swift Mailer that MailPoet 3 does not like. Unfortunately, Swift Mailer is a dependency of our single-sign-on plugin.

I confirmed that upgrading to release 2.1.9 resolved this issue. After upgrading, we no longer see this error when logging in.

Thank you.

Thank you, James. I submitted an issue on Github.
https://github.com/Automattic/jetpack/issues/11982

Also, because CAS is our only allowed authentication source, we had already disabled both “Allow users to log into this site using WordPress.com accounts” on all individual sites and “Allow individual site administrators to manage their own connections (connect and disconnect) to WordPress.com” (network).

+1 on this demand. We use Pantheon hosting, which relies on git for deployment. Until I manually deleted the .git folder and .gitignore file, Pantheon could not see any of the files in this folder, so I could not deploy from Dev to Test.

This is what I am referring to.

https://www.dropbox.com/s/xjkfbibphmpokdj/adware.png

I administer an enterprise content management system with thousands of users. I install a free plugin from www.remarpro.com to fill a specific need. I carefully vet this plugin, and then activate it across the network.

Years later, I’m a few months behind on patching plugins on the system. I’ve kept up with security patches, but held off on bug fix updates. I apply a bunch of point updates, including one for Remote Image After Upload. I read the release notes, but I don’t test as thoroughly as I should have. A few days later I get support tickets from confused customers, wondering why there are advertisements at the top of every admin page in said content management system. “Why are there ads? Should they install this software? Was my site hacked?”

I look at the source code and see a “riau” class. After going through the plugin list, I figure out that it is the Remote Image After Upload plugin that betrayed my trust.

I apologize to my university colleagues who submitted the support tickets. I then have to decide between patching this plugin or removing this plugin (or visiting every site using this plug to click the close buttons on these advertisements).

I really wouldn’t mind if the plugin author promoted his or her software on the config page for the plugin, but to hijack every page of the WordPress dashboard is unacceptable.

I am not sure if this makes a difference, but we had tested quite a few sites with Jetpack 6.3.2, and they all seemed to load fine, but with the site that our customer reported the WSOD, the Jetpack plugin had never been set up.

I still downgraded to Jetpack 6.2.1. We can’t use Simple Payments anyway. It would jeopardize our non-profit status.

I am getting a fatal error with sites in our multisite network, running Jetpack 6.3.2 and PHP 5.6.37. We held off on upgrading from 6.2.1. I guess we should have held off longer.

What is especially frustrating is that some sites in the multisite network are loading just fine, but others are showing a WSOD and generating the fatal error.

Fatal error: Class ‘Jetpack_Simple_Payments’ not found in /srv/bindings/XXXX/code/wp-content/plugins/jetpack/modules/widgets/simple-payments.php on line 479

Sorry for the delay in responding. We have a setup that mixes subdomains and subdirectories in the same multisite system. So when LH HSTS is activated, subdomain sites are fine, but subdirectory sites get the infinite redirects.
https://blogs-dev.princeton.edu (main site, okay)
https://blogs-dev.princeton.edu/wdstest/ (subdirectory site, infinite redirects)
https://perla-dev.princeton.edu (subdomain site, okay)

I have the same issue.

I get an infinite redirect when I try to activate LH HSTS. The main site works fine, but all subdirectory sites have too many redirects.
https://blogs-dev.princeton.edu/wdstest/
https://blogs-dev.princeton.edu/hsts-test/

I deactivated all plugins, including mu-plugins, and I then reactivated LH HSTS.

Too many redirects occurred trying to open “https://blogs-dev.princeton.edu/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/wdstest/”.

/wp-admin works fine on both the main site and the subdirectory sites.