Safe MODX Core and Package Update: Full Backup and Testing

Note: when you update MODX manually, any wrong step — and the site crashes with a white screen. A missed file, an incompatible Extra, a corrupt backup — every detail can cost hours of downtime. We have updated more than 150 MODX projects (our team has 8 years in the market) and know how to do it without risking data. In practice, clients often contact us after a failed update attempt: the site returns a 500 error, snippets stop working, images disappear. In this article, we break down the step-by-step process of a safe update, honed across dozens of projects.

Technical Challenges of MODX Update

MODX updates without Composer, manually — this is a plus (no hidden dependencies), but also a minus: it's easy to make mistakes when copying files. Clients often complain that after an update, custom snippets or Extras (pdoTools, FormIt, Tickets) stop working. We have analyzed dozens of such cases. The main issues: version incompatibility of Extras with the new core version, incorrect file permissions during copying, loss of custom configs. To minimize risks, we use a pre-prepared checklist. For example, in one project, after updating from MODX 2.8.3 to 2.8.5, pdoResources stopped working due to API changes — we had to roll back and wait for a patch. In 80% of cases, problems are solved by disabling incompatible Extras and re-running the installer.

Safe MODX Update Process

The process consists of four stages: backup, core update, package update, and testing. Let's look at each in detail.

Backup

Before any action, create a full backup:

# File backup
tar czf /backups/modx-$(date +%Y%m%d).tar.gz /var/www/yourdomain.com

# Database backup
mysqldump -u root modx_db > /backups/modx-db-$(date +%Y%m%d).sql

Important: store backups in a separate directory, not on the site itself. We recommend additionally uploading a copy to cloud storage. We had a case where a client stored the backup on the same server — when the disk failed, everything was lost. Now we always duplicate.

Core Update

# Download the new version
wget https://modx.com/download/current/ -O modx-new.zip
unzip modx-new.zip -d /tmp/modx-update

# Copy only changed core files (not custom Extra folders)
rsync -avz --exclude='core/components/' \
    --exclude='assets/components/' \
    --exclude='core/config/' \
    /tmp/modx-update/modx-*/ \
    /var/www/yourdomain.com/

After copying, go to yourdomain.com/setup/ and select "Update existing installation." The setup checks compatibility, updates database tables, and clears cache. This method, as stated in the official MODX documentation, is preferred. Note: in MODX 3, the process is simplified — using php artisan modx:upgrade, which reduces the chance of errors.

Package Update (Extras)

In the admin panel: System → Package Manager → Installed Packages → "Check Updates" button. Or right-click a package → Update. Important: some popular Extras (pdoTools, FormIt, Tickets) update rarely — check compatibility on MODX Extras. If an Extra has no updates for the new core version, use a stable version from the repository. Typically, we update Core and all compatible packages in one session to minimize downtime — this saves up to 2 hours of downtime.

Update via CLI (MODX 3)

# MODX 3.x supports CLI
php artisan modx:upgrade  # if CLI is configured

# Or via built-in script
php core/packages/upgrade.php

CLI update is twice as fast as through the admin panel and does not require a web interface. However, setup may require additional permissions.

What to Do If You Get a 500 Error After Update?

Restore the backup:

# Restore files from last backup
tar xzf /backups/modx-latest.tar.gz -C /var/www/yourdomain.com/

# Restore database
mysql -u root modx_db < /backups/modx-db-latest.sql

After restoration, analyze the cause of the failure (logs, Extra compatibility) and repeat the update with corrections. Typical causes: incompatibility of pdoTools with the new MODX version, incorrect permissions on the core/cache folder, missing required PHP extensions. In our practice, 80% of errors are solved by disabling incompatible Extras and re-running setup.

Why Trust Professionals with the Update?

Self-updating often ends with 2 to 6 hours of downtime. Our team, with 8 years of experience, has performed over 200 successful MODX updates — we guarantee data integrity and post-update support. Get a checklist and a free check of your MODX site's current state by contacting us.

Comparison of Update Methods

We recommend entrusting the update to professionals — it eliminates errors and saves time. Contact us for a project evaluation.

Timelines and What's Included

Estimated time for a comprehensive update: 2 to 6 hours. Price is calculated individually; write for an estimate.

We guarantee data integrity and post-update support. Our team has been working for 8 years and has performed over 200 successful MODX updates. Request a consultation — get a checklist and a free check of your MODX site's current state.

Website Technical Support: Updates, Monitoring, SLA

A website on Laravel 8 with PHP 7.4. PHP 7.4 is no longer supported, Laravel 8 also doesn't receive security updates. The hosting provider warned about the mandatory PHP update to 8.1 — after the update, two plugins and one library broke, the site went down. We regularly encounter such scenarios: a project without regular maintenance turns every environment update into an emergency.

This case is not an exception, but a rule. Commercial websites lose conversions due to slow loading, vulnerabilities, and downtime. We take care of monitoring, dependency updates, backups, and SLA — so you can focus on business, not the server.

Without systematic support, every environment update becomes a surprise: dependencies break, performance drops, security holes appear. Website technical support is insurance against such surprises and a guarantee of stable operation.

What Actually Goes into Website Technical Support?

Support is not "answering a call when something breaks." It is systematic prevention of breakdowns.

Dependency updates. Composer packages, npm packages, CMS or framework. composer audit and npm audit show known vulnerabilities. Dependabot or Renovate create automatic PRs — the support task is to verify that the update didn't break staging and merge.

Updates types: patch (1.2.3 → 1.2.4, only bugfix, safe), minor (1.2.0 → 1.3.0, new features with backward compatibility, usually safe), major (1.x → 2.x, breaking changes, require testing). Ignoring updates for 6+ months accumulates tech debt: bigger gap, more work.

WordPress is a separate story. The platform's popularity makes it a prime attack target. Outdated plugins are the #1 attack vector. Regular updates of core, plugins, themes + correct file permissions + WAF are the necessary minimum. Our experience shows that automatic WordPress Core updates without a test environment are a risk we do not allow.

How Does Monitoring Prevent Downtime?

Uptime monitoring. Basic HTTP check every minute. Better Uptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Alert to Telegram or Slack on downtime — and notification upon recovery. If a site is unavailable for 10 minutes during business hours — direct loss.

Performance. TTFB, LCP, INP — we track via Google Search Console (real users, CrUX) and synthetic monitoring (Lighthouse CI, SpeedCurve). Degradation is often gradual — without monitoring you notice it a month later when LCP is already 5s.

Application errors. Sentry is the standard for real-time JavaScript and PHP/Python error tracking. Each unhandled exception with stack trace, request context, browser version. Especially important for errors users don't report — they just leave.

Database. Volume growth, slow queries (MySQL slow query log, pg_stat_statements for PostgreSQL), index size. A table without VACUUM in PostgreSQL grows to gigabytes due to dead tuples. Routine database maintenance is part of support.

Disk space and logs. Is logrotate configured? /var/log/nginx growing without limits and filling the disk — classic. Automatic rotation + alert at disk > 80%.

Why Are Backups Without Verification an Illusion?

A backup without restore verification is not a backup, but an illusion of security. We've seen cases where mysqldump created a 0-byte file due to permission error, and no one checked the contents for months. We guarantee all copies are restorable.

Backup scheme:

• Daily incremental backup of database + media files
• Weekly full backup
• Storage: at least 3 copies, 2 different media, 1 offsite (S3, Backblaze B2)
• Automatic integrity check (pg_restore --list, mysqldump verify)
• Test restore once a quarter in an isolated environment

Retention policy: 7 daily, 4 weekly, 3 monthly. S3 Lifecycle rules automate deletion.

SLA: What Does It Mean in Practice?

SLA (Service-Level Agreement) Wikipedia — specific commitments for response and resolution times:

SLA makes sense only with monitoring — otherwise you learn about problems from users, not systems. A broken button in a form can silently kill conversions for weeks.

Content Update Process

A developer should not be in the chain for editing text on a page. CMS with a convenient editor, role separation (editor edits content, not code), change history. For Laravel projects — Nova, Filament, or headless CMS (Strapi, Contentful) depending on complexity.

Preview before publishing, staged rollout for important changes. If editors work directly on prod — that's a risk.

Typical Situations We Resolve

Website hack: attack vector analysis, cleanup, security hardening (WAF, fail2ban, file permission restrictions). Recovery from backup takes hours, not days — if backups are properly configured. Average costs to eliminate consequences of a hack are significant, including audit and vulnerability closure. Regular support is much cheaper and prevents such incidents.

Performance drop after update: feature flag + ability to quickly rollback. Canary deployment — update 5% of traffic, check metrics, then 100%.

What's Included in the Support Package (Deliverables)

Upon signing the contract, you receive:

• Documentation: infrastructure diagram, access, recovery procedures
• Monitoring: uptime, performance, errors, logs — set up from day one
• Backup: daily/weekly copies with verification
• Dependency updates: monthly audit and update with testing
• SLA response: per priorities from the table above
• Reports: weekly dashboards, monthly review, quarterly tech plan
• Content editing support: editor training, permission setup

Contact us to choose a suitable plan and get an initial audit of your project.

How We Work: Stages

1. Onboarding (3–5 days): audit of current state, setup of monitoring and backups, infrastructure documentation.
2. Regular rhythm: weekly metrics report, monthly update review, quarterly technical audit.
3. Response: per SLA, with recording of cause and resolution time.
4. Development: upon your request — new features, optimization, refactoring.

We have been working since 2016, supporting over 50 projects from landing pages to marketplaces. Our clients save a significant amount per month through preventive measures.

Timelines and Cost

Setting up monitoring and backups: 3–5 days. Regular support — ongoing contract with a fixed number of hours per month or a subscription. Cost is calculated individually after audit. Get a consultation — we will evaluate your project in 1–2 days.

Comparison: Monitoring with Automatic Alerting vs Manual Checking

Automatic monitoring with Better Uptime responds to failures 10 times faster than manual checking.