PHP Content Management Systems on the Marketplace Compared: WordPress, Drupal, Joomla and MODX, Matched to Four Kinds of Site

Agencies tend to build every site on the CMS they know best, which is efficient until a brief arrives that the CMS is wrong for. The marketplace has four PHP content systems as one-click packages, and because each lands on the same PHP application server and database with the same scaling, backup and TLS add-ons, the cost of choosing the right one for each brief is nearly zero. This post follows an agency's technical director doing exactly that on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.

The agency, which we will call Bellwether Studio, has four briefs on the table in one quarter. The packages are WordPress, Drupal, Joomla and MODX, each installing the current release on a tuned PHP server (NGINX or Apache with PHP-FPM and OPcache) with a MySQL or MariaDB database, HTTPS on a platform subdomain and Let's Encrypt for the client's domain.

The four systems in a paragraph each

WordPress is the world's most used CMS: theme-driven, plugin-rich, with an editor non-technical clients already know and an ecosystem for anything, at the cost of plugin sprawl and the security discipline it demands. Drupal is a content framework: structured content types, fields, views and a permissions model built for large institutions, with Composer-managed code and configuration in files, and a steeper learning curve. Joomla sits between them: built-in multilingual content and access control levels without plugins, a mature extension directory, and an administrator interface that clients with a bit of training manage well. MODX is the designer's CMS: it imposes no markup of its own, so every tag in the page is the front-end developer's, with content placed where the template says and a lean core extended through its package manager.

Four briefs, four choices

What is identical underneath, and why that matters

All four packages produce the same hosting shape: a PHP application server container and a database container on separate physical hosts, scaling vertically in cloudlets (128 MiB of RAM plus 400 MHz of CPU) by the hour, with the same add-ons available. The director's standard checklist applies regardless of CMS: Let's Encrypt for the client domain, the Database Backup/Restore add-on nightly to the agency's Backup Storage node (or the WordPress-specific one for the hotel), load alerts, and a Redis node when the site's traffic justifies a cache. Staging for every site is a clone of production, created before an update and deleted after. Because the operations are the same, the agency's junior staff can run any of the four sites, and the choice of CMS is made on the brief alone.

That is the point the director makes to colleagues who default to one CMS: on a shared host the choice used to carry hosting consequences (does this host tune PHP for Drupal, does it allow Composer, can it run Joomla's cron), and on the platform it carries none.

Scaling paths differ a little

Each CMS scales the same way to a point: raise the cloudlet ceiling and vertical scaling absorbs traffic; add Redis for the object cache (WordPress, Drupal) or the system cache (Joomla) or MODX's cache handler. Past one node, the platform adds an NGINX balancer when the PHP layer scales to two, and user uploads must be shared: the File Synchronization add-on for modest file sets, a shared storage mount for large ones. WordPress has the extra option of the purpose-built WordPress Cluster package with a replicated database and Redis already wired, which is what the director would reach for if the hotel became a chain.

Migrations into the packages

Three of the four briefs were rebuilds of existing sites on other hosts, and the migration path was the same shape each time: copy files over SFTP, import the database through the platform's built-in database manager, adjust the configuration file's database credentials and paths, regenerate URL rewriting (Joomla's .htaccess, MODX's friendly URL settings), and point the domain last. WordPress additionally offers migration plugins; Joomla has Akeeba Backup archives; Drupal is a Composer project restored from its repository and a dump. Each migration was rehearsed into a clone-sized environment first, and each took an afternoon.

Cost, which did not vary by CMS

The four sites' environments average between 8 and 14 cloudlets an hour each, the Drupal faculty site at the top because of its editors and its Redis node, roughly $20 to $35 a month each before discounts at MassiveGRID's published $0.003372 per cloudlet-hour. The CMS did not move the number; the traffic and the editors did. The director's closing note to the agency: pick the CMS for the client, not for the hosting, because the hosting no longer cares.

Frequently Asked Questions

Which of the four is easiest for a client to edit?

WordPress, by ecosystem and familiarity, with Joomla close behind once configured. Drupal's editing experience is good but its administration is for trained staff. MODX's manager is clean and simple for content editing, since the designer decides exactly which fields exist.

Can Joomla run on several nodes?

Yes, like any PHP application on the platform: scale the PHP layer, let the balancer be added, move sessions to Redis and share uploads with the File Synchronization add-on or a storage mount. Joomla's own cache should be Redis-backed or per node.

Is MODX still actively maintained?

Yes. MODX Revolution has regular releases and an active extras ecosystem; its community is smaller than WordPress's but stable, and its lean core has a correspondingly small attack surface.