Here are the main features of the new Upgrade Center:
- SQL files are no more used. All work with DB is being done with Migrations.
- Now it is possible to define upgrade servers and upload upgrade packages for add-ons.
On the Upgrade Center page you can see available packages. They can be of the two types:
Core packages are downloaded through
$config['resources']['updates_server'] (http://updates.cs-cart.com). Add-ons packages are downloaded through add-on connectors and from servers defined in these connectors.
It is also possible to upload an upgrade package manually using the form on the Upgrade Center page (the + button in the picture above).
Checking for updates
Checking for updates is started in two cases:
- When logging to the administration panel.
- When switching to the Upgrade Center page.
Upgrade Center App sends a request on checking for updates. Connector manager gets the list of all available connectors. Each connector (implementing IConnector interface) returns an array with information about connecting to its upgrade server (each connector can add any data to be sent to a server).
After receiving information about upgrade servers, Connector manager simultaniously sends requests to all of them. Received answers will also be passed to connectors for further processing.
Connector receives an ansver from the server and returns either an empty array (if the update is not available) or information about a package (a package is not downloaded). A returned scheme (array) contains the following mandatory fields:
file- file name (some_upgrade_1.2.3.tgz).
name- upgrade package title (Marketplace add-on upgrade, for example).
description- description of a package: what issues are resolved and improvements are added.
from_version- from what version does an add-on/core uprade.
to_version- to what version does an add-on/core uprade.
timestamp- time of a package creation.
size- size of a package in bytes.
type- type of a package (core/add-on). It is set automatically.
And any optional fields that can be used after downloading a package, for example:
example_md5- 68e109f0f40ca72a15e05cc22786f8e6. It can be the file md5 hash that will be checked after downloading from a server (to avoid substitution, broken files, etc.)
Example of the returned data:
If the upgrade scheme passes the verification, the following scheme is created: /path/to/store/var/upgrade/packages/NAME/schema.json. Where NAME- the name of an add-on or core.
After obtaining the package scheme it is possible to get the package itself (it is not done automatically because the package size can be very big). When clicking the Download button Upgrade Center App uses this package connector and passes the previously saved scheme and a path (where to save the downloaded file) to it.
The connector communicates with its upgrade server, passes the necessary data to it, gets the package content, and saves it according to the given path. In case of the successful saving the connector returns
array(true, '');. If there was an error, (could not connect to a server, save, etc.) it returns the following:
After receiving a file, Upgrade Center App unpacks and checks it:
Checks if there is the package.json scheme (description and structure).
Checks if the package.json scheme description contains information about all files of the package. If there are additional files in the package, it will not pass validation.
If there is an add-on upgrade package, it makes sure that this package does not try to rewrite Core files. Pathes available for the add-on files:
Here is the approximate package structure:
The languages directory contains languages in the Crowdin package format (http://translate.cs-cart.com).
The migrations directory contains phinx migrations. They are applied in the file name TIMESTAMP order. Conceptually, migrations should work only with DB. But in fact they work in the cart environment and can play different roles. However, use the PRE/POST scripts to work with files.
The scripts directory contains the PRE/POST scripts. Scripts running depends on the file name. They are selected according to the
PREscripts are launched before starting the update (but after Validators).
POSTscripts - after the update is over.
The validators directory contains additional checking functions that return true before the update beginning. For example, checking the availability to write in .htaccess, checking the domain name, etc.
The package directory contains new files. This directory is fully copied to the store core.
The package.json file describes the full package structure: files, upadated files hashes, migrations, languages, etc.
Example of the package.json file
Update processing order
Every step of the update process is logged in the following file: var/upgrade/[NAME]_log.txt, where NAME - core or the add-on name. It is always possible to find out the reason of an emergency update stop from there.
Example of a log file: