Updating the shop
An update replaces the core files with a newer release: security fixes, bug fixes, new features. It is the moment when the rule of the whole course pays off — everything of your own lives in extension/, and the core is untouched. A shop with edited core files cannot be updated without losing those edits.
What an update changes
| Part | What happens |
|---|---|
catalog/, admin/, system/ | Files are replaced with new ones |
extension/opencart/ | Built-in extensions are replaced |
extension/acme_hello/ | Stays as it is |
config.php, admin/config.php | Stay as they are |
image/, the storage folder | Stay as they are |
| Database | The upgrade script adds new tables and columns |
Step 1. A backup
Before anything else save the files and the database:
mysqldump -u root -p shop > shop-before-update.sql
tar -czf shop-before-update.tar.gz /var/www/shopThe first command saves the database, the second packs the site folder into an archive. A database copy can also be made in the admin panel: System → Maintenance → Backup / Restore.
Step 2. A test copy
Deploy the backup to a separate address, for example http://test.shop.test/, as in the deployment lesson. The update is first done there, and on the live shop only after everything is checked.
Step 3. New files
Download the archive of the new release and copy the contents of its upload folder over the files of the shop. Do not copy config-dist.php over your configuration files — they are separate files and yours stay in place. If the admin folder was renamed, copy the contents of the new admin into the folder with your name.
Step 4. The upgrade script
The database is brought to the new structure by the upgrade script. It is started by opening the address of the install folder that came with the new files, http://test.shop.test/install/: the installer sees an existing shop and offers an upgrade instead of an installation. In some releases the upgrade is also available from the admin panel in the System → Maintenance section. Follow the upgrade instructions that come in the archive of your release — the steps differ between releases.
After it finishes, delete the install folder again.
Step 5. Checking
| Check | Where |
|---|---|
| The storefront and the admin panel open | Both addresses |
| The version has changed | Footer of the admin panel |
| Your extensions work | Their settings pages and blocks on the storefront |
| Events are in place and enabled | Extensions → Events |
| A test order goes through to the end | Storefront, then Sales → Orders |
| The error log is empty | System → Maintenance → Error Logs |
Between releases 4.0 and 4.1 method signatures and array keys changed — the places marked in this course as depending on the release are the first to check in your code.
Common mistake
A fix is made right in a core file — «it is only one line». Half a year later an update with a security fix is released, and it cannot be installed: nobody remembers what was changed and where. Keep everything of your own in extension/ and connect it through events; then an update is copying files and running one script.