WonderCMS: a flat file CMS that installs by unzipping five files

The whole site is five files and one JSON database

WonderCMS is described as a small flat file CMS, and the size claim is specific: five files, roughly a 50KB zip, one step install. The five files are named in the README. The database is database.js in JSON format, and it is a JavaScript file rather than a JSON file because PHP writes to it as one. The other four are index.php, the theme file theme.php, the stylesheet style.css, and the .htaccess file. That last detail is the one that gives the design its character. There is no database server, no schema, no migration step, and no separate cache to warm, so moving a site to a new host is a copy and paste of all files with no additional configuration or migration work. The content is edited inline in the page, the way a wiki works, rather than through a separate admin screen. For a brochure site, a landing page or a small set of documentation pages, that is the whole product.

One step install, and the server requirements behind it

The install path is the shortest one in this category of project. The README says to unzip and upload the latest version to your server, and that no configuration is needed. There are alternative routes too: cloning from GitHub with git clone https://github.com/WonderCMS/wondercms.git, getting hosting that comes with WonderCMS already installed, using a Docker image, or installing through cPanel with Softaculous. The requirements list is what makes the simple story conditional. You need PHP 7.4 or greater, with the cURL, mbstring and Zip extensions, and the mod_rewrite module, on a server of any type: Apache, NGINX, IIS or Caddy. The README notes that WonderCMS works on most Apache servers and hosts by default, and that NGINX or IIS need one additional setup step, which it links to in the documentation. So the honest version of the pitch is that the install is one step if your host meets the requirements, and the cURL extension in particular is there for a reason, since updates are pulled from GitHub.

Themes and plugins install through an in-browser installer

Extension happens through a theme and plugin installer rather than by editing files by hand, and the mechanism underneath is hooks or listeners. The README lists plugins, themes and a theme and plugin installer and updater among the included features, along with one click updates and one click backups. The distinction between a hook-based system and a database-driven plugin architecture is the one that matters for anyone planning an extension. Plugins hook into the page rendering rather than living in a registry that the CMS queries, so a plugin is PHP that runs at defined points. The documentation links to the hooks section and to the themes section, and there is a separate theme and plugin installer so that adding a theme does not mean uploading files over FTP. The repository layout supports this: a themes directory at the root, with the default sky theme visible through the theme.php and style.css links in the README.

Security design: no tracking, one session cookie, and a hidden login URL

The security section is unusually specific, and one item in it changes how you should deploy. The README lists track free and transparent behaviour with no user tracking and no personal cookies beyond a single session state cookie, and states that an installation is completely detached from the WonderCMS servers, with one click updates pushed through GitHub. HTTPS is supported out of the box, and all CSS and JS libraries include Subresource Integrity tags, so a modified library will not load. Passwords are hashed with PHP's password_hash and verified with password_verify, and CSRF verification tokens are issued for each user action, with hash_equals used to prevent timing attacks on the token comparison. The unusual one is the login URL. WonderCMS encourages you to change the default login URL, and the README frames your custom login URL as your private username, because the login page always returns a 404 response and search engines do not cache it. A good URL, it argues, can prevent brute force attempts. The README also claims no known vulnerabilities, crediting several security researchers by name.

Only three libraries, and only for logged-in admins

The dependency footprint is part of the pitch. The README states that three libraries are located in index.php and are included only when an admin is logged in: wcms-admin.min.js, autosize.min.js at version 4.0.2 and taboverride.min.js at version 4.0.3. A visitor who never logs in receives no JavaScript libraries at all, which keeps the front end small and reduces the attack surface for the public pages. The README also notes that some plugins include other libraries such as jQuery, and that the default installation includes only the three named libraries, loaded through CDNs. The Cdn point pairs with the Subresource Integrity claim, since the integrity hashes only protect you if the served bytes match the hash. The front end also has no cookies, no tracking and no powered by link, which matters for privacy policy pages and for visitors running blockers.

MIT licensed, with a maintenance badge and a thin feature set

The licence is MIT, so commercial use and modification are both straightforward as long as the notice is kept, and the repository has a license file at its root. The repository is not archived and the last push was on 2026-08-25, so the code is being worked on, and the README carries a maintained badge for 2026. The release history shows 3.6.0 on 2025-12-31, 3.5.0 on 2025-03-16 and 3.4.3 on 2023-11-05, so the project has settled into an infrequent update rhythm that matches its stated goal of infrequent-ish one click updates. The feature list is short enough to read in one pass: subpages, inline click and edit, the theme and plugin installer and updater, one click updates, one click backups, and speed. What is absent is what tells you where the boundaries are. There is no user management with roles, no content types beyond pages and subpages, no scheduling, and no media library beyond what a theme or plugin provides. The README does not describe a plugin API in detail, so anyone planning to build on the hooks will need to read the online documentation.

Editorial conclusion

WonderCMS fits a small site, a landing page, a documentation page or an internal site where the owner wants to edit content in the browser without a database and without a build step, and where copying files to a new host is an acceptable migration plan. It does not fit a site needing structured content, per-user roles, a comment workflow or any content type beyond pages and subpages. Verify first that your host meets the stated requirements of PHP 7.4 or greater with cURL, mbstring and Zip plus mod_rewrite, change the default login URL before going live, and read the hook documentation before promising a plugin will do what you need.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. WonderCMS/wondercms on GitHub