WP Toolkit - General Discussion

[Robin Scott]

Hi All,

Since a recent update (last Thursday this was working) in Plesk, one server I oversee has lost the connection of WPT and the login for admin. This is across all installations. Has a recent update changed the admin username in some way? Its failing to update too:



I posted a thread on this earlier, but could use a pointer or I'm getting tickets on this my side tomorrow morning

 

[zanuda]

Does this happen with all the WordPress instances on the server or just with one of them?
Are you trying to change the main admin's password or for an additional admin?
Could you please go to list of all the WordPress instances as Plesk admin, click "Updates" then click "Check Updates" button, after that please check is it possible to set admin's password?

 

[David974]

Hi,

I have purchased the "Smart Update" option of the wordpress toolkit.

I am using on all my websites "WP Super Cache" plugin to speed up my websites, is there any modification to do with smart update ?

I think for example that if smart update test the "in cache" version of the cloned website, it will not correctly detect the error on the website.

In this case, is there a possibility to automatically empty the cache before the smart update ?

Thanks,
David.

 

[Robin Scott]

Does this happen with all the WordPress instances on the server or just with one of them?
Are you trying to change the main admin's password or for an additional admin?
Could you please go to list of all the WordPress instances as Plesk admin, click "Updates" then click "Check Updates" button, after that please check is it possible to set admin's password?

1) This happens with all WordPress instances. All 195 of them. Hence "this is across all installations" - this is what this means.

2) I'm not trying to change the main administrators password - I'm trying to login as the main administrator. The login option is not visible. I attempt to change the password in order to attempt to "re-connect" WPT with this WordPress site - and I get the warning I screenshotted. I can still login because I can change the password in MySQL - but users on the system cannot, except for the one admin whose email address can process a password reset (i.e. like "normal" WordPress - for which, no "Toolkit" is needed!). The workflow for users in this system is they each login to Plesk to access WP admin - they do not store the admin passwords. Its what the WPT was doing here - providing a login interface. This, and only this, has stopped working.

3) I pressed the "check updates" button. If I'm not mistaken, this checks for plugin and theme updates on each WP site? This would not change anything related to the administrator login information - or would it.

For a little extra detail, there were a couple of sites where this does work. Both have the db prefix `wp_` - the existing sites where this does not work have the db prefix `wordpress_` - I'm not 100% sure what relevance this would have, but I wonder if it may point to the source of this edge case I am experiencing?

Extra information in the as yet unreplied thread here: Issue - WordPress Toolkit - Lost (and can't update) Admin Logins

 

[David974]

Hi All,

I have detected something working wrong with theme update and extension update.

I am using DIVI theme, and DIVI builder extension, lifetime license (for update).

So, in wp toolkit : I scan, and do a refresh scan, nothing detected to be updated.

Log into wordpress admin panel : search for update : detecting 2 update : DIVI theme + extension (builder) (outdated since at least 2 month).

Re-check in wp toolkit : now it detect theme update available (because I have go on wordpress admin panel I think), but no extension update is available.

Theme updated correctly in wp toolkit.

To update extension, its necessary to use the wordpress panel.

So, the problem is that free extension is updated correctly with wp-toolkit (like WP SUPER CACHE), but paid extension like DIVI, is not detected to be updated. Partially detected if I go to wordpress admin panel.

Please, can you correct this bug ?

Precision : my updating key / account is registered on the application and everything is fine using wordpress admin panel.

Fail to detect only on wp toolkit.

Thanks,

David.

 

[Tomek]

Hi,

Is it possible to automatically send an e-mail with login credentials information after the Worpdress installation?

When WordPress is installed automatically on subscription creation, the user does not have credentials to log in to Wordpress. He does not know what to do. Email with login details would tell him what to do next.

 

[Tomek]

I found a bug in WordPress Toolkit 3.3.1-999


When Wordpress is automatically installed with the hosting plan, then the default Wordpress language is always English (not the same as the language of the Plesk customer interface).

 

[custer]

Hi everyone,

We have released a new version of WordPress Toolkit: v3.4.0. This version includes a bunch of new features, improvements and a record-setting number of bugfixes making it to the release notes.

Here's an overview of the new stuff introduced in WPT 3.4:

• We have added the following new commands to the wp-toolkit CLI utility: sets, plugins, and themes. These commands are supposed to be used in provisioning scripts by the web studios and managed hosters looking to automate their Managed WordPress offerings.
  
  The sets command allows server administrator to create a new set, add plugins and themes to a set, remove them from a set, view set contents, rename sets, and install sets on existing WordPress instances.
  The plugins command can display the list of custom plugins available on the server, upload custom plugins from external URL or from local path, install custom plugins from the server on selected WordPress instances, and remove custom plugins from the server.
  The themes command does everything the plugins command does, but for custom themes.
  
  To learn about using these commands, run plesk ext wp-toolkit --help in the command line.
  
  We hope this improvement will make WordPress Toolkit more attractive to use for larger-scale WordPress hosting. Our technical documentation team is working on a document that will describe how hosters and studios can tie these commands together to set up the provisioning of customized WordPress instances to their clients. Stay tuned!

• We have redesigned the Security screens, both for a single instance and for multiple instances.
  
  Changes on the single-instance Security screen were focused on improving and standardizing the user experience. We've combined all security measures into a single standard list (as opposed to two different non-standard lists) so that you don’t have to jump between two lists, and moved all relevant controls on top of the unified list, right where you expect them to be. This change should make the experience of working with this screen more familiar and predictable, since the UI and UX are now more in-line with the other WPT and Plesk screens (in a good way).
  
  For additional convenience, users can now sort security measures by their status and revert multiple measures at once, if needed.
  
  Old Security screen for a single instance:
  
  
  
  New Security screen for a single instance:
  
  
  
  We have also optimized the way WPT checks the security status for a single instance. If WPT has checked the security of an instance less than one hour ago, the security information is displayed from the cache. If security status was checked more than one hour ago, WPT will recheck it and refresh the cache. The time and date of the last security check is immediately displayed for the user, who can decide to force the security check at any time by clicking the corresponding button. This behavior was initially introduced on the Security screen for multiple instances in WPT 3.3, because constant security rechecks were clearly very annoying, especially when working with multiple instances. Our internal usability testing has unquestionably confirmed this problem, and since the Security screen for a single instance was being redesigned, we have propagated the same security check logic to this screen for consistency and convenience.
  
  The Security screen for multiple WordPress instances was also reworked to be better than ever. The biggest change is the ability to choose which security measures you want to apply to the selected instances. This ability was present in WPT since the very first version, but it was unfortunately lost during the transition to new UI in WPT 3.0. Later on, WPT v3.2 has brought this ability back, but in a limited way – you could only apply all critical measures at once (indiscriminately). Now it's possible to apply any selection of security measures on any number of available instances, giving users the long-desired flexibility (yes, we've received quite a lot of requests about this):
  
  
  
  Another noticeable feature that was actually not available before is the ability to revert a number of security changes on selected instances. This feature was requested by several WPT users on the forum and Uservoice. It might come in handy when an optional security measure prevents a plugin from working correctly on several instances:
  
  
  
  
  
  
  
• Users can now detach and remove multiple WordPress instances with a single action. Removal and detaching operations are not done that often, but when you have to perform them on several instances, doing it one-by-one can be a pain. We've had a couple of minor complaints about the lack of this functionality over the years. Fortunately, adding the ability to perform mass removal and detach operations turned out to be relatively cheap, so here they are:
  
  
  
  

 

[custer]

• Server administrators using Plesk Onyx versions 17.0 and 17.5 will see a gentle reminder that upgrading Plesk to Onyx 17.8 will give them access to a constant stream of new WordPress Toolkit features (and a brand new UI to boot). It's a small but very important notification because not everyone realizes that new WPT UI features are available only in Plesk Onyx 17.8 since they require the Plesk UI Library (which is available only in Onyx 17.8). This oversight became particularly evident during our communications with WPT users on this year's WordCamp Europe, so we've decided to act on it.
  
  The reminder is displayed on the old Instances tab, it has a link to Plesk Installer and it can be closed (obviously). We hope this humble contribution from WPT team will encourage people to upgrade their Plesk servers, since not all users realize they're really missing out on many cool features offered by WPT and Plesk itself. Here's how the reminder looks:
  
  

• Users can now clearly see the indication that a new website screenshot is being made. Making a screenshot is not instantaneous, so when users were performing major visual changes (like switching between different themes), the lack of information about the new screenshot status was quite confusing. Naturally, users complained during our internal usability testing, since they were not getting any feedback about their actions from the product -- you don't know if something is going on, you don't know if anything's wrong, and so on. This uncertainty is now fixed, and the screenshot part of an instance card is temporarily greyed out with a spinner when a new screenshot is being made:
  
  

• When users clone WordPress instances, 'Search Engine Indexing' option is now turned off by default on the resulting clones. Initially this was a request from one of the Managed WordPress hosters we're communicating with. Their reasoning was that a clone is much more likely to be a staging instance, not a production instance, and even if it was a production instance, turning search engine indexing on immediately might not be what users expect. This reasoning was all but confirmed by our internal usability testing, where users have voiced the same concerns, so we've changed the behavior accordingly:
  
  
  
  Note that server administrators can change this behavior on the 'Global Settings' tab, if they like the way it worked before:
  
  

• After users clone an instance, a proper screenshot of the clone is now immediately displayed. This addresses a problem that arose during our internal usability testing: users were cloning an instance only to see a screenshot of the current instance theme on the clone instead of the actual website screenshot (because the actual screenshot was still being made). This was a small but ugly nuisance that we've quickly addressed upon learning about it -- now users will immediately see the actual website screenshot on the cloned websites.

• When users synchronize data between WordPress instances using the 'Sync' feature, 'Files And Databases' option is now selected by default. The previous default was 'Files Only', and it caused a lot of unhealthy confusion for non-expert users during our internal usability testing. In particular, when users were changing a theme on one website and then using the 'Sync' feature with default settings to propagate these changes to another site, it was quite an unpleasant surprise for them to discover that the theme has not been changed (you need to also sync the database for that). To address this, we have changed the default sync configuration accordingly. Now non-expert users get what they expect without touching the scary sync settings, and advanced users can still fine-tune everything to their heart's desire:
  
  

This concludes the overview of the all major changes we're introducing in WPT 3.4. Full changelog will be posted below. Let us know if you have any questions or comments. Thank you for your attention!

 

[custer]

Full changelog:

3.4.0 (30 August 2018)

• [+] New CLI commands are now available! You can manage your plugin & theme sets, install them, and upload or remove custom plugins and themes -- all through command line. Run plesk ext wp-toolkit --help to learn more about sets, plugins, and themes commands.
• [+] Security-related screens were redesigned to make them more convenient and usable. In particular, users can now apply any selection of security measures to a number of instances.
• [+] It's now possible to roll back several applied security measures on multiple Plesk instances at once (not that we recommend to do it).
• [+] Users can detach or remove multiple WordPress instances from WordPress Toolkit.
• [+] Server administrators using Plesk versions earlier than Plesk Onyx 17.8 will see a gentle reminder that upgrading their Plesk to version 17.8 or later will give them access to a wonderful world of great new WordPress Toolkit features wrapped in a brand new UI.
• Users can now clearly see when a new website screenshot is being made. Spoilers: the screenshot part of an instance card is temporarily greyed out.
• When you clone WordPress instances, Search Engine Indexing is now turned off for the clones by default. Server Administrators can change this behavior on the Global Settings tab.
• Screenshots for cloned instances are immediately visible right after the cloning (no more playing hide-and-seek).
• When users synchronize data between WordPress instances, Files And Databases option is now selected by default, as opposed to Files Only option.
• Updates screen for a single WordPress instance now has a magical checkbox that selects or clears all items from WordPress Core, Plugins, and Themesgroups.
• [-] Users can now install WordPress instances in subfolders and on additional domains or subdomains even if wp-config.php file is present in the parent domain or folder. (EXTWPTOOLK-1765)
• [-] As a corollary of the bugfix mentioned above, users can now clone WordPress instances to additional domains or subdomains even if wp-config.php file is present on the parent domain. (EXTWPTOOLK-1766)
• [-] It's now possible to install WordPress into an already existing empty folder. (EXTWPTOOLK-1155)
• [-] Uninstall confirmation dialog in the old UI now has proper text instead of internal localization string. (EXTWPTOOLK-1720)
• [-] WordPress Toolkit no longer redirects users to the first page of the instance list after they have closed the security check screen of an instance located on a different page. (EXTWPTOOLK-1737)
• [-] Custom plugins no longer ignore the Activate after installation option, especially if it's not selected. (EXTWPTOOLK-1724)
• [-] WordPress instances with broken database connections can now be found by WordPress Toolkit. Hint: if you fix the database connection, you can manage them in the WordPress Toolkit. (EXTWPTOOLK-1754)
• [-] Smart Updates now work with IDN domains. (EXTWPTOOLK-1719)
• [-] Options on Update Settings page will not jump around anymore if you change them before checking for updates has been finished. Note: no options were harmed during the fixing of this bug. (EXTWPTOOLK-1681)
• [-] WordPress Toolkit displays proper error message if one of the instances found during the instance scan is broken. (EXTWPTOOLK-1768)
• [-] CLI command responsible for installing WordPress now adequately explains what's wrong with provided administrator username if there's anything wrong with it. (EXTWPTOOLK-1609)
• [-] WordPress Toolkit no longer executes files of WordPress instances on suspended and disabled domains as a part of its scheduled task. (EXTWPTOOLK-1678)
• [-] Custom themes are now properly activated if Activate after installation option is enabled. (EXTWPTOOLK-1717)
• [-] Tooltip is now available for the green icons which indicate that there are no updates on the Updates screen shown for multiple instances. (EXTWPTOOLK-1680)
• [-] wp-config.php is now removed properly when users remove WordPress instances initially installed as APS packages. (EXTWPTOOLK-1677)
• [-] Smart Update now displays proper error message if it cannot work due to SSL-related problems on the website. (EXTWPTOOLK-1594)
• [-] Security checker Permissions for files and directories now should display proper error message if it couldn't do what it had to do. (EXTWPTOOLK-1746)
• [-] Scan operation does not refuse to continue working anymore when it encounters a broken instance. (EXTWPTOOLK-1631)

 

[Tomek]

Hi @custer ,

can you fix a language bug, please

When Wordpress is automatically installed with the hosting plan, then the default Wordpress language is always English (not the same as the language of the Plesk customer interface).

 

[zanuda]

Hi @custer ,

can you fix a language bug, please

When Wordpress is automatically installed with the hosting plan, then the default Wordpress language is always English (not the same as the language of the Plesk customer interface).

Hello, Tomek, we were not able to reproduce such issue. We've tried in this way:
1. Create a Customer without a subscription;
2. Login as Customer, go to Edit profile and set any non-default language (e.g. German);
3. As an Admin create a subscription for Customer, using service plan with "Install WordPress" additional service;
4. Login to admin console of newly installed WordPress.
I see that language of WordPress is the same as Customer's (German).

Please let me know if your behaviour differs from ours.

 

[Tomek]

Hello, Tomek, we were not able to reproduce such issue. We've tried in this way:
1. Create a Customer without a subscription;
2. Login as Customer, go to Edit profile and set any non-default language (e.g. German);
3. As an Admin create a subscription for Customer, using service plan with "Install WordPress" additional service;
4. Login to admin console of newly installed WordPress.
I see that language of WordPress is the same as Customer's (German).

Please let me know if your behaviour differs from ours.

Hello @zanuda

ok, I will contact the pleska support directly with detailed information.

 

[custer]

Hi everyone! We have released WordPress Toolkit v3.5 with new installation experience, a huge amount of new security measures and a ton of bugfixes. The full list of changes is so huge that I had to split it into two posts. Features and improvements first:

• [+] A big bunch of new security measures was added to ramp up the security of WordPress instances. The measures are not applied automatically, so all users are shown a notification in UI that prompts them to check and apply the new measures. It's now possible to:
  • Enable hotlink protection
  • Disable unused scripting languages
  • Disable file editing in WordPress dashboard
  • Enable bot protection
  • Block access to sensitive and potentially sensitive files
  • Block access to .htaccess and .htpasswd
  • Block author scans
  • Disable PHP executing in various cache folders
• [+] WordPress installation experience was updated to unify the UI, so there are no "quick" and "custom" options anymore. WordPress Toolkit now always displays the installation form with all data prefilled, which allows users to make an informed choice: confirm the defaults to install WordPress quickly, or take your time and change the options you want.
• [+] All users can now choose domains from any accessible subscription when installing WordPress. In practical terms this means that you can now install WordPress anytime you click WordPress in the left navigation panel, even if you're a reseller or server administrator.
• [+] WordPress Toolkit CLI for installing WordPress instances was updated to include management of automatic update settings. Specifically, the following options were added: -auto-updates, -plugins-auto-updates, and -themes-auto-updates.
• [+] For those who don't want to use Gutenberg yet after WordPress 5.0 is released, we have added a WordPress Classic set that includes Classic Editor plugin.
• [+] WordPress Toolkit cache can now be cleared with a special CLI command: plesk ext wp-toolkit --clear-wpt-cache. This might be useful for handling issues with invalid WordPress Toolkit cache data like corrupted WordPress distributive or broken lists of languages and versions.
• The yellow Warning security status was changed to greenish OK to avoid scaring innocent users, since it's actually OK to not have every single security measure applied.
• Security measures Security of wp-content and Security of wp-includes were unnecessarily restrictive, so they were forced to relax their grip somewhat

 

[custer]

Now the bugfixes:

• [-] WordPress Toolkit no longer hangs during the execution of routine daily maintenance tasks when it encounters WordPress instances infected by malware or otherwise operationally challenged. (EXTWPTOOLK-1524)

• [-] Error and warning messages do not display IDN domain names in punycode anymore. (EXTWPTOOLK-1769)

• [-] Resellers and Customers without security management and auto-updates management permissions can no longer manage security and automatic updates. (EXTWPTOOLK-2047)

• [-] WordPress instances no longer become invisible after their installation or cloning process has failed at the very end for some weird reason. (EXTWPTOOLK-1844)

• [-] When users were deleting WordPress instances, WordPress Toolkit was displaying an ambiguous confirmation message, insinuating that WordPress instances will be simply removed from the Toolkit (not deleted). The ambiguity of the message was reduced by several degrees of ambiguousness, so users should now have a very clear idea of what will actually happen. (EXTWPTOOLK-2075)

• [-] Invalid URL was requested error is no longer displayed when plugins or themes are activated in the dialog opened directly from the subscription screen. (EXTWPTOOLK-2096)

• [-] WordPress Toolkit no longer refreshes the update cache for detached instances. (EXTWPTOOLK-2049)

• [-] If users are trying to set up Admin credentials for a WordPress instance that does not have any Admin users, WordPress Toolkit does not spectacularly fall on its face anymore, displaying proper error message instead. (EXTWPTOOLK-1826)

• [-] The installation process of WordPress instances is not confused about its own success status anymore if it encounters a file owned by root in the installation directory. (EXTWPTOOLK-2091)

• [-] When WordPress Toolkit encounters a file owned by root during the security status check, it will no longer scare users with a message about the inability to apply a security measure. When the Toolkit finds such a file during the application of security measures, it displays a proper error message now. (EXTWPTOOLK-1875)

• [-] Interface translations no longer display HTML entities in places where they're not supposed to be. (EXTWPTOOLK-2073)

• [-] Removal of multiple instances does not fail anymore if one of the removed instances is broken. (EXTWPTOOLK-1771)

• [-] WordPress Toolkit now properly falls back to the Install WordPress service plan option if the Install WordPress with a set service plan option was previously selected and this set was removed from the server. (EXTWPTOOLK-1931)

• [-] Smart Update does not enthusiastically notify users about successful updates via notification email anymore if Smart Update was in fact not performed correctly. (EXTWPTOOLK-1760)

• [-] Security status checks became too complacent and stopped working on a routine daily basis. This disgusting behavior was addressed, and users will now be duly notified whenever there's a problem with previously applied security measures. (EXTWPTOOLK-1794)

• [-] Update settings are no longer changed for all WordPress instances selected in the instance list when some of these instances are subsequently filtered out on the Updates screen. (EXTWPTOOLK-2101)

• [-] Smart Update notification emails are now security conscious, providing HTTPS links to Plesk instead of HTTP. (EXTWPTOOLK-1758)

• [-] Cloning procedure now displays proper error message when somebody without the Subdomain management permission tries to clone their stuff. (EXTWPTOOLK-1866)

• [-] Failed automatic updates are now properly included in the notification digest. (EXTWPTOOLK-1761)

• [-] WordPress Toolkit has improved its defense against WordPress instances with malformed UTF-8 strings in their settings. Such instances will no longer cause WordPress Toolkit to display a blank screen instead of instance list. (EXTWPTOOLK-1935)

• [-] Users of Russian translation can now see when was the last time WordPress Toolkit checked an instance for updates. (EXTWPTOOLK-1821)

• [-] Speaking of text messages related to updates, a proper error message is now displayed whenever there's a problem with a missing update task. (EXTWPTOOLK-1929)

• [-] WordPress instances that store authentication unique keys and salts in a separate file are no longer considered broken by WordPress Toolkit. (EXTWPTOOLK-2111)

• [-] Set Contents pop-up on the WordPress installation screen is now censored out when users open it for a selected set and then switch the set to None. (EXTWPTOOLK-1984)

• [-] Maintenance mode no longer displays the countdown on a preview screen if the countdown isn't turned on. Internal debates still rage over whether the Toolkit should play The Final Countdown when it's on, but that's a different story. (EXTWPTOOLK-1845)

• [-] Users will now see a proper error message when they are trying to install WordPress in the same directory where important files like web.config were left behind by another WordPress installation. (EXTWPTOOLK-2082)

• [-] WordPress Toolkit now helpfully selects critical security measures not yet applied on the instance when the security scan is ran the first time. (EXTWPTOOLK-2002)

• [-] Text visibility on the Maintenance mode screen was improved to reduce the eye strain of the website visitors around the world. (EXTWPTOOLK-2086)

• [-] Certain placeholder messages were properly localized in the old UI. (EXTWPTOOLK-2021)

• [-] WordPress Toolkit no longer updates the options database table of detached WordPress instances when their domain name is changed in Plesk. (EXTWPTOOLK-2074)

• [-] Maintenance mode can now be properly configured if it was never enabled before. (EXTWPTOOLK-2087)

• [-] German translation was updated so that all messages display proper data instead of placeholders. (EXTWPTOOLK-1579)

• [-] Administrator's username security measure is not displayed anymore for existing multisite instances, where it doesn't work anyway due to circumstances beyond our control. (EXTWPTOOLK-2106)

• [-] Trying to remove plugins or themes in WordPress Toolkit when they were already removed via other means will now display a proper error message instead of a placeholder. (EXTWPTOOLK-1855)

• [-] Set names are finally restricted to 255 characters, so no more War And Peace on your Sets screen, sorry. (EXTWPTOOLK-1697)

• [-] Maintenance mode screen now properly displays default texts instead of undefined. (EXTWPTOOLK-2113)

• [-] Security Status screen can no longer be summoned by users without the corresponding security management permission for a particular instance. Such instances will also no longer be visible on the Security Status screen for multiple instances. (EXTWPTOOLK-1560)

• [-] WordPress Toolkit will display a proper message when one user is trying to secure an instance while another user has already deleted it. (EXTWPTOOLK-1515)

• [-] Redundant requests to wordpress.org on the Plugins and Themes management screens were optimized away. (EXTWPTOOLK-1876)

• [-] The Select All Updates checkbox on the Update screen is no longer accessible when users review the intermediate results of the Smart Update procedure. (EXTWPTOOLK-1801)

• [-] The dollar sign displayed on the Sets tab when you don't have the full version of WordPress Toolkit is no longer clickable. (EXTWPTOOLK-1822)

• [-] WordPress Toolkit now displays somewhat different result messages when users remove or detach several WordPress instances as opposed to a single one. (EXTWPTOOLK-1755)

• [-] Extremely long WordPress site titles no longer venture outside of the WordPress Toolkit UI. (EXTWPTOOLK-1958)

 

[custer]

Hope you enjoy the release -- let us know if you have any comments or questions!

 

[trialotto]

@custer,

With so many posts, it is hard to tell which of them I should like..............since I like them all. Excellent work!

By the way, a big question: as the WP Toolkit CLI is (essentially) a clone of the wp-cli utility, does the WP Toolkit CLI also support "running commands remotely"?

If yes, can you give an example of the command stanza?

If no, are there plans to support this in the near future?

Regards.......

PS For the sake of reference, see this article on "running commands remotely".

 

[Eleshar]

@custer

Not great experience with WordPress Toolkit v3.5 so far.

After installing latest update proceeded to do a scan which took forever in comparison to the previous release.

Previously working instances were now listed as broken, proceeded to detach them which results in a few websites being completely wiped.

Gave up on the extension after that and uninstalled from all our servers.

 

[custer]

@custer

Not great experience with WordPress Toolkit v3.5 so far.

After installing latest update proceeded to do a scan which took forever in comparison to the previous release.

Previously working instances were now listed as broken, proceeded to detach them which results in a few websites being completely wiped.

Gave up on the extension after that and uninstalled from all our servers.

Hi @Eleshar,

I'm really sorry to hear about this! Such behavior was definitely not intentional. Can you tell me more details about your affected servers -- in particular, are you running Windows? Can you elaborate on what "completely wiped" means? Any other details would be very appreciated -- if this is a systemic problem, we'd like to release a fix immediately.

 

[custer]

@Eleshar

FYI, if you have stumbled upon the mentioned issue on Windows Server with IIS and shared application pools, I think we have identified and fixed it. WPT 3.5.1 with the corresponding fix was published several hours ago. If you are using a different configuration, though, please let us know the details so we can continue our investigation.

PS. I know you've said that you've already given up on WordPress Toolkit, and it makes me feel real bad -- we want our product to help people, not harm their business. If you're willing to give the Toolkit a second chance, drop me a PM. Thank you!