UpgradeMODX provides a dashboard widget that checks for available upgrades to MODX and (optionally) installs them. The upgrade process is automatic and very simple. It shows you a form with available versions to install (you can set how many it shows). Once you've selected one, UpgradeMODX downloads all the files, puts them in place, and launches Setup. It should upgrade *any* version of MODX except the SDK development version. It should correctly upgrade versions with a moved and/or renamed manager, core, connectors, assets, or processors directory. I think it will upgrade the SDK version to the non-SDK version, but I haven't tested that.

Upgrade MODX is only for upgrades. It will not install a fresh MODX site.

(Jump to System Settings Table)

No matter what upgrade method you use, you are strongly advised to make a full backup of the database and all files and be prepared to restore the site if things go wrong.

For testing purposes (and to fix possible corrupted or missing MODX files), you can "upgrade" MODX to the version you currently have by changing the `settings_version` System Setting to an earlier version. UpgradeMODX will go through all of its steps, download and replace all the MODX files, and launch setup. In theory, UpgradeMODX can also be used to "downgrade" MODX to a previous version, though this has not been extensively tested.

If you have moved or renamed any directories. UpgradeMODX should work fine. It calculates the correct location for the files by reading the `config.inc.php` file. Setup should no longer ask you where your core directory is.

### Installing UpgradeMODX

Go to Extras -> Installer (or System -> Package Management in older versions of MODX) on the main menu in the MODX Manager and click on the "Download Extras" button. That will take you to the Revolution Repository (AKA Web Transport Facility). Put UpgradeMODX in the search box and press Enter. Click on the "Download" button, and once the package is downloaded, click on the "Back to Package Manager" button. That should bring you back to your Package Management grid. Click on the "Install" button next to UpgradeMODX in the grid. The UpgradeMODX package should now be installed.

### Upgrade Notes

Version 2.0.x of UpgradeMODX has a very different look and many upgrades. It stores all configuration data in System Settings instead of snippet properties, so all settings will survive upgrades. The Settings can be found by going to System (gear icon) -> System Settings and selecting the `upgrademodx` namespace. The installation script will attempt to copy your snippet property values to the new System Settings. In view of the attacks on MODX, the default `interval` will be reset to 1 Day.

Most of the work is now done in JavaScript and MODX processors. The UpgradeMODXScriptSource chunk has been removed.

Here's a quick summary showing some of the new features:

- Tell Setup where the core is, so it doesn't ask!
- Restyle for Mobile
- Automatically select appropriate upgrade version
- Automatically extend version list to include current version
- Indicate current version in version list
- Report progress during upgrade process
- 3D animation for progress (except on f@$@|#% IE < Edge)
- Use a separate processor for each step to avoid PHP timeouts
- Use Guzzle for all remote file and data access
- Operate entirely in the Manager until setup is launched
- Fix bug with missing versionlist error
- Make sure downloaded file is closed
- Get MODX files directly from AWS
- Other bug fixes and improvements

Because Guzzle is used for the HTTP requests, PHP 5.4 is now the minimum required version of PHP, though some users have reported that they needed to upgrade to PHP 7 to get UpgradeMODX to work for them.

### Credits

This package was inspired by the work of a number of people and I have borrowed some of their code. Dmytro Lukianenko (dmi3yy) is the original author of the MODX install script. Susan Sottwell, Sharapov, Bumkaka, Inreti, Zaigham Rana, frischnetz, and AgelxNash, also contributed and I'd like to thank all of them for laying the groundwork.

### Usage

To upgrade your site, just click select a version to upgrade to and click on the "Upgrade MODX" button in the widget. Downloading and extracting the files may take some time, so be patient.

Once you've installed UpgradeMODX, the widget should appear. It's attached to the default dashboard, so if you have another dashboard showing, you'll have to attach it to that dashboard by going to System (gear icon) -> Dashboards.

In very old versions of MODX, creation of the dashboard widget will fail and you'll see a bunch of error messages during the install. The UpgradeMODX installer will attempt to create a resource called `UpgradeMODX` that will show the install check. If no widget appears, view the resource to check for MODX upgrades. When an upgrade is available, it should let you launch the installer.

If the snippet and chunks fail to install (this if fairly rare), your version of PHP is too new for your MODX install and you'll have trouble saving chunks and snippets in the Manager as well. You can either downgrade the version of PHP to version 5.4, or manually make the changes to the three files shown in this commit.

Once you've upgraded MODX to a recent-enough version, you can uninstall and re-install UpgradeMODX to get the widget. You can also upgrade to the current version of PHP.

As installed, the widget will only appear for members of the Administrator group. To show it to other groups, change the `ugm_groups` System Setting. You can also change the `ugm_interval` System Setting if you'd like it to check for upgrades more, or less often, though the default value is now 1 day.

Hint: To get to the Manager's dashboard, you can click on the MODX logo at the upper left.

Note that if you set the interval to 60 seconds (as it is in the beta and rc versions), it won't execute every 60 seconds. It will only execute when you visit the dashboard at least 60 seconds after the last check. The minimum recommendation for the `ugm_interval` System Setting on a production site is `1 hour`.

By default, UpgradeMODX considers only pl (stable) versions for upgrade (except in the beta and rc versions). You can change the `ugm_pl_only` System Setting to see all versions. You can change the `ugm_versions_to_show` System Setting to show more versions (the default is 5). UpgradeMODX will automatically extend the versions shown to include your current version. Initially, the interval for checking is set to `1 day` (except in the beta and rc versions where it's 60 seconds). You can change that by setting the `ugm_interval` System Setting. That setting should always be an integer followed by the name of the unit (e.g., 6 hours, 3 days, 1 week, 1 month.

If you would like to hide the widget when no upgrade is available, change the `ugm_hide_when_no_upgrade` System Setting. The widget will still check for upgrades at the selected interval, but won't appear in the dashboard(s) unless an upgrade exists.

If you would like to fool the widget into thinking there is an upgrade, you can change the `settings_version` System Setting. Make it any earlier version (it doesn't have to be a real version) and the widget will show an update. If you install the update (even though it's not an update) and finish Setup, it will restore the System Setting to its correct value. If you don't run an upgrade, be sure to change the System Setting back to its original value.

You can set the language used by the widget with the `ugm_language` System Setting

You are *strongly* advised not to change anything in the package except the System Settings.

### Security

The upgrade processors can only be run from the Manager, and only by users who belong to allowed user groups (Administrator by default). Even if the processors were available to the public, all they would do is upgrade your site.

The upgrade script downloads everything to the `/ugmtemp` directory in the MODX root directory (or another directory if you have set the `ugm_temp_dir` System Setting). At the default location, UpgradeMODX deletes that directory when it finishes successfully so nothing should be left behind after the upgrade.

If you have changed the directory, UpgradeMODX will leave the downloaded `.zip` files in place. This is handy if you have multiple MODX installs on the same server and avoid downloading the `.zip` file for each one.

After upgrading the site, It's a good idea to make sure that the `/ugmtemp` directory has been removed, especially if the script times out or fails. The files are relatively harmless, but their existence could identify your site as a MODX site, and there's no point in giving potential hackers that information.

### GitHub API Rate Limit Exceeded

The default install of UpgradeMODX makes anonymous requests to the MODX repository at GitHub for information. Requests of this type are limited to 60 per hour. If a lot of people are making requests, or your `ugm_interval` setting is very short, or if you are doing a lot of testing, this limit could be hit and you will either get the error message: `GitHub API Rate Limit Exceeded` or the script will report that it couldn't get the version list from GitHub. You can try again later, but to solve this problem permanently, you can get your own GitHub token so your requests will not be anonymous. That will bump your limit up to 5,000 requests per hour.

You can create a free account at GitHub, or use an existing one. To get a token, follow the directions here. Copy your token to the clipboard, then paste it into the `ugm_github_token` System Setting. Enter your GitHub username in the `ugm_github_username` System Setting. Don't forget to clear the cache after changing any settings. Some browsers will cache the request headers, which contain the credentials, so you may also need to clear your browser cache and cookies.

### Multiple Installs

If you have multiple MODX sites on the same server, you can set the `ugm_temp_dir` System Setting to a path that's available to all sites, like your server's tmp directory. Once you do that, UpgradeMODX will leave the downloaded .zip file in place and skip the download for all sites but the first one. Remember to change that setting on all the sites before performing any upgrades.

### Troubleshooting

If UpgradeMODX reports trouble getting the versions from GitHub, you should get a helpful error message. If you'd like to see the full message returned from GitHub, set the `ugm_verbose` System Setting to `Yes`.

As of UGM Version 2.1.2, if you get persistent errors about the versionlist, you can bypass them by creating the file: core/cache/upgrademodx/versionlist and following these steps:

1. Go to this url: //api.github.com/repos/modxcms/revolution/tags.
2. Copy the entire contents of your browser window (Ctrl-a, Ctrl-c)
3. Paste it into the file (Ctrl-v).
4. Note the name of the latest version at the top of the file (e.g., 2.7.0-pl)
5. Set the `ugm_last_check` and `ugm_file_version` settings to the latest version
6. Clear the Site Cache in the Manager

You should be able to do as many upgrades as needed in the next 24 hours

If you get frequent timeouts, you can increase the `ugm_github_timeout` or `ugm_modx_timeout` System Settings. They set how long the program will wait for a response. The default is 6 seconds.

UpgradeMODX now uses Guzzle (which uses cURL by default) to check for and download files. If cURL isn't installed on your server, Guzzle uses streams to get remote files and requires PHP 5.4 to work.

UpgradeMODX uses ZipArchive to unzip the files. You can set the `ugm_force_pcl_zip` SystemSetting to `Yes` to avoid using ZipArchive to unzip the downloaded MODX file.

In Version 2.0.0 of UpgradeMODX the cURL SSL_VERIFY_PEER option to is set to `true` by default in Guzzle. Guzzle uses the server's certificate file, so there should be no need to turn it off. Having this setting off leaves you vulnerable to man-in-the-middle attacks where the attacker could pretend to be the MODX repo and lead you to download malicious code instead of MODX. If you can't get UpgradeMODX to work because of SSL issues, the best solution is to check with your host. There is a list here of the places Guzzle looks for the certificate file.

Turning the `ugm_ssl_verify_peer` System Setting off might make it work for you, but in a less secure way.

Version 2.0.0 has a new setting: `ugm_cert_path` (empty by default). If you are having SSL trouble, you could try asking the host or checking their forum for the path to the SSL cert file. Paste that path into the `value` field of this setting.

If UpgradeMODX shows an available upgrade but the submit button doesn't work, check the spelling of the `assets/components/upgrademodx/js/progressButton.js` file. Make sure the "B" matches the case of the filename in the UpgradeMODXTpl chunk.

Note that some browsers cache the credentials used in HTTP requests. If you change the `ugm_github_username` and `ugm_github_token` settings. They may not take effect until you clear the browser cache (and maybe the cookies) or use a different browser that doesn't have the cached credentials.

If the widget doesn't appear. Go to System (gear icon) -> Dashboards and check to make sure the widget is on the default dashboard (or whatever dashboard you're using).

### Catch 22

There is a bug in very old versions of MODX that prevents some elements of UpgradeMODX and other extras from being installed if you are using PHP 7 (see the note above about fixing this bug manually). At the same time, UpgradeMODX now requires PHP 5.4 or above because that's what Guzzle requires. There may be other incompatibilities in older versions of MODX and some of your plugins might interfere with the setup process.

If UpgradeMODX fails for you and the troubleshooting steps above don't work, the best approach is to use PHP 5.4, and upgrade MODX manually using the method described here. Make sure you install all major versions of MODX (the ones ending in .0).

Once you hit MODX 2.4, you should be able to upgrade to PHP 7 (assuming that you've fixed the bug), then uninstall and remove Upgrade MODX, re-install it, and use UpgradeMODX from that point on. For security, and to prevent future hassles, keep your MODX install up to date.

### UpgradeMODX System Settings

Setting | Description | Default
--- | --- | ---
GitHub
ugm_verbose | Display full GitHub Error Messages | No
ugm_cert_path | Path to SSL cert file in .pem format; rarely necessary |
ugm_github_username | Your username at GitHub |
ugm_github_token | Github token - available from your GitHub profile |
ugm_github_timeout | Timeout in seconds for checking Github | 6
Widget
ugm_versionlist_api_url | URL of API to get version list from | //api.github.com/repos/modxcms/revolution/tags
ugm_temp_dir | Path to the directory used for temporary storage for downloading and unzipping files; Must be writable | {base_path}ugmtemp/
ugm_file_version | Version when versionlist file was last updated. Set automatically -- do not edit! |
ugm_interval | Interval between checks -- Examples: 1 week, 3 days, 6 hours | 1 day
ugm_last_check | Date and time of last check -- set automatically |
ugm_latest_version | Latest version (at last check) -- set automatically |
ugm_hide_when_no_upgrade | Hide widget when no upgrade is available | No
ugm_version_list_path | Path to versionlist file (minus the filename -- should end in a slash) | {core_path}cache/upgrademodx/
Download
ugm_force_pcl_zip | Force the use of PclZip instead of ZipArchive | No
ugm_modx_timeout | Timeout in seconds for checking download status from MODX | 6
ugm_ssl_verify_peer | For security, have cURL verify the identity of the server | 1
Form
ugm_language | Two-letter language code for language to use | en
ugm_pl_only | Show only pl (stable) versions | 1
ugm_versions_to_show | Number of versions to show in upgrade form | 5
Security
ugm_groups | group, or comma-separated list of groups, who will see the widget | Administrator