# Update Verify #
**Contributors:** danielbachhuber, ipstenu, dreamhost
**Tags:** wordpress updates
**Requires at least:** 4.4
**Tested up to:** 5.9
**Stable tag:** 0.2.4
**License:** MIT
**License URI:** https://opensource.org/licenses/MIT

Verifies the WordPress update process

## Description ##

Verifies the WordPress update process by comparing heuristics about the WordPress installation before and after the update. 

These checks include:

* HTTP status code.
* Whether or not a PHP fatal error is detected.
* Whether or not the closing `</body>` tag is detected.

### How to Use ###

At DreamHost, we have coded this to run for every single upgrade, be it core, plugins, or themes.

Example: `$ wp upgrade core`

This will run an upgrade and return data in 'reporting' mode.

Should an upgrade need to happen that skips these checks, you must pass the `--skip-packages` flag.

Example: `$ wp upgrade core --skip-packages`

It is _not_ recommended to do this unless the upgrade is intended to temporarily break a site, or the site is down and cannot update.

### Valid HTTP Codes ###

The following codes are considered a valid and safe return:

* '200' - Literally this is okay.
* '401' - This happens when there's an `.htpassword` file.
* '503' - Many maintenance plugins throw this.

### Reporting mode ###

By default, Update Verify operates in a reporting mode; these heuristics are output alongside standard web or CLI update output.

    $ wp core update --path=/path/to/wordpress
    Updating to version 4.9.1 (en_US)...
    Fetching pre-update site response...
     -> HTTP status code: 200
     -> Correctly detected closing </body> tag.
     -> No uncaught fatal error detected.
    Unpacking the update...
    Fetching post-update site response...
     -> HTTP status code: 200
     -> Correctly detected closing </body> tag.
     -> No uncaught fatal error detected.
    Cleaning up files...
    No files found that need cleaning up.
    Success: WordPress updated successfully.

### WP-CLI command ###

To use the heuristics to influence the update process, run the `wp core safe-update` WP-CLI update command instead.

Under the hood, this WP-CLI command aborts the update process if it detects WordPress to already be broken, and rolls back to the prior WordPress version if the update process caused detectable breakage.

For WordPress installations older than 3.7, `wp core safe-update` will first use `wp core download` to bring the installation up to WordPress 3.7, and then use WordPress' internal upgrade process for the remaining update.

Here's an example of what you might see running `wp core safe-update`:

    ###
    # 500 status code observed while updating from WP 4.6 to 4.9, and causes rollback.
    ###
    $ wp core safe-update --path=/path/to/wordpress
    Currently running version 4.6
    Updating to version 4.9.1 (en_US)...
    Fetching pre-update site response...
     -> HTTP status code: 200
     -> Correctly detected closing </body> tag.
     -> No uncaught fatal error detected.
    Unpacking the update...
    Fetching post-update site response...
     -> HTTP status code: 500
     -> No closing </body> tag detected.
     -> No uncaught fatal error detected.
    Rolling WordPress back to version 4.6...
    Downloading WordPress 4.6 (en_US)...
    154 files cleaned up.
    Success: WordPress downloaded.
    Error: Failed post-update status code check (HTTP code 500).

If the update process is successful, all output is written to `STDOUT` and the process returns exit code `0`. If the update process fails in some way (pre- or post-updatE), the final error message is written to `STDERR` and the process returns exit code `1`.

## FAQ ##

TBD

## Changelog ##

### 0.2.4 (Feb 2022) ###
* Added in loop to check site status multiple times. This helps avoid DNS errors in rare cases.

### 0.2.3 (Aug 20, 2021) ###
* Use non-cached URL
* Improve post update checks to properly return errors
* Teach safe-update about safe HTTP codes

### 0.2.2 (Aug 18, 2021) ###
* Force English

### 0.2.1 (Aug 16, 2021) ###
* Allow --skip-packages to override checker.

### 0.2.0 (April 8, 2021) ###
* Finishing IP override and better fails in all cases.

### 0.1.3 (Feb 17, 2021) ###
* Allow IP override for internal DNS.

### 0.1.2 (Dec 10, 2019) ###
* Added new check with pure curl to account for cases when a proxy is down (the HTTP API library makes this a fatal, which breaks further checks)

### 0.1.1 (2018) ###
* Updated 'closing </body> tag' detection message to clarify it's a success.

### 0.1.0 (2017) ###
* Initial release.