10. Upgrade to a new version (manual install, production mode)

These are the real steps from upgrading our own live store (0.2.13 to 0.2.16). On that upgrade the storefront showed the maintenance page for about 7 minutes; products, orders and settings did not change, and the license and the AliExpress connection stayed healthy. Your store and server are different, so your times will differ.

For you if you installed GetDropFlow by unzipping it by hand (no Composer) and your store runs in production mode. If you installed with Composer, see the "Upgrade" section of INSTALL.md inside the package.

Read this first

The storefront goes into "maintenance" for a short time. Pick a quiet hour; look at your order count for the last 24 hours first.
Back up first. Do not start until the backup is made and checked.
Do not just unzip over the old files. Files that the new version no longer has would stay behind. Delete the five old module folders first, then unzip the new package.
Run the commands as the user that runs your website, not as root. Otherwise files only root can read or write are created and the storefront can break.
In this page, WEB_USER, WEB_GROUP and PHP stand for the real values on your server. See step 0.

Step 0: find out how your store is set up (look only, change nothing)

In the server terminal, go to the Magento root folder (the one that contains app, bin and pub) and run:

pwd
php -v | head -1
php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
grep -h '"version"' app/code/DropshipKit/*/composer.json
ls pub/static/frontend/*/*/
df -h . | tail -1

Write down:

The version you have now. The five lines should match. The Settings page does not show the version yet, so this command is how you check.
Your Magento version. GetDropFlow needs Magento 2.4.9 and PHP 8.4.1 or newer on the command line.
The languages your storefront uses, from the last ls (for example en_US, es_ES, zh_Hans_CN). In step 6 you must list all of them when you deploy static files. If one is missing, that language loses its styles.
Free disk space, enough for a backup.
The user that runs your website (owner of the files), call it WEB_USER, and the group, WEB_GROUP. Command: ls -ld app.

Below we use these. Replace them with your own:

cd /your/magento/root
M="sudo -u WEB_USER php -d memory_limit=-1 bin/magento"

php must be the same version your website uses. If the server has several PHP versions, use the one the website uses (for example php8.4). Ask your host if you are not sure.

Step 1: back up (do not upgrade without all of it)

B=/root/backup-gdf/before-NEWVERSION
mkdir -p $B && chmod 700 $B
cp -a app/code/DropshipKit $B/DropshipKit-before
cp -a app/etc/env.php app/etc/config.php $B/
$M module:status > $B/modules-before.txt

Database backup: make a full backup with mysqldump (or the backup feature in your host's panel). Read the database user and password from app/etc/env.php; never paste them into a chat, a document or a screenshot. Then check two things:

The file is not empty.
The end of the file has a Dump completed line, and the number of tables inside matches the live database.

A whole-server snapshot is even better, if your host offers it (for example a VPS "snapshot"). Create one before the upgrade. It can put the whole server back to that moment and is your last line of defense. Note: a host usually keeps only one snapshot, it has an expiry date, and restoring it loses orders placed after the snapshot. So it is an extra safety net, not a replacement for the backups above.

Can the backup really be restored? If you can, restore the database backup into a temporary database once and compare row counts of a few key tables (orders, products, tables that start with dropshipkit_) with the live one. In our own upgrade this step was not possible (the website's database account may not create databases), so we marked it "not verified" and relied on the integrity check plus a whole-server snapshot.

Step 2: download the new package and check it

Open the download page on our website, enter your license key and download dropshipkit-manual-install-NEWVERSION.zip.
The page shows the file's SHA-256 checksum. After you upload the file to the server you must compare it; see step 3.

Step 3: upload to the server and check

Upload the zip to the Magento root folder (your host's file manager or SFTP both work).
An upload can scramble the file group of the whole site. Fix it right after uploading:

chgrp -R WEB_GROUP .

Check that the file is not damaged. Put the checksum from the download page on the first line:

E=CHECKSUM_FROM_THE_DOWNLOAD_PAGE
H=$(sha256sum dropshipkit-manual-install-NEWVERSION.zip | cut -c1-64)
[ "$H" = "$E" ] && echo HASH_OK || echo HASH_BAD
unzip -p dropshipkit-manual-install-NEWVERSION.zip BUILD-INFO.txt | head -4

Go on only if you see HASH_OK and the first line of BUILD-INFO.txt is the version you want. Stop on HASH_BAD and download again.

Step 4: turn on maintenance mode and swap the modules

From here on the storefront shows "maintenance".

$M maintenance:enable
[ -d app/code/DropshipKit/Core ] && rm -rf app/code/DropshipKit/Admin app/code/DropshipKit/Catalog app/code/DropshipKit/Core app/code/DropshipKit/Orders app/code/DropshipKit/Shipping
unzip -q -o dropshipkit-manual-install-NEWVERSION.zip "app/code/*"
chown -R WEB_USER:WEB_GROUP app/code/DropshipKit
find app/code/DropshipKit -type d -exec chmod 2770 {} +
find app/code/DropshipKit -type f -exec chmod 660 {} +
grep -h '"version"' app/code/DropshipKit/*/composer.json

The last line should show the new version five times.

Step 5: database upgrade and code compile

$M setup:upgrade --keep-generated
$M setup:di:compile

On our small store setup:di:compile took under a minute; a big store takes longer. When the screen goes quiet do not close the page; wait for Generated code and dependency injection configuration successfully.

During the upgrade you may see generated/code/Magento cannot be deleted. This is a known harmless message and can be ignored. Stop on any other red error and read "Roll back" below.

Step 6: deploy static files, clear the cache, turn maintenance off

Replace the language list with all the languages you saw in step 0:

$M setup:static-content:deploy -f en_US es_ES zh_Hans_CN
$M cache:flush
chgrp -R WEB_GROUP .
$M maintenance:disable
$M maintenance:status

Keep the store in production mode; do not switch modes.

Step 7: check everything

Storefront (browser or command): the home page, the sign-in page, the cart, the contact page and a product or category page must open normally; the checkout page must open (go as far as "shipping method", do not place an order). Check every storefront language.

To see the status codes with a command:

for u in / /customer/account/login/ /checkout/cart/ /contact/ ; do echo "$u  $(curl -s -o /dev/null -w '%{http_code}' https://YOUR-DOMAIN$u)"; done

You should see 200. An empty cart sent from checkout returns 302 (a redirect), which is also normal. The first request is slower because the cache was just cleared.

Admin: sign in and check, in order:

GetDropFlow → Settings: license status is "Active" and the AliExpress account is "Connected". Press Verify now once (it only asks the license server for the status; it changes no setting).
Every sub-menu under GetDropFlow opens.
Every new GetDropFlow entry under Catalog opens.
Sales → Orders: the list shows. Do not open any order and do not press any submit button.

After the upgrade do not change settings and do not turn on "really submit to AliExpress".

Logs: after the upgrade, look at var/log/exception.log and var/report for new files. In system.log, lines like maintenance mode is enabled during maintenance are normal (scheduled jobs were refused while the store was in maintenance); they stop after you turn maintenance off.

Watch it for an hour: are there any 5xx errors on the storefront, errors from scheduled jobs, are orders still coming in?

Roll back (use it as soon as a step looks wrong)

$M maintenance:enable
rm -rf app/code/DropshipKit
cp -a $B/DropshipKit-before app/code/DropshipKit
chown -R WEB_USER:WEB_GROUP app/code/DropshipKit
$M setup:upgrade --keep-generated
$M setup:di:compile
$M setup:static-content:deploy -f ALL-YOUR-LANGUAGES
$M cache:flush
chgrp -R WEB_GROUP .
$M maintenance:disable

You usually do not need to restore the database. If you really must, first make sure the backup file is good, then restore it; restoring loses the orders placed after the backup, so think before you do it. The whole-server snapshot is the last resort.

Common problems

The Settings page shows no version. How do I know the upgrade worked? Run the grep '"version"' command from step 0 and look at the five modules; if they all show the new version, it worked. From 0.2.17 on, the license box of the Settings page has a row "GetDropFlow plugin version" that shows the version the five modules share; if the five modules differ, that row warns in bold and lists each module's version, which means the upgrade was not completed: install the whole package again. Versions before 0.2.17 have no such row.

The Settings page shows an error saying the settings page class needs 15 arguments but only 14 were passed? The compiled dependency configuration is still the old one after the upgrade. Run $M setup:di:compile, then $M cache:flush, then reload the Settings page. A store that was compiled before the upgrade to 0.2.17 (production mode always is) must be compiled again after it; the commands of step 5 already include this, do not skip it. (AI translation, not proofread by a person.)

The storefront shows a 500 error or a blank page? First $M cache:flush, then chgrp -R WEB_GROUP .; if that does not help, use "Roll back" above.

The admin Settings page does not open? Look at the last lines of var/log/exception.log and send the error to our support. Never include database passwords or license keys.

I installed with Composer? This page does not apply; see the "Upgrade" section of INSTALL.md in the package.