Completely Uninstall Wordpress Toolkit including users

[mtbwacko]

Today's cPanel update included the Wordpress Toolkit. After looking at it we decided we don't want it because it forces our users to pay for premium features to get all the benefits. So I disabled it in Features for our users. But now I see that every single account has the below 'WP_AUTO_UPDATE_CORE' line at the top of their wp-config.php files, placed there by Wordpress Toolkit. First, I resent the fact that a program would alter all of our user's files without any warning. So now I need to safely remove this line from hundreds of Wordpress installations. Is there a way to do this? I am aware of the following command, but I assume this will only remove the toolkit RPM, correct?

>rpm -e wp-toolkit-cpanel

So how do I safely remove the following line from hundreds of users' wp-config.php file? This just irks me to no end that I have to do this.

define('WP_AUTO_UPDATE_CORE', 'minor');// This setting is required to make sure that WordPress updates can be properly managed in WordPress Toolkit. Remove this line if this WordPress website is not managed by WordPress Toolkit anymore.

 

[cPRex]

Hey there!

I've been doing some testing with this today and it seems that the first time you access the WordPress Toolkit option in WHM it automatically performs a scan in the background, adding that line to the wp-config.php files.

It's important to note that the WPTK software doesn't get automatically installed as part of the cPanel update. You have to activate this after the update in your next WHM login session through the Feature Manager, or manually install it at a later time. This is outlined in our documentation here:

WP Toolkit | cPanel & WHM Documentation

This document explains how to install, manage, and upgrade the WP Toolkit.

docs.cpanel.net

If you haven't removed the software yet, it might be best to detach the Wordpress installs through the interface. If you have already removed the RPM, you could create a script to remove those lines from the wp-config.php files on the machine.

 

[mtbwacko]

Yeah, but the problem is I can't check the Select All box to detach all of the installations at once because the "Select All / Mass Manage" feature is only available in the Premium version, so I would have to purchase the premium version, then Select All to unattach all of my client's web sites, just to uninstall the app! Surely you realize how ridiculous this is. So I am forced to detach hundreds of web sites one at at time just to uninstall the app?

 

[cPRex]

You wouldn't have to do that manually through the app if it detected many hundreds of Wordpress installations. You could create a script to manually remove the one line from the wp-config.php for all accounts at once, which will effectively do the same thing.

 

[mtbwacko]

Yes, I understand I could write a script, but that makes me very nervous if something goes wrong with it and it nukes hundreds of wp-config.php files. I guess I'll figure something else, but let this be a warning to any one who reads this and wants to remove the Wordpress Toolkit after it's been installed. What a pain!

 

[cPRex]

I did confirm with the Wordpress Toolkit engineers that any of the "batch update" type functions require the Deluxe version of Wordpress Toolkit. They are going to adjust the interface so that is more obvious in future releases, so there will be a warning in addition to the buttons being non-clickable.

 

[timmmmyboy]

Is there an additional command that can be run to not show the toolkit installation request on next login after running rpm -e wp-toolkit-cpanel? We'd like to make sure the servers we manage don't accidentally get it enabled again after we've uninstalled it.

 

[cPRex]

Are you referring to the Feature Showcase being displayed in WHM? If so, you can enable/disable the Feature Showcase with the presence of this touch file on the system:

touch /var/cpanel/activate/features/disable_feature_showcase

UPDATE: You can remove Wordpress Toolkit from the Feature Showcase with this command:

touch /var/cpanel/activate/features/wordpress_toolkit_install

It's important to note that WPT does not auto-install on any system. It either needs to happen through the Feature Showcase link, or manually on the command line.

 

[timmmmyboy]

Great, thank you! Our main issue is that while yes it is not installed by default, it's pretty easy for someone to think they are *supposed* to click on through and with it being enabled by default and highlighted we anticipate some of our staff may inadvertently enable it. The touch command will help prevent that.

 

[kernow]

It's important to note that WPT does not auto-install on any system. It either needs to happen through the Feature Showcase link, or manually on the command line.

Not so! On our servers running CL 7* we had the choice when logging in to WHM to disable it from the showcase, but on a server running CL6 it auto installed, it wasn't even listed on the WHM 'Feature showcase' login page
And just like @mtbwacko we also resent the fact that a program would alter all of our user's files without any warning.

 

[wintech2003]

we also resent the fact that a program would alter all of our user's files without any warning.

Yeah, that shouldn't be happening at all - let alone without a warning. The fact that a server admin installed WPT to check it out, doesn't mean their customer data should be altered just because they launched the app.

 

[custer]

Hi everyone,


I'm the person responsible for WordPress Toolkit on R&D side. Sorry to hear about your troubles with WPT -- let me explain what's going on with the 'WP_AUTO_UPDATE_CORE' constant added to wp-config.php file. I'm going to assume that not everyone here is a WordPress expert, so I hope you'll forgive me if I state something you already know. TLDR version is also available at the bottom, if you're short on time.


What is 'WP_AUTO_UPDATE_CORE' constant?

The 'WP_AUTO_UPDATE_CORE' constant in wp-config.php file is a standard WordPress constant (see https://wordpress.org/support/article/editing-wp-config-php/#disable-wordpress-core-updates, for example). Usually you would add this constant to your wp-config.php file in one of two cases:

1. You need to completely disable automatic WordPress updates altogether.
2. You want to automatically install all, even major (e.g., 5.2 > 5.3) WordPress updates.

You might notice that a third case is missing: automatically install only minor/security (e.g., 5.2.1 > 5.2.2) updates. You can use 'WP_AUTO_UPDATE_CORE' constant to address this case as well, but you don't have to -- this case is the default WordPress behavior. In other words, WordPress defaults to this behavior if 'WP_AUTO_UPDATE_CORE' constant is missing from wp-config.php.

As you see, by adding this constant with its default setting to wp-config.php file, WordPress Toolkit does not actually change any site data or user settings -- it merely exposes the existing default WordPress autoupdate setting.


Why WordPress Toolkit adds this constant to wp-config.php?

WordPress Toolkit uses this constant to determine if a WordPress site needs to be updated whenever the update is available. The constant is added if it's missing to make autoupdates management standardized and transparent to users. It is also needed to make sure the autoupdate experience in WPT works properly at all times. Adding this constant also means the following can happen:

1. Users can manually change the constant, and these changes will be accepted by WordPress Toolkit.
2. If users have already added this constant by themselves before the site was connected to WPT, it will be accepted by WPT.

Why can't WordPress Toolkit remove this constant when you uninstall it?

Removing the constant from wp-config.php would be problematic due to the following reasons:

1. Users might have added the constant by themselves before the site was connected to WordPress Toolkit, so deleting it will remove actual user data/settings.
2. Users might have changed WordPress autoupdate behavior either via WordPress Toolkit or via direct modification of this constant, so, again, deleting it will remove actual user data/settings.

In other words, WPT leaves this constant to make sure that WordPress site is autoupdated the way its owner wants even after WordPress Toolkit is uninstalled.

PS. The WPT-related comment added to this constant hasn't been relevant for quite some time, so we will remove it in the next WordPress Toolkit release. Hopefully this should alleviate the potential customer confusion.


TLDR version: There is no need to remove the 'WP_AUTO_UPDATE_CORE' constant from wp-config.php, since it will either make zero practical difference or will make things worse, if your users added it by themselves. You can remove the comment next to the constant as it is not relevant and might confuse customers.


Hope this helps -- let me know if you have any questions.

 

[cPRex]

Thanks to @custer for that helpful post.

I'd also like to point out that after some additional research, WPT *will* auto-install if you update cPanel and Wordpress Manager is detected, which is something we weren't aware of at the time I posted last week.

The best way to keep the software from being installed at all would be to add the RPM to the yum exclude line on the server.

Due to the reasons mentions by @custer we are currently not exploring a more automated method to remove that line from the wp-config.php file.

 

[ffeingol]

@custer First, I understand that WP_AUTO_UPDATE_CORE is a standard WordPress constant and that you are just setting it to the default value. This is still very problematic. We (like I assume most web hosts) tell our clients that we will never modify anything in their web site unless they open a support request and request a change. This (even if it's in a minor way) breaks that trust.

We hosting is 100% a commodity now (with a race to zero) so one of the important things that differentiates us from everyone else is our service and support. If we start to break that trust (even in tiny ways), it hurts our reputation.

The good news is that all our servers are on LTS, so we don't even have to think about this until next April (hopefully) so al the issues about how to keep this from installing will be long solved.

 

[kernow]

@custer thank you for your reply.
Full update, minor update, plugin update etc are all available options of course from within 'Softaculous' which thousands of us already have installed.
And please in future, do not alter or edit our clients files without our express permission! It doesn't look good when we have to explain to our clients that although we host their websites, some third party software called "cPanel" has edited them without asking us !!!

 

[Josh Cobb]

In the WP Toolkit documentation, it says:
Note: Changes you make directly in WordPress are synchronized with WordPress Toolkit once every 24 hours.

Is there a cron doing the work here? If so, where has it been created?

 

[cPRex]

@Josh Cobb - can you let me know where you're seeing that in the documentation? I'm not seeing that at WordPress Toolkit | cPanel & WHM Documentation when I checked just now.

 

[custer]

@ffeingol @kernow You make a very good point about trust as a cornerstone principle, can't argue with that. I've talked to WordPress Toolkit dev team about this particular issue. We are planning to change the way WPT behaves in the next WPT update -- specifically, unless the user explicitly changes the WP core autoupdate setting via WPT, this constant should not be added.

As for the existing WP_AUTO_UPDATE_CORE constants already added to wp-config.php files by WPT, the plan is to remove them during the update to the next WPT version. If this constant has a particular comment left by WPT, we'll know it wasn't the user who added it, so we'll remove it. I know you've already uninstalled WPT from your servers, but the product cannot perform any actions if it's not installed. If installing WPT again is unacceptable to you for some reason, let us know -- we'll see if we can create a one-off script outside of WPT that will do the job.

Sorry for the inconvenience, and I hope that sometime later down the road you might give WordPress Toolkit another chance.

 

[bradlee]

Since the editing of the wp-config.php files.. I tested some manual Wordpress upgrades and they have now switched to the dev/nightly versions. This is a huge issue. There has to be some way for cPanel to support the reversal of this almost malicious (not intended) action.

 

[ozfiddler]

So I have just discovered that I also have had this line added to my config files. I never signed up for WP Toolkit and I don't want WP Toolkit. But, more of a worry, I am not even using WordPress on most of my sites. I use ClassicPress.

Are you aware of this WP fork? If you look at Softaculous or Installatron you will see that it is available as a separate installation. Why is WP Toolkit messing around with my ClassicPress files?