Time For a Major Rethink

WordPress does remove files on updates, if the files are outdated. Read https://halfelf.org/2011/how-the-wordpress-upgrade-works/ (yes, still valid).

Minor updates normally never delete anything. This time they did delete example.html from Genericons: https://core.trac.www.ads-software.com/changeset/32386/branches/4.2/src/wp-admin/includes/update-core.php?old=32125&old_path=trunk%2Fsrc%2Fwp-admin%2Fincludes%2Fupdate-core.php

So in this case, we really did our best to make sure things were okay.

Mika, that only applies on automatic updates. It doesn’t apply to the rest of us who cannot risk letting an automated update destroy sites with untested theme updates and incompatible code. Also, with many of the problems coming up in themes and plugins, and with an unreliable standard of what is a major upgrade, it’s hard to see that this really working out

It would be much more inclusive if this was an “instakker” separate from the automation. You upload (to automatically) download all of the packages, theme updates, and the like, and then run the installer – which does the work and CLEANS UP. Right now, you have multiple ways for wordpress to be managed and maintained, and only one of them (automatic updates) will accomplish what is needed to secure a website.

Mika, that only applies on automatic updates. It doesn’t apply to the rest of us who cannot risk letting an automated update destroy sites with untested theme updates and incompatible code…
…Right now, you have multiple ways for wordpress to be managed and maintained, and only one of them (automatic updates) will accomplish what is needed to secure a website

On the surface, that all seems a bit contradictory… So, it won’t work for you because you won’t allow automatic updates, but the only way to a secure site is through allowing an automatic updater?

Can you provide some clarification (in particular, about the ‘installer’ method you’re suggesting) ?

Hi Clayton.

Automated updates are good to a certain extent, but they come with risks. Most wordpress installs are a combination of core code, plug ins, themes, and sometimes custom code. Any one of those things can upset the other, so automated updates some with risks.

So I use other methods to perform updates on the sites I maintain. Some of them require that I use sFTP or similar to transfer files. Other servers with multiple installations get a single upload and then an automated copying to each of the target WP installs. Some MU sites are done with a combination of these methods and more scrupulous checks to assure that the sites hosted do not drop. For what it’s worth, it’s the methods used in the wordpress world for all installs until the automatic updates thing came along.

it’s also generally not the best idea to provide direct FTP access into a server for a remote update, especially if that server hosts many sites or many user accounts. It’s just not a good idea to leave a potential security hole like that available. I do fear the day someone figures out how to tap into the current WP automated process to do harm.

The downside is that security updates that require files to be removed do not work under the current setup. FTP or file copy / replace does not account for files that are no longer in use or in the package. The only way currently to assure that everything is 100% is to literally delete the entire wordpress install (except data files and uploads) and reinstall from scratch – or to run a file by file comparison looking for stray files.

It’s a lot of work – and do that work close to 200 times each time an update comes out, and you can imagine the work involved. Most people just won’t do it, and as a result, wordpress installs that I have seen over 10_ years using it are generally hellacious collections of dead plug ins, unused themes, and other flotsam.

So my suggestion is to create an installer that works for everyone. That would mean moving the installer part of the automated updates out into the open so that the rest of us can use it. Upload the package, run the installer, and it does what it does – including deleting abandoned files.

I also think that it would be really good to include a report scanning all wp core directories and assuring that there are no extra files or files that do not match up to the current version.

Realistically, the same should apply to themes and plugins as well. Each update should include methods to confirm all of the valid files and to remove or flag any that are not valid or not part of the current package. That would very likely mean an extra step in the process of approving themes and plugin updates, as an extra step would have to be taken to verify file changes. The hope is that something like that might have noted the big increase in the number of files in the Yoast plugin update that included a whole bunch of stuff nobody needed – and if not, at least provide a better way for EVERYONE using the product to benefit from keeping systems clean.

It would likely need an interface to allow manual triggering of the updates. That way the admin could control what does and what does not get updated.

That’s a well thought out response. Thank you!

Oh, and in case I missed it, the installer should be for everything including applying theme updates and plugin updates. They should all go through an installer and be responsible for cleaning up their own messes. The Yoast extra file situation should have been resolved in the next update and the files automatically removed when the installer applied the update.