Bad Standard Operating Procedure

Hi @thanewest, when you deactivate the plugin, it will ask you if you want to deactivate and keep https, or if you want to revert to http.

If you used a very old version of the plugin, this feature may not have been there. I’m guessing this is what happened.

Let me know if you have any questions about this.

Hey @rogierlankhorst, that’s only true if you click the “deactivate” link directly on the plugin description/line area. I used the bulk select and bulk select dropdown to disable RS SSL and there was no popup (nor consent) for RS SSL to alter my site data.

Hi @thanewest,

Thanks for the additional info. That explains a lot. I can confirm that we don’t have this popup for this specific situation. I’m afraid a popup is not possible in this case.

Let me explain why the default method reverts to http. There are essentially two situations.

– When SSL is not enabled yet, it does not revert to http even when the site is on https, because no change has been detected, so no need to revert.
– When SSl is enabled, most users who deactivate want to deactivate because they have an issue with the SSL certificate. In that case they need to revert to http to access their site again. This is why the default method is to revert to http.

This leaves a group of users who have SSL enabled, but want to deactivate the plugin, and keep https. To accommodate these users we have added the popup which offers users this choice.

Unfortunately, this popup is not available on bulk deactivations, due to the technical nature of the bulk deactivation: you are deactivating multiple plugins at once, so there’s no option to ask anything about a specific deactivation.

I’m sorry you ran into this issue, I will think about options to allow this option for bulk deactivation as well. If you have any suggestions how to do this without depriving users with a valid certificate from the revert option, we’re happy to add that to the plugin.

Luckily your issue can be fixed by adding

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

To your wp-config.php, where you can replace example.com with your domain of course.

Let me know if that works for you.

It’s disingenuous and the truth is more likely that it’s done to CAUSE errors and get people to leave the plugin installed. Nobody is going to believe the plugin is altering people’s private data (without consent) for the better of the user.

Nobody is going to leave the plugin installed if it causes errors. That would be one of the strangest arguments I have ever heard. You don’t have the plugin installed anymore, right?

I have explained the logic, which is based on 6 years of experience with all kinds of users and works quite well for a lot of users.

Except for one edge case situation that has never been reported before. I have offered to add your issue to the roadmap, and invited you, as free community collaborator, to share your suggestions.

There’s nothing more I can do. You seem determined to mistrust our motives whatever I say or do, so can’t help you any further I’m afraid.

I’ll leave it at that.

Sorry, you seem to have misread this review as a support request. This is a review of a plugin’s bad practice, plugin dev can take it or leave it, it is what it is.