Making sure updates didn't break anything

Question

I am tasked with updating plugins and core on a number of blogs that I am completely unfamiliar with (nothing weird about them, but I haven't worked with them before today).

What I need to do is update all the plugins and the core, and after it's done fix or rollback any introduced bugs. Thing is, I don't have shell access and I don't have access to a home directory on the server, so I can't automate a lot, or I don't know how to automate anything that will run tests or the like after every update to make sure that nothing is broken.

These are fairly large sites, so there are a lot of places bugs can hide. Is there a recommended procedure for this? Or is there a way that I can pretty well reliably catch any new bugs introduced?

I'm not worried about temporary errors, because this is a staging environment, but I do want comprehensive knowledge that nothing is busted. I should have access to error_log files, but I'm not 100% sure I do yet, and I haven't seen any.

Any help?

Answer 1

You can use updraft backup it's free plugin. It will make backup before updating.

Problem is if your auto update didn't copy all wp-core files (this happen) and you don't have access to home and ssh you are not able to fix that. Even with backup.

Answer 2

My general advice would be: Don't do it.

You could let the client know that they're making your work much more difficult to perform than it ought to be, and include that in your charges. You could also, maybe more important, warn them clearly that in a small percentage of cases, a plugin or core upgrade will crash a site in a way that can ONLY be recovered from externally.

I personally would still be reluctant to proceed, even if they signed a legally sound release form - because who needs the headache?

As for making them see reason: If they might happen to think they are being wisely careful about security, you can inform them that, when they give you or anyone access to WP Admin, they are giving you access to the filesystem (and DB) anyway. You could, for instance, install a File Manager plugin, open up wp-config.php, turn debugging and logging on ("true"), and prepare to access the files you want that way... and you could also, intentionally or not, also proceed to wreck the site in any number of ways - so why not give you shell or FTP access? The lack of it just means that you'll need possibly a lot more time even if things go well, and in the meantime adds risks in case they go very badly.

If, after that, they still won't give you external access to filesystem and DB, then you may not be dealing with rational parties. I wouldn't trust them to abide by the terms of any release of liability or other understanding you've gotten from them. If they have some other reasonable explanation for their refusal to give you what you need to do your work efficiently and responsibly, then I'd be curious to know it.