Extensions Error

Hi @cavalierlife,

I speculate that this might be an issue with the PHP installation. e.g. Floating point errors.
Nevertheless, the plugin verifies its settings so no unsolicited API connections can be made.

With “Deactivate account” it means the “Deactivate Account” button found in the “Account and Actions” box on its WordPress settings page. I’ll see if I can improve the semantics in an upcoming update.

When you click on that button, it will ask you if you’re sure: click it again after it turns red.
Then it will try to disconnect your site (if it’s connected) and it will remove all activation settings. All extension options (if any) are held intact.

Then, you should see the activation page. Follow the steps provided there (enter a key or go free) and you should be able to activate the extensions again.

If the deactivation button doesn’t work or isn’t visible, let me know!

I do not have an Account and Actions area, nor do I have a Deactivate button. None of this exists for me.

Hi @cavalierlife,

It’s a bummer to hear you’re still encountering issues. I’m wondering what screen you’re seeing, as you can’t view those settings. Could you send me a screenshot of it when you find the time?

In any case, I created a little plugin for you that should get you out of this issue instantly.

> View it here.
> Download it here.

Usage:

1. Download the plugin ZIP folder above.
2. Open ZIP contents, and store file reset-tsfem.php somewhere on your computer.
3. Connect to your site using FTP.
4. Upload reset-tsfem.php to ../wp-content/plugins/
5. Activate the plugin “Reset TSFEM activation settings”.

After that, you can simply delete the plugin through the WordPress plugin management interface.

If even that doesn’t let you reactivate the plugin once more, then please contact me privately with a link to your site and I’ll see what I can do from there.

That worked! Now I see all those things. That entire page was being replaced by the error, but once I activated the above plugin, it was all there again. Thank you!!

I also ran into this issue and the plugin above resolved it. It would be nice to know what we did, though, to cause it. Just so we can avoid it in the future?

Hi @insiderperks,

This happens after moving sites, so where the wp-config.php salts or the domain differs. If any of those change, the integrity checks will fail as those variables are used as keys for its hashing.

A popular use-case for this is WP Engine’s staging environment.
Another would be using ServerPilot, where the home option is dynamic (which is bad).

So a question then. What if we regularly change our salts for security purposes?

• This reply was modified 6 years, 11 months ago by insiderperks.

Hi @insiderperks,

I don’t see a reason why you would. The salts are there to prevent rainbow table lookups for when your database gets hijacked, there’s nothing much more to that. Changing them would mean that every user needs to update the password too. Even when the salts become public, or even when your database is exposed, there’s little concern as it’ll take many years before a password is cracked. Many magnitudes of order more so if both are securely obscure.

Take the above with a grain of salt, as not every WordPress installation uses secure-enough password storage. It’s always good to change your password every so often. Also, changing the salts and keys after they become exposed is a good practice too.

Regardless of the above, I did test it out before releasing TSFEM version 1.0.0, and at that moment I knew the “Deactivate” button would pertain effectiveness. Why and whether that has changed is yet to be determined, as I laid focus on the 3.0 version release of TSF last month.

The gist is that when the integrity of the settings can’t be verified, only the API activation and activated extension settings will be rendered inefficacious. All other settings–like your department settings in Local SEO–shouldn’t be affected. So, there’s little harm done when moving sites and/or having to change salts and keys.

When that happens, those settings need to be reset. This can be manually done with the deactivation button. The little plugin I shared above does exactly what the deactivation button should do, and I might have to implement it better in TSFEM when this happens. More on this will follow as I learn more.

Quick update: In the upcoming version (1.5) this issue will no longer cause a block-out from the overview page.

There’s still a lot to be done, so I can’t promise an ETA.