[Closed] Updating toolset: invalid site key

[Author]

Posts

[takoL]

On our multisite installation hidden link we're trying to update the Toolset plugins but we get the following error:

Installer could not fetch subscription data for toolset. Error message: Invalid site key for the current site.

We tried unsubscribing the key, but this did not work
Then we tried removing the site from our sites/keys on our Toolset account and re-register the site, but to no avail.

This error could be caused by an action from our part: we have recently replaced the main site with a subsite. This has probably caused the site/key entry to be corrupted / invalid?

How can we fix this?
By manually removing a db entry?
Or by registering the site as a new site at Toolset.com and then manually entering the new valid site key into the database?
If so, which one?

Thanks in advance!

Floris

[Nigel]

From the custom installer page, unregister the site if it is already registered, and then use the link "Get a key for this site" to register the site again at toolset.com.

If the site is already registered it will offer the correct existing key, otherwise it will offer a new key.

That's the one way to ensure that the URL is correct. Any difference (even http vs https, for example) would render the site key invalid.

[takoL]

We tried that already, but we can not unregister the site: when we click 'unregister site' a loader icon appears and then nothing happens. Where in the DB is the site url / key stores? Maybe I can manually remove / repair those entries.

[Christian Cox]

Hi, the registration key is serialized, possibly gzipped, and encoded in base64 along with a whole load of other options depending on the other Toolset and WPML plugins you have installed. I'd have to ask my developers if this option key can be deleted without serious repercussions. Perhaps there is a plugin conflict or theme conflict preventing that unregistration process, and we can work around it instead of direct DB manipulation?
- Temporarily switch to a default theme like Twenty Twenty One
- Temporarily deactivate all plugins except Toolset Types (and a Maintenance Mode plugin would be fine if you want to prevent access during testing)
- Temporarily deactivate any custom code snippets in Toolset > Settings > Custom Code
- Try unregistering once again

If the process still hangs, perhaps a server-side error is being thrown and disrupting the AJAX call. Are any errors shown in the browser console? Do you have access to server-side error logs? Can you see if anything relevant is logged during that time period? If you are not familiar with server logs, I can show you how to activate one temporarily. Go in your wp-config.php file and look for

define('WP_DEBUG', false);

Change it to:

define('WP_DEBUG', true);

Then add these lines, just after the WP_DEBUG line:

define('WP_DEBUG_LOG', dirname(__FILE__) . '/error_log.txt');
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
define('WP_DISABLE_FATAL_ERROR_HANDLER',true);

Try to unregister again. If any server-side errors are triggered during this process, it will create an error_log.txt file in your site's root directory. Use FTP to look for this file in the same directory as wp-config.php. You may need to click "Refresh" in your FTP browser to see a new file appear. Please download this file to your computer, open it in any text editing software, and send me its contents. Once that is done, you can revert the changes you made to wp-config.php and delete the log file using FTP.

[Christian Cox]

Our developers have also asked me to find out if there are any problems reported on the Installer Support page. You can find that page after logging into wp-admin at /wp-admin/admin.php?page=otgs-installer-support

Can you take a screenshot or screenshots of this page showing any errors? Please include the screenshot with your next reply.

[takoL]

I've uploaded the requested screenshot.

I've also checked for errors in de server log when I try to unregister the site: there is no error in de logs.

I think this issue is caused by replacing the main site (siteid=1) with a subsite inside the network. The path will problably be different in the site_options after this replacement? Maybe the keys db cannot recognize the key for the path of the new main site and therefore also cannot unregister it?

[Christian Cox]

I think this issue is caused by replacing the main site (siteid=1) with a subsite inside the network. The path will problably be different in the site_options after this replacement? Maybe the keys db cannot recognize the key for the path of the new main site and therefore also cannot unregister it?
It should not be a problem if the current site domain/URL is different from the domain/URL used to initially register the site. I migrate sites often and unregister a previously registered site on a new temporary domain without any problems. Something else must be going on. Can you tell me if there is an AJAX request to admin-ajax.php after you click the Unregister link and confirm? See the screenshot here for an example. You can find the AJAX request in the browser's developer tools Network tab. Please include the response from the AJAX request in the browser console.

Normally a request to admin-ajax.php is triggered after the confirmation dialog, and the response should include some data like success:true. Then the page should reload automatically, and you should see that the plugin has been unregistered.

[Christian Cox]

Also, can you tell me if you are trying to unregister from one of the subsites or from the main network site?

If you are trying to unregister from a subsite, can you try unregistering from the main network site at main network site wp-admin > Plugins > Add New > Commercial tab?

[takoL]

Can you tell me if there is an AJAX request to admin-ajax.php after you click the Unregister link and confirm?
Yes there is an AJAX request.

Please include the response from the AJAX request in the browser console.
See attached file

Normally a request to admin-ajax.php is triggered after the confirmation dialog, and the response should include some data like success:true.
The only console message we get after confirmation dialog box is: [Violation] 'click' handler took 868ms

Then the page should reload automatically, and you should see that the plugin has been unregistered.
The console message disappears after a few seconds / new page load and then there are no messages anymore in console.

Also, can you tell me if you are trying to unregister from one of the subsites or from the main network site?
From the main network site

If you are trying to unregister from a subsite, can you try unregistering from the main network site at main network site wp-admin > Plugins > Add New > Commercial tab?
We tried this with the same result: admin-ajax request, no console messages, page refresh, still registered

Thanks in advance for looking in to this!

[Christian Cox]

You can use the "preserve log" feature in the developer tools to preserve the list of network requests, even after navigating away from the page. Can you try that, then inspect the response of the AJAX request? Screenshot showing these features in the Network tab of Chrome.

I've asked our installer team for more information and other options for updating the site key. I'll let you know what I find out. Until then, it's best to manually update plugins. You can download the current plugins from your account downloads area here at https://toolset.com/account/downloads/
Then

[takoL]

You mean this? See screenhost.
We will manually update the plugins in the mean time, no problem.

[Christian Cox]

No, that's the JavaScript console. I'm talking about the server's response to the AJAX request, in the Network tab. Open the browser console when the page loads, then open the Network tab and check the "Preserve Log" checkbox. Then clear all the existing requests with the "Clear" icon. Click "Unregister" and then confirm in the popup dialog. You will see an admin-ajax.php request appear. When the request is complete, click it and open the Response tab to see the server response.

[Christian Cox]

Can you check your wp-config.php file and see if "OTGS_INSTALLER_SITE_KEY" is defined in the config file? If so, can you update that definition key to match your new key? If this definition already exists and contains the correct site key, can you delete the definition from wp-config.php?

After you update your wp-config.php file on the server, test unregistering again.

[takoL]

server's response to the AJAX request
It says: failed to load resource data
Other admin ajax request from WP Heartbeat has a correct response though.

Can you check your wp-config.php file and see if "OTGS_INSTALLER_SITE_KEY" is defined in the config file?
The key OTGS_INSTALLER_SITE_KEY is not defined

[Christian Cox]

Okay thank you, I have discussed this with our developers and they believe a direct database intervention is necessary here. Registration information could be stored in these keys in a multisite installation:
wp_installer_network - sitemeta table
wp_installer_settings - options tables, all db prefixes

We suggest you create a full db backup first, then delete the wp_installer_network sitemeta entry. Try unregistering again at that point. If that does not allow you to unregister, delete the wp_installer_settings key/value entries from the options tables in each db prefix. Try unregistering once again, and let me know the results. I had some concern that deleting the DB entries could cause problems, but our developers informed me the system is designed to regenerate the DB entries automatically using system defaults.

After deleting those values and unregistering, verify the sites are all loading as expected. If you see any problems, revert the site using the database backup you just made.