• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

WP Toolkit - General Discussion

I was excited to hear about the Smart Updates, but the price makes it impossible to use. For 200-300 sites on a server, the Smart Update add-on would cost us $118.80 per month! For a single feature (albeit a great one) we'd be paying 5 times the price of Plesk itself, and about the same we pay for a VPS.

Also, how can we hide the feature if we're not using it? It looks like it displays the upsell option to our end user customers, with a link to buy the Smart Updates feature directly from Plesk, and we don't want that. We want any customer purchases to be through us. We'd like to remove this upsell option and also the Smart Update settings that appear on the updates configuration page (but are disabled if Smart Updates are not active).

IMHO these kinds of things make Plesk look spammy, especially when paired with Addendio, which we would like to see go away quickly. It's not about improving the user experience, it's about selling for Envato and others.

Sorry for venting, but the WordPress features in Plesk are why we're moving over from cPanel. But these kinds of things are making us revisit our options.
 
Last edited:
Where can you set major & minor updates for all instances in one bulk operation in the new wordpress toolkit? I can't seem to find it.
 
I have a question about automatic updates. Does the Wordpress Toolkit check the health of the installation after the update?

If you have opted to create a restore point when updating WordPress Core, WPT does some basic health checks (like checking the browser return code).
 
Hi Mark,

Also, how can we hide the feature if we're not using it? It looks like it displays the upsell option to our end user customers, with a link to buy the Smart Updates feature directly from Plesk, and we don't want that. We want any customer purchases to be through us. We'd like to remove this upsell option and also the Smart Update settings that appear on the updates configuration page (but are disabled if Smart Updates are not active).

This is a good point -- you should be able to hide these upsell prompts. I've added a task for our team to develop this in one of the next WPT updates.

IMHO these kinds of things make Plesk look spammy, especially when paired with Addendio, which we would like to see go away quickly. It's not about improving the user experience, it's about selling for Envato and others.

BTW, Addendio is going away next week in WPT 3.2 (well, if we don't hit any unexpected surprises during the testing phase, then the release will be shifted one week).

Sorry for venting, but the WordPress features in Plesk are why we're moving over from cPanel. But these kinds of things are making us revisit our options.

Thank you for your trust in us, Mark. We're making this product for you guys, so we're always eager to hear what you think of it. Please don't hesitate to let me know if you have more concerns or suggestions.
 
Where can you set major & minor updates for all instances in one bulk operation in the new wordpress toolkit? I can't seem to find it.

That's not available yet, but we're working on it. This functionality will be released in WPT 3.3 in June.
 
If you have opted to create a restore point when updating WordPress Core, WPT does some basic health checks (like checking the browser return code).

Hi custer,

so, after the automatic update of the plugins and themes, health is not checked? I ask to be sure :)
 
Last edited:
Hi,
I'm a big fan of plesk, but wordpress management is still a pain while maintaining plugins and themes.
I was thrilled by this new SmartUpdate feature, so I gave it a try.

--> It's a nightmare on my end.

Updating a single wordpress plugin took 17 min, then failed with a "cannot write log" error.
I tried a couple of times. At the end , *server crashed* because of no space error : My website has been duplicated 5 times , with names
.wp-toolkit_E,
.wp-toolkit_k
.wp-toolkit_p
..
took all space left on my disk and crashed all my customer websites !
+ these instances appear in wordpress toolkit instance lists.

Wced7xwia7IriME8E7x0O5kRsQLYMp.png



so ...
- Is it really suppose to take dozens of minutes for a single plugin update ???
- You didn't think of cleaning up the created instance in case of failure ???
- You do not reuse the smartupdate sandbox instance, you create a new one on each test ???
- You don't even check disk space before duplicating GB of websites on disk ???

Canceling smartupdate subscription, not production-ready at all and really really dangerous.

- Arnaud
 
Last edited:
I wanted to follow up on my earlier rant...I've realized that the Plesk team is indeed committed to keeping Plesk great, for example their willingness to introduce a non-Addendio solution. And I do understand now that the Smart Updates feature took a lot of time and resources to develop, so that's why there is an additional charge for that. I was just worried because I saw a few things happen at once, and I mistakenly thought they meant that Plesk was headed in a bad direction.

My faith is restored. :)
 
Hi @Arnaud Lapiere,

First, I'm sorry to hear that your experience with Smart Updates was far from satisfactory. I too would've been royally pissed if I had to go through something like that. Anyway, let's go through your questions:

- Is it really suppose to take dozens of minutes for a single plugin update ???

It's not the update that takes so much time, it's cloning of the whole instance for the test update run. If you have a huge instance, it will take a large amount of time to clone. I'd love for WPT to display a proper progress indicator for the Smart Update procedure, but it is unfortunately a quite non-trivial task.

The alternative to performing the test update on a clone would be to perform the analysis and the update on a production instance. However, in this case if the update isn't considered successful, you're left with a "hey, your site looks broken after the update, go fix it" situation, which isn't very reassuring. We could try to roll back the update automatically if the system decides that the update didn't go well (or at least make such auto-rollback an option), but what if the rollback fails too? The main requirement for Smart Updates was that it should be a "fire and forget" thing, and if you have to scramble and fix your site after an unsuccessful automatic update, that wouldn't be "fire and forget" -- that would be more like "forgot and got fired" kind of thing, and we definitely don't want that.

- You didn't think of cleaning up the created instance in case of failure ???

We indeed didn't think about it initially, because we've never had a cloning procedure fail during Smart Updates testing. Well, until recently -- now it's a known bug that is fixed in the WordPress Toolkit 3.2 update that will be released later this week.

- You do not reuse the smartupdate sandbox instance, you create a new one on each test ???

Since the cloned instance is removed after a successful update (or when you reject the update), this should not have been a problem. However, you raise a very good point -- it might be more efficient to always keep a clone for testing updates, because syncing the changes between two instances is generally faster than cloning the whole instance. We'll discuss this internally tomorrow.

- You don't even check disk space before duplicating GB of websites on disk ???

Let me check this with the guy who've coded this part -- will get back to you tomorrow.


PS. I've got a request for you, Arnaud, and for other people who've tried Smart Updates or are thinking about it: if any of the improvement ideas mentioned above make sense to you, please let me know. If you have other ideas or expectations about how Smart Updates should work, I'd love to hear them as well. I don't like how much time it takes for a Smart Update to happen myself, but I'm not sure if there are any safer alternatives acceptable for the users. Would love to hear your thoughts, guys!
 
Hi everyone,

We have released WordPress Toolkit 3.2 earlier today. It is strongly recommended to update to this version since it replaces Addendio with a GDPR-compliant interface for installing plugins and themes. It also includes a bunch of other stuff, including customer bugfixes. Full changelog:
  • [+] New GDPR-compliant interface for installing plugins and themes is now available, completely replacing the old Addendio service. It doesn't have filters yet, but (spoiler alert!) we're working on that.
  • [+] Users can now check security and apply critical security fixes for multiple WordPress instances at once. The ability to apply non-critical security fixes en masse was late to the party, so it will have to wait for later WordPress Toolkit releases.
  • A couple of new default sets with Jetpack plugin were added.
  • Setup shortcut was added for those who want to quickly fine-tune their nginx caching settings.
  • Smart Update service accuracy was improved. Also, confirmation prompts were added because everybody loves them.
  • [-] Toggling stuff like Debug or Maintenance Mode on an instance now immediately updates instance list filters. (EXTWPTOOLK-1389)
  • [-] Instance filters went through an extensive bootcamp and became much more useful. You can always see the Filter button now with selected filter and filtered instance count, and you have a "Clear filter" button on the bottom of the instance list as well. (EXTWPTOOLK-1390)
  • [-] Smart Update action buttons on the Updates screen are now always visible after being taught how to float. (EXTWPTOOLK-1496)
  • [-] The "link" button now opens the website in a different tab or window, not in the current one. (EXTWPTOOLK-1445)
  • [-] Instance screenshots are now removed if the instance itself is removed (sorry for littering). (EXTWPTOOLK-1413)
  • [-] Quick Start menu on the Websites & Domains screen is not hideously deformed on wildcard subdomains anymore. (EXTWPTOOLK-1159)
  • [-] If instance cloning has failed during Smart Update, the failed clone is now removed to avoid clone wars (and, uh, copyright infringements). (EXTWPTOOLK-1360)
  • [-] Caching management is no longer visible for customers who don't have the permission to manage their hosting settings. (EXTWPTOOLK-1504)
  • [-] Users can now turn off countdown timer without having to disable Maintenance mode first. (EXTWPTOOLK-1507)
  • [-] In a surprising turn of events, nginx caching management is no longer visible if nginx is not installed on the server. (EXTWPTOOLK-1482)
  • [-] Several layout issues were eliminated from the Maintenance mode settings screen. (EXTWPTOOLK-1300)
  • [-] It's not possible anymore to confuse Smart Updates by unchecking update items in the middle of Smart Update procedure. (EXTWPTOOLK-1460)
 
Hey everyone,

since the May 25th Upgrade for the Wordpress Toolkit, i keep getting the following exception when trying to install a theme in an instance:

Server Error
500
Zend_Controller_Action_Exception
Action "null" does not exist and was not trapped in __call()

Type Zend_Controller_Action_Exception
Message Action "null" does not exist and was not trapped in __call()
File Action.php
Line 485


I suppose the file in question is /opt/psa/admin/plib/modules/wp-toolkit/library/Controller/Action.php, but since the file is encrypted with ioncube, i can't make sure of that.
Any known workaround for this?
 
I suppose the file in question is /opt/psa/admin/plib/modules/wp-toolkit/library/Controller/Action.php, but since the file is encrypted with ioncube, i can't make sure of that.
Any known workaround for this?

Could you please check content of /var/log/plesk/panel.log file? Exception stacktrace should be placed here, this could help us to find the root cause.
 
No problem, excerpt from the log:


[2018-05-25 12:18:19.421] ERR [panel] Action "null" does not exist and was not trapped in __call():
0: /opt/psa/admin/plib/vendor/plesk/zendframework/library/Zend/Controller/Action.php:485
Zend_Controller_Action->__call(string 'nullAction', array)
1: /opt/psa/admin/plib/vendor/plesk/zendframework/library/Zend/Controller/Action.php:518
Zend_Controller_Action->dispatch(string 'nullAction')
2: /opt/psa/admin/plib/vendor/plesk/zendframework/library/Zend/Controller/Dispatcher/Standard.php:308
Zend_Controller_Dispatcher_Standard->dispatch(object of type Zend_Controller_Request_Http, object of type Zend_Controller_Response_Http)
3: /opt/psa/admin/plib/vendor/plesk/zendframework/library/Zend/Controller/Front.php:954
Zend_Controller_Front->dispatch()
4: /opt/psa/admin/plib/pm/Application.php:99
pm_Application->run()
5: /opt/psa/admin/htdocs/modules/wp-toolkit/index.php:4
 
There seems to be a problem with the WP Toolkit's Maintenance Mode.

Within 24h it disables itself again and the page is available publically again. --> This is far from good and should not happen.
How can we solve this?

Thanks!
 
There seems to be a problem with the WP Toolkit's Maintenance Mode.

Within 24h it disables itself again and the page is available publically again. --> This is far from good and should not happen.
How can we solve this?

Thanks!
Thank you for feedback, we will check this case carefully.
 
There seems to be a problem with the WP Toolkit's Maintenance Mode.

Within 24h it disables itself again and the page is available publically again. --> This is far from good and should not happen.
How can we solve this?

Thanks!

I can confirm this. This is caused by Wordpress core, pluguins and themes updates. Maintenance Mode is turned off before the update starts.
 
Last edited:
Ubuntu 16.04.4 LTS‬
Product Plesk Onyx Version 17.5.3 Update #50
WordPress Toolkit version 3.2.1-936

this time instances just got lost / disappeare / not more visible in wordpress extension :( the wordpress intstallation is 4.9.6 with php 7.2.6 fpm apache
scan for instances does not bring up the missing wordpress installation, and the the wp-config.php wasnt touched in the last month...

the panel.log did not tell mutch details about it
[2018-06-10 14:58:13] ERR [extension/wp-toolkit] Unable to get info about instance: Failed to parse metadata
[2018-06-10 14:58:14] ERR [extension/wp-toolkit] Unable to get info about instance: Failed to parse metadata
 
Last edited:
Back
Top