Completely Uninstall Wordpress Toolkit including users
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.
-
Just found about the changes made to wp-config with this new plugin. There is no way to uninstall WordPress Toolkit and undo the changes made at the wp-config.php? Couldn't find anything at your documentation. 0 -
@Duplika - as of this time, that is correct. Removing the RPM will remove the software from the server, but it will not remove the edits to the wp-config.php file. The above post from @custer provides an explanation as to why that decision was made. 0 -
@Duplika - as of this time, that is correct. Removing the RPM will remove the software from the server, but it will not remove the edits to the wp-config.php file. The above post from @custer provides an explanation as to why that decision was made.
So to remove it, at least not everything, we should run the following command and nothing else?rpm -e wp-toolkit-cpanel0 -
Correct 0 -
Yup - that's correct! 0 -
Might just be us thinking this, but WP Toolkit have blown their chances of us ever using their software. Trust and partnerships are the cornerstone of business and they always will be - something WP Toolkit's team need to step into the real world and learn. It's simply unacceptable and arrogant to think you can force your software onto businesses who have run successfully and profitably without it.
It's definitely not just you. Oakley have certainly changed the ethos of cPanel.0 -
I just received the 92.0.6 WHM/cPanel update and WOW .... I now have WORDPRESS ....... how do I get this crap off my VPS server? All it does is open up security vulnerabilities across ALL my user accounts and my main VPS server as well ... Who decided to FORCE this crap on WHM/cPanel server owners??? .... they should be FIRED !!! 0 -
@Forrest Ward - your server did not get any Wordpress installations as part of the update. If your server had Wordpress Manager, which has been a cPanel tool for some time, or if you clicked the option to install Wordpress Toolkit during the Feature Showcase, your machine would get Wordpress Toolkit installed. It just gives you the option to install and manage all Wordpress installations more easily. As mentioned earlier in this thread, you can remove the RPM if you don't want the tool on the machine at all. 0 -
Here's an update applied in version 5.2.4 of WPT that I'm sure many of you will appreciate: WordPress Toolkit no longer adds WP_AUTO_UPDATE_CORE constant to wp-config.php file right after scanning process adds a WordPress installation. This constant will be added only after site admin has explicitly modified WordPress autoupdate settings. 0 -
I agree with the general sentement above from WHM users, i.e. new features shoudn't add or modify code on users' accounts without the explicit consent & agreement from server owners etc. I too have used the rpm -e wp-toolkit-cpanel command to remove the feature, after initally accepting it, in oder to understand it's functionalty better, and then regretted this. Furthermore and FYI, I have noticed many additional log lines (1000's of additional lines) in our daily "/var/log/secure" log file, referencing this line... sudo: wp-toolkit : TTY=unknown ; PWD=/usr/local/cpanel/3rdparty/wp-toolkit/scripts ... which indicates increased activity as this feature "does-it's-thing" so to speak, and there is no explination of this yet. I'm a bit suspicious of course, but hoping this will now stop after its de-registration. Just FYI. :) 0 -
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.
Hi @bradlee, This can happen only if both of the following conditions are true: 1. Your WP site is already running a dev/nightly version. 2. Major WP core updates were enabled for your WP site either manually or via WPT. Please double check if the sites you've used for testing were already running a dev/nightly build, since WPT cannot install dev/nightly builds or update a public release build to a dev/nightly build without site admin enabling dev/nightly builds first.0 -
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.
I am glad that this was picked up, as it was made to believe i did something wrong in0 -
"WordPress Toolkit" has broken auto-update for the 350 WordPress blogs on our server by modifying wp-config.php without my knowledge. cPanel: please avoid pushing this kind of thing onto my systems in the future. @custer: my platform manages auto-updates by setting constants from our own plugin, so if you scan wp-config.php and don't find WP_AUTO_UPDATE_CORE, don't think that you can insert your own random settings without affecting anything. Your inserts clobbered our logic. It took me a while to figure out what was going on. Our plugin uses this: add_filter( 'auto_update_core', '__return_true' ); add_filter( 'allow_dev_auto_core_updates', '__return_true' ); add_filter( 'allow_minor_auto_core_updates', '__return_true' ); add_filter( 'allow_major_auto_core_updates', '__return_true' ); add_filter( 'auto_core_update_send_email', '__return_false' ); 0 -
@custer I'd like to add a little something to this discussion, both pro and con... First, I'm upgrading to a new cloud hosting account. It was nice to find the Toolkit there. Normally, I'd either have to add WP manually, or do it through Softaculous, so the toolkit was a nice surprise since I won't have Softaculous anymore. We are all here to make money. Obviously the toolkit wants to monetize itself, but let's be realistic here.... Almost All of the options the toolkit wants us to pay for are free with a number of different security plugins, so why would anyone want to pay for that! lol This is the one I use, I have it on all of my sites: All In One WordPress Security and Firewall Plugin The free version has, I believe, all of your Premium options included. Wordfence is probably the most popular one, but it's a little overblown for my tastes. Premium features should be PREMIUM features. Things you can't get somewhere else or provide a much needed service. Being able to add my own plugin and theme library is Really nice, but do i want to pay a monthly fee for that? Yeah no. Cause really, that's the only thing I can see so far that I can't easily get somewhere else AND makes my life easier. Add some Real value to it, reduce the price, or maybe make it a one time fee to upgrade (the one time fee is a much prefered option to me)? Nickel and diming my monthly nut is never my first choice for an upgrade. :) With all due respect, -Joe 0 -
Also, having the default to Yes, when the showcase features appears after login, is not a good choice. Specially since you modify a lot of files; most users will not notice this... 0 -
There is nothing automatic about that tool. It requires you edit the command line to include the path to the wp-config.php file and then run it, one at a time, for each and every Wordpress installation on the server. Your installation script apparently found and edited every one of them without our intervention. Why are you making it so difficult to uninstall?
+1 The first command finds all the paths with wp-config.php files that WordPress Toolkit edited, and then the second script needs you to feed each path one-by-one? That's not automatic, I need to run the command 229 times for a customer who accidentally choose to install it (before WPT v5.2.4)...0 -
I was reading through the thread and I didn't see anyone mention how the Wordpress Toolkit also installs a 'drop-in plugin' and it's located in your Wordpress content folder called 'Maintenance.' Does anyone know if detaching a website from Wordpress Toolkit will remove the files it installed in your Wordpress directory? (i.e. the 'Maintenance' folder and all it's contents inside and any other files) I was trying to figure out where this 'drop-in plugin' came from as I deleted it and it came back. I investigated it, found the maintenance folder but thought it was placed there via a Wordpress update. I investigated it even further and it came from the Wordpress Toolkit. I can't quite figure out why this was a necessary thing to do without asking for consent to install files in someone's Wordpress directory. I ended up deleting the folder and maintenance.php file that was outside the folder. So far it hasn't auto generated again. The first time I just deleted the php file and not the entire folder. Which looked like why the .php file kept coming back. The wp-config file edit was not that bad. I got over it and auto-updating to a minor release isn't a big deal for me but the drop in plugin and files added to the content folder was uncalled for. 0 -
@Alongar - if the site has ever been put into maintenance mode through the cPanel interface the /wp-content/maintenance directory gets created. Unlinking a site from WordPress Toolkit does not remove that directory at this time. If you'd like to see the directory removed it would be best to submit a feature request so we can work toward getting that behavior changed, but the presence of the directory itself will not interfere with the way the site works. 0 -
@cPRex I never put the site in maintenance mode through cPanel. 0 -
Would you be able to share the contents of the maintenance directory so I could confirm if this was something put in place by WPT? 0 -
AFAIK those are standard files/folders for WordPress Toolkit managed installations. I've seen them in Plesk in the past too. They're here in cPanel as well. You don't need to enable maintenance mode for them to appear, simply adding a WordPress installation to WordPress Toolkit is enough. Not particularly bad when you actually add the WordPress sites yourself - the problem here is that in the v5.2.3 it happened automatically after installation (even if you hadn't ran the plugin at all yet). Anyway, what is done is done - we can't change that. I believe it's clear to the devs that altering client files in any way is not acceptable. 0 -
In my testing, I couldn't get them to appear without putting a site in maintenance mode, although my site was only running for a few minutes. If something else is making that happen, I'm personally not aware of it, so I just wanted to see his file structure for comparison. 0 -
@cPRex It happened when Wordpress Toolkit was first introduced in the cPanel update. Wordpress Toolkit automatically attached itself to my Wordpress website on my VPS after the update. It added the Maintenance folder under wp-contents. Inside the wp-contents folder there was also a maintenance.php file that resided outside the actual maintenance folder. Both items were added by Wordpress Toolkit automatically during the cPanel update that introduced it. I actually didn't realize it until a week ago that Wordpress Toolkit added my website when I was trying to figure out where this maintenance drop-in plugin came from that appeared on my Wordpress backend. During that update that introduced Wordpress Toolkit, when my site was attached to it automatically, it also by default had 'Disable wp-cron.php' feature active. I already disabled the native Wordpress cron job before Wordpress Toolkit and had a manual cron job going. Wordpress Toolkit added another cron job on top of the one I already had. So there was 2 cron jobs going. I disabled the cron job feature in Wordpress Toolkit, as well as, deleted the cron job it added. After that, I noticed after disabling that feature, it deleted the 'define('DISABLE_WP_CRON', true);' line from my wp-config.php (keep in mind, that code was in my wp-config file before Wordpress Toolkit took over, I disabled it beforehand because I was using a server side cron job). So, I had to add the line back to my wp-config file. I went to look at Wordpress Toolkit and 'Disable wp-cron.php' was now active again. I checked server cron jobs, but only the one I manually input was there (Wordpress Toolkit did not add another one this time around). Also, when I look at the security fixes and recommendations provided by Wordpress Toolkit, the 'secure' box is not active when checking hardening features. It's disabled and can not be clicked to apply any hardening. Anyway, that's not really a big deal since I have hardening in place in the areas Wordpress Toolkit recommends or has it flagged as critical. For example, Sucuri Wordpress plugin does the same hardening features as Wordpress Toolkit. However, Wordpress Toolkit does not recognize those hardening features in place and flags the site with critical issues. I also have my directories and files with the correct permissions but Wordpress Toolkit still flags it as being 'critical'. I attached the file of the security issues and how the secure button is disabled. Anyway, I like the idea of the Wordpress Toolkit. Especially, the hardening features which can replace plugins that do the same thing. That would be one or more less plugins to use if Wordpress Toolkit can do it server side instead of installing a plugin via Wordpress dashboard. The issue I have, like many others, was the roll out of Wordpress Toolkit which applied changes to web server files and/or added files and directories automatically during the release. As to your question about sharing the contents of the files and directories so you can confirm: Under Maintenance Folder: Assets template.phtml Under Assets in Maintenance Folder: Fonts Images styles.css timer.js Under Fonts in Assets Folder: open-sans-300.woff open-sans-300.woff2 open-sans-regular.woff open-sans-regular.woff2 Under Images in Assets Folder: bg.jpg facebook.svg instagram.svg plesk-logo.png twitter.svg Those were the contents of the maintenance folder. However, outside that folder resides maintenance.php which is located in the wp-contents folder as well. That file relates to the maintenance folder contents. Both the maintenance folder and all contents inside, and the maintenance.php were added by Wordpress Toolkit. 0 -
Thanks for the great details. I can confirm those are the files created by WPT. As long as you don't have a .maintenance file present in your WordPress' root directory, the site is not currently in maintenance mode, but the folders can still exist. Did you see the site in maintenance mode at some point or are you just concerned with the presence of the files? 0 -
Thanks for the great details. I can confirm those are the files created by WPT. As long as you don't have a .maintenance file present in your WordPress' root directory, the site is not currently in maintenance mode, but the folders can still exist. Did you see the site in maintenance mode at some point or are you just concerned with the presence of the files?
No, the site was not seen in maintenance mode even with the files there. I removed the files since I have my own maintenance feature in place. Also, I haven't tested it yet but it looks like WPT also created a 'wordpress backup' directory. I haven't performed the backup via WPT to see if the backup files get placed in that folder. Another question, do you know why the 'secure' button in WPT is not active when critical issues and recommendations are checked off under the security option in WPT? I attached a screenshot in the previous post of mine to get a better view of what I am talking about.0 -
The backup directory I'm not sure about as that doesn't seem like a standard naming convention. So far we haven't been able to reproduce the odd behavior of the maintenance directory just appearing, so if someone that sees this could submit a ticket that would help us out, as I don't have a good explanation for the behavior you're experiencing at this time. 0 -
Not only does it not pick up what the plugins do, it doesn't pick up on what WP does either! I had a site set to Search engine visibility off in one of my test sites... After I went and turned it back on, the toolkit still showed it as off. Makes me wonder who has the final word on such things, the toolkit, or WordPress it's self?? Not good... 0 -
I'll check that out too @rivermobster and report back 0
Please sign in to leave a comment.
Comments
95 comments