-
Notifications
You must be signed in to change notification settings - Fork 490
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
8 changed files
with
35 additions
and
248 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,9 +1,8 @@ | ||
| --- | ||
| # this page is redirected so it has no content | ||
| # TODO update link to the new Update from the Back-Office page | ||
| layout: redirect | ||
| redirect: /1.7/basics/keeping-up-to-date/update | ||
| redirect: /1.7/basics/keeping-up-to-date/update/update-from-the-back-office | ||
| _build: | ||
| list: never | ||
| list: never | ||
| showOnHomepage: true | ||
| --- | ||
| --- |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,31 +1,7 @@ | ||
| --- | ||
| title: Upgrade Module | ||
| weight: 80 | ||
| layout: redirect | ||
| redirect: /1.7/basics/keeping-up-to-date/update | ||
| _build: | ||
| list: never | ||
| showOnHomepage: true | ||
| --- | ||
|
|
||
| # Upgrade module | ||
|
|
||
| Also known as the "Autoupgrade module" or the "1-click upgrade module", PrestaShop upgrade assistant aims to automatize the upgrade process. | ||
|
|
||
| Details on how to use the web interface are documented in [Keep up-to-date: Upgrade Assistant page]({{< ref "/1.7/basics/keeping-up-to-date/use-autoupgrade-module.md" >}}). | ||
|
|
||
| {{% children /%}} | ||
|
|
||
| ## New features of v4 | ||
|
|
||
| Although v4 of the module was scoped to be a refactoring, some features were added at the same time to improve the support. | ||
|
|
||
|
|
||
| ### New loggers | ||
|
|
||
| Reporting is now using [PSR-3](https://www.php-fig.org/psr/psr-3/), allowing incomers in the module code to recognize some common code in PHP. | ||
|
|
||
| New loggers have been created: | ||
|
|
||
| - **LegacyLogger**: The existing logger still stores its content in lists before being displayed in a sigle row, and at the same time in a log file. By doing this, we still can get details on what happened if the script execution stopped prematurerly. | ||
| - **StreamLogger**: New logger, used in CLI mode. We do not need to use memory to store the logs, we can display them directly on the terminal. | ||
| - **Error handler**: This was done for debugging. In case of a server error (in web, HTTP 500), the module was unable to display anything to the user. It is then needed to read PHP logs in order to get error details, and some users have trouble doing it. Thanks to this logger, the error is displayed directly on the screen. | ||
|
|
||
| ## How to download it | ||
|
|
||
| You can download it from [Addons marketplace](https://addons.prestashop.com/en/data-migration-backup/5496-1-click-upgrade.html) or from your shop administration panel. It is also available on the module GitHub repository, in the [Releases](https://github.com/PrestaShop/autoupgrade/releases) section. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,43 +1,7 @@ | ||
| --- | ||
| title: Upgrade channels | ||
| weight: 40 | ||
| layout: redirect | ||
| redirect: https://github.com/PrestaShop/autoupgrade?tab=readme-ov-file#channels | ||
| _build: | ||
| list: never | ||
| showOnHomepage: true | ||
| --- | ||
|
|
||
| # Upgrade channels | ||
|
|
||
| Different channels are available for upgrade. | ||
|
|
||
| Depending on the channel, the archive that will be used to upgrade the shop will be different. | ||
|
|
||
|
|
||
| ### Major | ||
|
|
||
| This channel will look at the latest version, even if it is a different major version. | ||
|
|
||
| ### Minor | ||
|
|
||
| This channel will look at the latest version of the same major version. | ||
|
|
||
| ### RC | ||
|
|
||
| This channel is currently disabled. This was done to avoid people getting stuck on pre release software of which they cannot upgrade later. | ||
|
|
||
| ### Beta | ||
|
|
||
| This channel is currently disabled. This was done to avoid people getting stuck on pre release software of which they cannot upgrade later. | ||
|
|
||
| ### Alpha | ||
|
|
||
| This channel is currently disabled. This was done to avoid people getting stuck on pre release software of which they cannot upgrade later. | ||
|
|
||
| ### Private | ||
|
|
||
| This channel allows you to fetch a version from a custom link instead of the official PrestaShop source. | ||
|
|
||
| ### Archive | ||
|
|
||
| This channel will not fetch available versions data from PrestaShop API but will look at a `prestashop.zip` file inside your `<admin directory>/autoupgrade/download` folder. | ||
|
|
||
| ### Directory | ||
|
|
||
| This channel will not fetch available versions data from PrestaShop API but will look at directory content `/<admin directory>/autoupgrade/latest/` |
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,44 +1,7 @@ | ||
| --- | ||
| title: Upgrade CLI | ||
| weight: 40 | ||
| layout: redirect | ||
| redirect: /1.7/basics/keeping-up-to-date/update/update-from-the-cli | ||
| _build: | ||
| list: never | ||
| showOnHomepage: true | ||
| --- | ||
|
|
||
| # Module CLI | ||
|
|
||
| ## Upgrade CLI | ||
|
|
||
| Upgrade module can be used as a Command Line Interface. | ||
|
|
||
| ### Command line parameters | ||
|
|
||
| Entry point is *cli-upgrade.php*. | ||
| The following parameters are mandatory: | ||
|
|
||
| * **--dir**: Tells where the admin directory is | ||
| * **--channel**: Selects what upgrade to run (minor, major etc.) | ||
| * **--action**: Sets the step you want to start from (Default: `UpgradeNow`) | ||
|
|
||
| If you use default `action` parameter, it will run the full upgrade process. | ||
|
|
||
| Exemple | ||
| ``` | ||
| $ php cli-upgrade.php --dir=admin-dev --channel=major | ||
| ``` | ||
|
|
||
| ## Rollback CLI | ||
|
|
||
| If an error occurs during the upgrade process, the rollback will be suggested. | ||
| In case you lost the page from your backoffice, note it can be triggered via CLI. | ||
|
|
||
| ### Command line parameters | ||
|
|
||
| Entry point is *cli-rollback.php*. | ||
| The following parameters are mandatory: | ||
|
|
||
| * **--dir**: Tells where the admin directory is. | ||
| * **--backup**: Select the backup to restore (this can be found in your folder `<admin directory>/autoupgrade/backup/`) | ||
|
|
||
| Exemple | ||
| ``` | ||
| $ php cli-rollback.php --dir=admin-dev --backup=V1.7.5.1_20190502-191341-22e883bd | ||
| ``` |
97 changes: 5 additions & 92 deletions
97
development/upgrade-module/upgrade-module-internal-behavior.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,94 +1,7 @@ | ||
| --- | ||
| title: Upgrade Module internal behavior | ||
| weight: 20 | ||
| layout: redirect | ||
| redirect: https://github.com/PrestaShop/autoupgrade?tab=readme-ov-fil#test-module-updates-locally | ||
| _build: | ||
| list: never | ||
| showOnHomepage: true | ||
| --- | ||
|
|
||
| # Upgrade module internal behavior | ||
|
|
||
| This is how the module is built, for version 4 and higher. | ||
|
|
||
| Most of the information is however valid with the previous versions too. | ||
|
|
||
| ## Entrypoints | ||
|
|
||
| The upgrade module aims to be a PrestaShop module AND be as independent as possible. Which means its content can be reached from several way: | ||
|
|
||
| - **autoupgrade.php** | ||
|
|
||
| Every module developer will recognize its content. This file is used to manage the module part of the project: installation, uninstallation, then automatic redirection to the next file. | ||
|
|
||
| - **AdminSelfUpgrade.php** | ||
|
|
||
| This controller uses the AdminController features from PrestaShop. It allows the upgrade configuration to be displayed in the back office. The merchant will see the configuration options. | ||
|
|
||
| In previous versions it was used to handle everything, displaying answers, handle and dispatching requests... In the latest version, its responsibilities were restricted, which should be displaying the configuration page. | ||
|
|
||
| - **ajax-upgradetab.php** | ||
|
|
||
| This file is called from ajax requests. This is the only file responsible of the initialization and upgrade / rollback steps. This file is not a PrestaShop controller for a simple but important reason, we do not want to rely on the core during an upgrade or a rollback, this would increase the risk of crashes. | ||
|
|
||
| - **cli-upgrade.php** | ||
|
|
||
| This is the equivalent of `ajax-upgradetab.php` file for CLI calls. It will instantiate some specific features to the CLI, like a logger displaying informations on the fly. This entrypoint is also useful for testing, or for a user who does not want to use the web version. | ||
|
|
||
|
|
||
| ## What version to use | ||
|
|
||
| The objective is to have a single module version to handle these PrestaShop upgrades: | ||
|
|
||
| - 1.6 >> to >> 1.6 / 1.7 | ||
| - 1.7 >> to >> 1.7 | ||
|
|
||
| The other versions are not supported anymore. We recommend to use the previous versions of the module available on the PrestaShop marketplace. | ||
|
|
||
| ## Technical choices | ||
|
|
||
| ### Compatibility with PrestaShop 1.6 & 1.7 | ||
|
|
||
| Aim is to help as many merchants as possible to upgrade from 1.6 to 1.7. This required to do the following implementation choices: | ||
|
|
||
| - **Twig as template engine** | ||
|
|
||
| Even if Smarty is still provided by the core, it was decided to use an independent engine template. | ||
|
|
||
| This makes sure than replacing the core template engine won't break the module later. | ||
|
|
||
| - **Core classes avoided** | ||
|
|
||
| Dependencies between the core and the module are limited, because the upgrade will modify classes the modules might need, it is important to avoid relying on them. | ||
|
|
||
| A 100% independent module would be great, but because some features absolutely need the core, it is not achievable. So it was tried to avoiding, when possible, using the core logic. This is mainly until the UpgradeDb step, in order to avoid some undefined methods coming from the new files. | ||
|
|
||
| - **Separate requests** | ||
|
|
||
| The best compromise was to separate requests (even the CLI one) in several steps. | ||
|
|
||
| By doing so, a new fresh core can be started with its updated classes. | ||
|
|
||
| The class Upgrade was introduced to the core around version 1.7.1.0. | ||
|
|
||
| - **Interface still unfriendly** | ||
|
|
||
| So far the main objective has been to make the PHP code easier to understand and improve the robustness of the upgrade process where possible. The interface will be improved in future releases to be more user-friendly. | ||
|
|
||
| ## New module structure | ||
|
|
||
| Most of the PHP classes in `classes` folder are mainly logic extracted from AdminSelfUpgrade, the class that was responsible of everything in previous versions. It has been split in smaller parts. | ||
|
|
||
| Classes are gathered by responsibilities: | ||
|
|
||
| - All classes responsible of the display (Twig related) | ||
| - Classes used for the module to work | ||
| - Classes interacting with PrestaShop core | ||
| - Tasks (Can be considered as controllers for upgrade, rollback etc.) | ||
|
|
||
| ## Local temporary assets | ||
|
|
||
| In order to work properly, the upgrade module needs to write some files to your filesystem server. These files are stored in the following folders, all available in the `<admin folder>/autoupgrade` path. | ||
|
|
||
| ### Folders | ||
|
|
||
| - backup: Folder in which the current state of the shop will be saved before upgrade. It contains files archive, DB structure & data. | ||
| - download: Destination folder of the downloaded PrestaShop archive, before unzip. | ||
| - latest: Working directory of the autoupgrade. This is where the "lastest" version of PrestaShop will be unziped, before copy. | ||
| - tmp: Temporary resources not specifically used for upgrade. For instance, logs will be stored in that folder. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,42 +1,7 @@ | ||
| --- | ||
| title: Upgrade Process Steps | ||
| weight: 30 | ||
| layout: redirect | ||
| redirect: https://github.com/PrestaShop/autoupgrade?tab=readme-ov-file#process-steps | ||
| _build: | ||
| list: never | ||
| showOnHomepage: true | ||
| --- | ||
|
|
||
| # Upgrade process stems | ||
|
|
||
| All these steps are called from the entrypoint `ajax-upgradetab.php`. | ||
|
|
||
| {{< figure src="../img/upgrade-process.png" title="Upgrade process schema" >}} | ||
|
|
||
| ## Upgrade | ||
|
|
||
| The following steps will be executed during the upgrade: | ||
|
|
||
| 1. UpgradeNow: Start of the whole process. The next step will be chosen depending on the configuration. | ||
| 2. Download: Download the proper archive depending on the selected channel | ||
| 3. Unzip: Unzip the downloaded archive | ||
| 4. RemoveSamples: The changes made by the merchant on his shop, like images, must not be deleted! This step removes the example files from the downloaded archive. | ||
| 5. BackupFiles: In case the upgrade does not went well, or if the merchant wants to rollback later, we save the files of the shop. Note this can be filtered, for example if a file is too big. | ||
| 6. BackupDb: Like the files, we save the current database structure and content, in case a rollback is needed. | ||
| 7. UpgradeFiles: Now the current content is saved, we can alter the shop content. This step will run several time. The first call will initialize the files list, then the next ones will copy a part of this list. | ||
| 8. UpgradeDb: This step does much more than you can think. Its initial purpose is to run all the upgrade SQL files available in the install folder. Then, it will run some additional steps, such as theme enabling, cache deletion, language update... | ||
| 9. UpgradeModules: With the list downloaded from the PrestaShop Marketplace in the first steps, we now request updated module zips and update the installed ones. | ||
| 10. CleanDatabase: This step run some SQL queries in order to remove obsolete or wrong data. Note the concerned data is not coming from the upgrade itself, but from the use of PrestaShop. | ||
| 11. UpgradeComplete: The upgrade completed and we want you to know it. This step will display a success message and will end the process. | ||
|
|
||
| ## Rollback | ||
|
|
||
| 1. Rollback: This is the entrypoint of the rollback process. It will find all the available backups regarding the given parameters (basically, the restore backup must be sent from the backup name you generated). If a backup matches the given parameters, the process starts the file restoration. | ||
| 2. NoRollbackFound: A classic task used to display a message saying no backup matches the given parameters, and terminates the process. | ||
| 3. RollbackFiles: Like the step UpgradeFiles, this step copies the files from the archive and remove the files absent from the original environment. | ||
| 4. RollbackDb: This task reads and runs the files generated by BackupDb. | ||
| 5. RollbackComplete: The upgrade may have failed or you were not completely satisfied by the new version, but we brought everything back. You can reuse the shop as before. | ||
|
|
||
| ## Other | ||
|
|
||
| These steps don't follow any process and are independent between each others. | ||
|
|
||
| - CheckFilesVersion: This task is responsible to detect all local files has been modified by the merchant / developer. This is an important pre-requisite which warn about the potential loss of changes. | ||
| - Error: This task can be called from any other one, and will display a specific message saying the upgrade / restore process failed. In case of upgrade, a restore will be suggested. | ||
| - UpdateConfig: This task will store in a configuration file the different options selected in the web version of the module. |