Z-BlogPHP: a long-running PHP CMS built for the Chinese web

What Z-BlogPHP is, and the audience its history points to

The README describes Z-BlogPHP as an open source website building program provided by the Z-Blog community, and states that the first version was released in 2005, giving the project a 21-year history. That date is the most important fact on the page, because it separates this from the flood of CMS projects that appeared and vanished around 2015 and never had a maintenance story at all.

The project states its audience directly: it has always been dedicated to giving users in China an excellent experience, and it is one of the few open source CMS systems in the country that still receive regular updates. That is a narrow claim and an honest one. It tells you the design assumptions were made for Chinese hosting conventions and for a Chinese-language publishing workflow, not that the software is unusable elsewhere.

The stated goal is to free users from tedious settings, and the range of sites listed is wide: personal blogs and corporate websites, knowledge bases, news portals and community forums. The plugin and theme model is what makes that range plausible, since the core program can stay small while the specialised cases are handled by extensions.

For developers the README promises powerful customizability, a rich set of plugin interfaces and theme templates, and for users it claims simplicity, small size, speed and the ability to handle large amounts of data. Whether the last claim holds for your dataset is worth testing with your own content rather than taking on trust.

The requirement matrix: PHP versions, four databases, many web servers

The requirements section is short and specific, which is a good sign for a project that has been deployed a long time.

On the runtime, the listed range is PHP 7 and 8.0 through 8.4. The odd thing about that list is what it excludes: PHP 5 is gone and PHP 8.5 is not mentioned. Supporting five PHP major lines at once is unusual work for a volunteer project, and it means the code is written to run on versions that differ considerably in session handling, argument parsing and type strictness.

On the database, the list covers MySQL 5 and later, MariaDB 10 and later, SQLite 3 and PostgreSQL. The presence of SQLite is the one that matters most for self-hosting, because it removes the separate database server from the picture entirely and turns a two-service deployment into a single process. The topics listed for the repository name MySQL, PostgreSQL and SQLite as separate concerns, which fits a project that treats each backend as a first-class target rather than an afterthought.

On the web server, the list runs from IIS and Apache through nginx, Lighttpd, Kangle, Tengine and Caddy. That spread is a genuine feature for shared hosting in China, where Kangle and Tengine are common and where the operator often cannot choose. It also means the plugin interfaces have to work behind several different request-handling models, which is part of why the plugin surface is described as rich rather than minimal.

Operating systems are described as Windows, Linux, macOS and so on, which in practice means anywhere PHP runs.

Installing through the browser wizard, step by step

Installation is a web wizard rather than a command line process, and the README lays out the order plainly.

First, the directory permissions. The site directory needs 755 permissions, which matters more on a Windows server than on Linux and matters even more when the web server runs as a different user than the one who uploaded the files.

Then the files go into the site directory and the wizard opens in the browser:

http://your-website/

The wizard handles the database next, and it branches by backend. For MySQL you enter the account and password from the hosting provider. For SQLite you confirm the server supports it, and the installer creates the database file itself after you click Next. For PostgreSQL you supply the host, database name, account and password.

The last steps are the administrator account and password, which the README asks you to make strong, and then clicking Next. Once the installation succeeds you can enter the site.

There is one cleanup step that people skip and should not. After installation you delete the zb_install folder, and if you deployed a development version from GitHub you also delete the standards, tests, utils and similar folders:

zb_install
standards
tests
utils

Leaving the installer behind on a live site means leaving a setup wizard reachable, which is exactly the kind of thing you do not want exposed. The README also explains the deployment order for development builds: download the stable release, install that first, then overwrite the files with the ones from GitHub. That avoids running the wizard against a half-configured tree.

Repository layout: what zb_system, zb_users and zb_install each own

The top level of the repository shows a PHP application with several distinctly named directories, and the names describe the deployment rather than the source code.

The entry points are the classic PHP set: index.php, feed.php and search.php at the root, with composer.json and composer.lock for dependency management and a .php-cs-fixer.dist.php for formatting. There is a standards/ directory holding the project's coding standards, and tests/ and utils/ directories that the installation notes tell you to remove from a deployed copy.

zb_system/ is the part that makes this a CMS rather than a set of scripts: it holds the program itself, the theme and plugin interfaces, and the administration layer. zb_users/ holds per-site data and uploaded content, which is the directory your backup plan has to cover. zb_install/ is the installer that the wizard runs from, and the one you delete afterwards.

The split between zb_system and zb_users is the single most useful thing to understand before operating the software. It is the classic separation between code and content, and it is why the upgrade path in the README can be as simple as overwriting the program files: your content lives in the other directory and is not touched by the upgrade.

The release naming follows the same kind of pattern. The tags are things like v1.8.0.4020, described as Martis Beta, and v1.7.5.3550, described as Optimus Beta, so the codename names the branch and the trailing digits carry a build counter. When you report a bug, which branch you are on is the first thing you will be asked.

Extending it: plugin interfaces, theme templates and coding standards

The developer-facing half of the project is the plugin and theme layer, and the repository gives some shape to it.

The README promises a rich set of plugin interfaces, and the presence of a coding standards directory, a php-cs-fixer configuration and composer dependency locking tells you the project expects third-party code to be merged or at least reviewed. There is a developer documentation site at docs.zblogcn.com and a developer community forum at bbs.zblogcn.com, and the README routes functional bugs to either the forum or a GitHub issue while welcoming pull requests.

Theme templates are the other extension surface. A theme is what determines how a site looks, and Z-BlogPHP's theme model is traditional: templates rather than a component tree, so a theme author writes template markup and a plugin author registers behaviour through interfaces. That is a dated model compared with a component-based front end, and it is also why the program stays small, since presentation lives outside the core.

One thing the README handles carefully is security disclosure. Rather than describing a policy, it points at a SECURITY.md file and says that for supported versions, reporting channels, acceptance criteria and the full disclosure process are described there, with an explicit request not to discuss vulnerability details in public issues. For a CMS that has been running since 2005 and holds administrative credentials, having a written disclosure path in the repository is the part of the security story that matters most, and it is the part that a plugin author needs to know about before filing a bug report.

Limits: an installer-driven deployment, a Chinese documentation set, and betas

Three practical limits are visible in what the README describes.

The first is that installation is a browser wizard against a web server. There is no command line installer in the documentation, no container image and no configuration-as-code path. For a hosted VPS where you can run a web server, that is unremarkable. For a deployment pipeline that builds an image and expects the same artifact everywhere, it is friction you will have to work around, and the requirement to delete the zb_install folder afterwards is exactly the kind of step that a pipeline tends to forget.

The second is the language of the ecosystem. The documentation site and the developer community are Chinese-language, the project targets users in China, and the theme and plugin ecosystem will reflect that. Nothing in the README suggests the interface is localised into English, and a team that cannot read Chinese will be relying on the source and on community translation.

The third is the release channel. The three most recent tags are all described as Beta, two of them on the same day: v1.8.0.4020 (Martis Beta) and v1.7.5.3550 (Optimus Beta) on 2026-09-20, preceded by v1.8.0.4015 (Martis Beta) on 2026-09-17. The last push to the repository was on 2026-10-13, so work is current, but the tags a deployer would pick are beta builds, and two parallel branches are being cut at once. That is normal for an actively developed CMS, and it means pinning a specific tag matters rather than tracking the default branch.

Z-BlogPHP against a hosted platform and against a static site generator

The comparison worth making is not between one PHP CMS and another, but between three different shapes of website.

The first alternative is a hosted platform, where someone else runs the CMS, the updates and the uptime. The difference in approach is operational rather than technical. With Z-BlogPHP you own the server, the PHP version and the database, which means you own patching, TLS renewal, backups and the consequences of a vulnerable plugin you did not install. What you gain is that the data lives in a database you control and the site keeps working if the vendor changes pricing or shuts down.

The second alternative is a static site generator. This is the sharper contrast, because Z-BlogPHP is a database-backed dynamic program while a static build produces files. A static site has no runtime to attack, no PHP version to keep supported and no database to back up, and it can be served from a CDN for a fraction of the hosting cost. What it cannot do is anything that requires a request-time computation: a comment system, a member area, a search index built as you type, an admin panel that a non-technical colleague can use. Z-BlogPHP's plugin architecture exists precisely to make those things possible, and so does its database layer.

The decision follows from who edits the site and how often. If one or two technical people publish occasionally and the content can be written as files, a static site is the simpler system and Z-BlogPHP is more machinery than you need. If content arrives through a browser from people who are not running a build pipeline, and if the site needs to respond to readers, then the dynamic model is the right one and Z-BlogPHP gives you a maintained version of it rather than an empty framework.

Editorial conclusion

Adopt Z-BlogPHP when you need a self-hosted PHP site with plugins, theme templates and a choice of four databases, and when operating your own hosting is acceptable. Do not adopt it if you want a static site with no runtime, or if the Chinese-language documentation and community are a barrier for your team. Verify first that your PHP version falls inside 7 to 8.4, that the web server can write to the site directory with 755 permissions, and that you delete the zb_install folder from the deployed copy before the site goes live.

Frequently asked questions

Official sources

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