WooCommerce Checkout Rollback on openSUSE Leap

When checkout breaks, roll back first and diagnose second

If a WooCommerce change causes failed payments, blank carts, or order creation errors, the fastest safe move is a controlled rollback of the store code and database state. This tutorial shows you how to do that on openSUSE Leap, using a staging-safe workflow that protects orders, keeps downtime short, and gives you a clean recovery path if the first rollback fails.

The example stack assumes WordPress and WooCommerce are running on Hostperl VPS with Nginx or Apache in front of PHP-FPM. If you host a busy store or a campaign-driven storefront, this is the sort of runbook your support team wants before launch night, not after an incident.

This guide uses openSUSE Leap because it is a valid and stable Linux track for production server work in 2026. If your store runs on a different Linux distribution, the same rollback logic still applies, but the package and service commands will differ.

What you will roll back and why

A proper WooCommerce rollback is not just copying files back. You need to restore three moving parts in the right order:

• Application code such as WordPress core, plugins, themes, and custom mu-plugins.
• Database state so product edits, checkout settings, and order metadata match the restored code.
• Runtime config such as PHP-FPM, web server config, and environment files that affect checkout flow.

For a live store, the safe sequence is: freeze writes, take a backup, restore the last known-good release, confirm database compatibility, and test checkout from a client browser. That avoids the common mistake of rolling back code while leaving incompatible database changes in place.

For store owners comparing hosting options, this is where resilient infrastructure matters. A dedicated server gives you more headroom for backups, PHP workers, and database I/O when you need a fast recovery window.

Before you start: lock in the recovery point

Run the first SSH connection from your local computer, then keep that root session open until the new admin login is verified.

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation address. Replace it with the real public IP assigned to your server. If your provider uses a default non-root account, the first login may instead be ssh deploy@203.0.113.10 after that account exists, but start with root when you need an initial recovery runbook.

On the VPS as root, detect the operating system first.

cat /etc/os-release

You should see openSUSE Leap details such as NAME="openSUSE Leap". If you do not, stop here and confirm you are on the expected host before changing anything.

Prepare the rollback workspace on openSUSE Leap

On the VPS as root, update package metadata and install the tools you need for backups, verification, and web service control.

zypper refresh

This refreshes the repository metadata so you are not restoring from stale package state.

zypper install -y rsync tar gzip mariadb-client curl unzip sudo

These packages cover file sync, compressed archives, database export/import checks, HTTP testing, and privilege management. If your store uses PostgreSQL instead of MariaDB, install the PostgreSQL client tools instead of mariadb-client.

Create a dedicated deploy user so recovery actions do not depend on direct root access.

useradd -m -s /bin/bash deploy
passwd deploy
usermod -aG wheel deploy

Set a strong password now. Later, after key-based access is working, you can lock password login if your policy allows it. On openSUSE, the wheel group is the standard sudo path.

Switch to the new account and create its SSH directory.

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

If you do not already have a key in /root/.ssh/authorized_keys, add one from your local computer first with ssh-copy-id, then copy it to the deploy user. Keep permissions strict or SSH will ignore the key file.

Open a second terminal on your local computer and test the new account before changing anything else.

ssh deploy@203.0.113.10

When logged in, confirm sudo works.

sudo -iu root whoami

You should see root. Do not close the original root session until this new login is confirmed.

Identify the WooCommerce release point

On the VPS as the non-root sudo user, change into the live site directory. In this example, the store lives in /opt/myapp, which is a safe generic application path for the tutorial.

sudo -iu deploy
cd /opt/myapp
pwd

Check which release is currently deployed and where your backup files live. Many production stores keep a current symlink and timestamped release directories.

ls -la
find . -maxdepth 2 -type d | sort

You are looking for evidence of a previous known-good release, such as /opt/myapp/releases/2026-10-12_2200 and a current link. If you use Git deployment, identify the last stable commit before the checkout failure.

If you need a broader reference for safer deploy flows, the article Git Deployments on Docker Compose for Safer Releases is useful for understanding controlled release movement, even if your store is not containerized.

Freeze writes before the restore

A rollback is safer when you stop checkout changes for a few minutes rather than let orders race the restore. Put the store into maintenance mode from WordPress, or use a temporary server-side block if the admin area is broken.

If wp-cli is available, use it from the WordPress root.

cd /opt/myapp/current
wp maintenance-mode activate

If wp-cli is not installed, create a temporary maintenance file at the web root.

touch /opt/myapp/current/.maintenance
ls -l /opt/myapp/current/.maintenance

That file should exist only during the recovery window. Remove it after validation.

Back up the broken state before restoring

Even if the site is already broken, capture the current state first. That gives you a return path if the rollback reveals a hidden data mismatch.

mkdir -p /opt/myapp/backups/pre-rollback-$(date +%F-%H%M)
rsync -aHAX --delete /opt/myapp/current/ /opt/myapp/backups/pre-rollback-$(date +%F-%H%M)/files/

Replace the date output with the actual timestamp created by your shell. This copies the active code and uploads area to a dated backup directory.

Export the database before you restore anything else.

mysqldump -u root -p --single-transaction --routines --triggers wordpress_db | gzip > /opt/myapp/backups/pre-rollback-$(date +%F-%H%M)/wordpress_db.sql.gz

Replace wordpress_db with the live database name. If your database user is not root, use the application account with export permission. A successful run ends with a compressed SQL file in the backup folder.

Restore the last known-good WooCommerce release

Now move the application code back to the previous stable version. If you use release directories, retarget the current symlink. That is safer than copying files over a live tree.

cd /opt/myapp
ls -la releases
ln -sfn /opt/myapp/releases/2026-10-12_2200 /opt/myapp/current
readlink -f /opt/myapp/current

Replace 2026-10-12_2200 with your actual known-good release. The final command should print the path you just selected.

If you do not use release directories, restore files from your backup snapshot instead.

rsync -aHAX /opt/myapp/backups/pre-rollback-2026-10-14-1430/files/ /opt/myapp/current/

Replace the timestamp with your actual backup directory. This method works, but a symlink-based release layout is easier to roll back again later.

Restore the matching database state

Checkout problems often come from database changes that the old code does not understand. Restore the matching database dump you captured before the incident, or the last known-good dump from your backup schedule.

gunzip -c /opt/myapp/backups/pre-rollback-2026-10-14-1430/wordpress_db.sql.gz | mysql -u root -p wordpress_db

Again, replace the timestamp and database name with your real values. When the import completes, confirm the tables are present.

mysql -u root -p -e "USE wordpress_db; SHOW TABLES LIKE 'wp_posts'; SHOW TABLES LIKE 'wp_options';"

You should see the expected WordPress tables. If tables are missing, stop and restore the dump again before bringing the site back online.

Check PHP-FPM and the web server before reopening checkout

openSUSE Leap commonly uses systemd-managed services for PHP-FPM and your web server. Check status before you take the site out of maintenance mode.

systemctl status php-fpm
systemctl status nginx

If your stack uses Apache, check apache2 instead of nginx. The service name must match your actual stack.

Open the relevant config file and make a small safety check if you changed PHP limits, timeout settings, or reverse proxy rules during the incident.

nginx -t

A clean test should end with syntax OK. If it fails, fix the exact file and line number before reloading.

If your store uses Apache, test the config with:

apachectl configtest

Then reload only after a clean syntax test.

systemctl reload nginx

or

systemctl reload apache2

Use only the command that matches your web server.

Run checkout smoke tests from the server and a client

First test the homepage and checkout route from the server itself. That helps separate application failure from external DNS or firewall issues.

curl -I https://example.com
curl -I https://example.com/checkout/

You should get a 200, 301, or 302 response depending on your configuration. A 500 usually means PHP or database trouble. A 403 often points to permissions or WAF rules.

Next, test from your local computer with a browser or a simple HTTP check.

curl -I https://example.com

If the site returns normally, open an incognito browser window and complete a real smoke test: add a low-value product to cart, continue to checkout, and verify that payment gateway redirects and order creation behave as expected. Do not use a live payment if the gateway is in test mode.

For store operators who need an adjacent reliability checklist, WooCommerce Checkout Reliability on Hostperl VPS covers the common failure points that usually show up during peak traffic.

Remove maintenance mode and confirm persistence

Once checkout works again, take the store out of maintenance mode and confirm the recovery survives a restart.

rm -f /opt/myapp/current/.maintenance
wp maintenance-mode deactivate

Then confirm the services are enabled and running.

systemctl enable php-fpm nginx
systemctl is-enabled php-fpm nginx
systemctl is-active php-fpm nginx

If your stack uses Apache, replace nginx with apache2. A healthy result shows enabled and active.

Finish with a reboot-persistence check during a quiet window if you can.

reboot

After the server returns, SSH back in and repeat the service and HTTP checks. If the store comes back cleanly after reboot, your rollback is durable, not just temporary.

Security and recovery notes for production stores

If the failure came from a bad plugin update, leave that plugin disabled until you review logs and compatibility notes. Repeatedly re-enabling a broken extension during business hours usually creates a second incident.

Check logs for the exact failure reason.

journalctl -u php-fpm -n 100 --no-pager
journalctl -u nginx -n 100 --no-pager
tail -n 100 /var/log/php-fpm/error.log 2>/dev/null || true

If WooCommerce checkout still fails, the log clues usually fall into one of three groups: database connection errors, PHP fatals, or payment gateway timeouts. Correct the root cause, then re-run the smoke test instead of guessing.

For support teams handling migrations or launch windows, Hostperl’s openSUSE Leap cloud instance setup for production VPS and 2026 hosting buyer checklist for VPS and cloud are useful references for planning future recovery-friendly environments.

Troubleshooting the most likely rollback failures

Problem: checkout returns 500 after restore.
Run tail -n 50 /var/log/nginx/error.log or the Apache error log. If you see PHP-FPM upstream errors, restart PHP-FPM with systemctl restart php-fpm and retest.

Problem: admin works, checkout fails.
Check payment gateway settings, REST API reachability, and security plugins. Use curl -I https://example.com/wp-json/ and confirm the response is not blocked.

Problem: old code cannot read newer database data.
Restore the matching database dump from before the incompatible change. If that is not available, reapply the plugin or theme version that introduced the schema change, then migrate forward carefully later.

Problem: file permissions block uploads or order PDFs.
Run find /opt/myapp/current -maxdepth 2 -type d -exec chmod 755 {} \; and find /opt/myapp/current -maxdepth 2 -type f -exec chmod 644 {} \;, then correct ownership with chown -R deploy:wwwrun /opt/myapp/current or the group used by your web server.

FAQ

Should I roll back files first or the database first?
Take a backup first, then restore code and database together so both layers match the same release point.

Can I skip maintenance mode if the failure is minor?
No. Even a brief checkout issue can create inconsistent orders, duplicate payments, or abandoned carts.

What if I do not have a known-good release directory?
Restore from your last verified backup and then rebuild a clean release process with timestamped directories or Git tags.

How do I know the rollback is complete?
The site responds normally, checkout completes in a browser, logs stay clean, and the services survive a reboot.

Should I re-enable the broken plugin right away?
No. Keep it disabled until you confirm it was not the root cause and test it in staging first.