Textpattern: a PHP CMS that treats content as text, not as pages

The problem: content that is not a page

Most content management systems store an article as a row in a table with a title, a body, a slug and a set of category identifiers, and the page is assembled from those fields. That model is comfortable for publishing and awkward for everything else, and it is the source of the two problems Textpattern was written to solve.

The first is re-purposing. A press release, a product description and a news item are the same shape of text with a different wrapper, and in a row based system each needs its own template or its own field set. The second is the authoring experience, because a writer in a rich text editor is a mouse user, and a writer in a text editor with a few tags is a keyboard user, and the two habits produce different writing.

Textpattern is a flexible, fast and easy-to-use content management system written in PHP, and the way it answers both problems is the same move: the content is text, marked up with a small set of tags, and the templates decide what that text becomes. An article can be a long piece, a section index or a page without being edited differently, because the distinction lives in the template rather than in the record.

The audience is a writer or a small team who wants a CMS they can actually shape, on their own hosting, without a page builder and without a service. It is a system with a long history, a dedicated support forum and a small core team, and the website is textpattern.com with the documentation and the community in one place.

The licence is GPL-2.0, the language is PHP, the default branch is dev, and the last push was on 2026-10-19, with releases 4.9.1 from 2026-02-14, 4.9.0 from 2025-12-21 and 4.9.0-beta.2 from 2025-03-14.

The installation shape, and the archive that decides your features

Textpattern is installed to a web server with PHP and MySQL, and the documentation asks you to make sure the server meets or exceeds the system requirements before you continue.

The download table is worth a look because of a detail that is easy to miss. The current production release is version 4.9.1, and it is published in .zip, .tar.gz and .tar.xz varieties from both textpattern.com and GitHub. But if you want to use the multi-site functionality in Textpattern, you should get the .tar.gz or the .tar.xz archive.

That is an unusual packaging decision, because the .zip is the format most people reach for first, and it is the one that will not give them a feature the system promises. The reason is almost certainly the permission bits and symbolic links that a .zip archive cannot carry, which is the kind of detail that gets discovered by an administrator rather than by the developer writing the installer.

The rest of the installation and upgrade documentation is kept in the repository as plain text files, README.txt and UPGRADE.txt, and the repository also has HISTORY.txt, which is the changelog across versions, and a CUSTOM-FIELDS-README.txt that documents the custom field system the text format relies on.

The directory layout is conventional for a PHP application of this vintage and size: index.php at the root, a textpattern/ directory holding the application, themes/ for the templates, files/ and images/ for uploaded content, sites/ for the multi-site data, rpc/ for the remote procedure call interface, css.php and a .htaccess for the rewriting and the asset serving, and composer.json with a lock file for the dependency set.

The front end dependencies, vendored rather than composed

The package.json is small and revealing, because it is not a build system for the application but a manifest for the browser assets that get copied into the tree.

The runtime dependencies are the JavaScript the templates load: blueimp-file-upload for uploads, dompurify for sanitising HTML, jquery at 4.0.0 with jquery-migrate and jquery-ui, and prismjs for syntax highlighting. The development dependencies are eslint, phplint and uglify-js, which are the three tools the scripts use.

The scripts show the pattern. There is an eslint script that runs the textpattern JavaScript and then exits zero regardless, which tells you the JavaScript linting is advisory rather than a build gate. There is a phplint script that lints the PHP files, excluding node_modules. And then there are copy tasks, one for the blueimp upload library and one for DOMPurify, which minify a file from node_modules and write it into textpattern/vendors/.

That last pattern is the interesting design choice. The browser libraries are not loaded from a CDN and they are not bundled at deploy time either; they are copied, and in the case of DOMPurify, minified, into a vendors directory inside the application, which the templates then reference. The result is a checkout that runs with no network access and no package manager in production, at the cost of a vendored copy of each library that has to be refreshed deliberately when it is upgraded.

The version numbers also tell you something about the maintenance. jQuery is at 4.0.0, with jquery-migrate 4.0.2 alongside it, and prismjs at 1.30.0, so the front end dependencies are current rather than abandoned.

Textpattern 5 and the move to vendor supported versions

The development branch is working towards Textpattern 5 as the next major release, and the documentation spends more space on the anticipated system requirements than on features, which tells you what the release is mostly about.

The guidance is that, as a development version approaches release, minimum and recommended system requirements are confirmed and the production release system requirements are updated accordingly. The table that lists the anticipated changes takes into account vendor support, security considerations, overall performance and other factors, and the documentation warns that the minimum or recommended versions listed may change multiple times during the development process.

For Textpattern 5 the table is a set of recommendations rather than numbers. The minimum column is empty for every row, and the recommended column says vendor supported for PHP, vendor supported LTS for MySQL, vendor supported for Apache, and mainline or stable for Nginx. The project states that it generally recommends running Textpattern on platforms with active vendor support where possible, though it also maintains a minimum system requirements list for situations where that is not viable.

So the direction is clear. The 4.9 line runs on whatever your host provides, and the 5 line will require versions that are still receiving security fixes, with the old ones retired. For an administrator, that is a migration to schedule rather than a surprise to absorb, and the documentation gives you the runway to do it, as long as you read it before the version lands.

The development snapshot itself is obtained from the Textpattern repository on GitHub, and the contributing documentation and the additional development tools document are both in the repository, the latter as DEVTOOLS.md.

Community, support and the sponsorship that pays for it

Textpattern is a community project in a way that is visible in the repository. The support forum at forum.textpattern.com is described as home to a friendly and helpful community of users and experts, and the project also has a presence on Mastodon and on X.

The financial side is spelled out in the README, and it is specific. The project is grateful to DigitalOcean for web hosting infrastructure, to BrowserStack for a cross-browser testing platform, and to 1Password for secure password management, alongside the GitHub Sponsors programme and a Crowdin project for the text packs used for localisation.

That list is a good description of what running a mature open source web application actually costs. The hosting for the demonstration and documentation sites, the browser matrix for a CMS whose output has to work in whatever the reader has, and a password manager for the people running the releases. None of it is exotic, which is the point.

There is also a small piece of infrastructure aimed at other developers, which is the topic tag list. The project asks that if you use GitHub for Textpattern related development, you add the textpattern topic, and it suggests the more specific variants: textpattern-plugin, textpattern-theme, textpattern-website for sites built with Textpattern, and textpattern-development for development resources. It is a small thing, and it is the kind of small thing that makes a niche ecosystem findable.

The contribution path is documented too, with CONTRIBUTING.md for the development workflow and a code of conduct in the repository.

The licence, and where Textpattern is the wrong tool

The licensing is more layered than the single badge suggests. The project is released under the GNU General Public License, with the terms in LICENSE.txt. It includes contributions licensed under the GNU Lesser General Public License, with those terms in LICENSE-LESSER.txt, and it includes contributions licensed under the New BSD License, with those terms in LICENSE-BSD-3.txt.

The practical reading is that the core is copyleft, and the bundled or contributed components carry their own terms. For a team that intends to modify Textpattern and host it, the GNU General Public License on the core is the obligation that matters, and the LGPL and BSD-3 parts are there so that the mix of libraries the project has accumulated does not force one licence on everything.

As for when Textpattern is the wrong choice, the honest answer has three parts. If you need a large plugin ecosystem and a marketplace, this is a small project with a loyal following rather than a platform, and you will be writing your own code. If your hosting is limited to an old PHP or MySQL, the 5 line will not run there and the 4.9 line is a dead end. And if your content is fundamentally structured, a catalogue with filters and facets or a documentation set with a hierarchy, a document oriented system or a static site generator will serve you better than a text based CMS that renders through templates.

What Textpattern is for is a writer who wants to publish text with structure, on their own server, with templates they control and a system small enough to read. Judged on that, the trade it offers is unusual: the smallest possible content model, and a surprising amount of control over the output.

Editorial conclusion

Adopt Textpattern if you write in PHP, you want a CMS that stores articles as text with custom fields rather than as rows in a page table, and you are comfortable running your own hosting. Do not adopt it if you want a large plugin and theme ecosystem, or if your hosting provider only offers PHP versions the project is about to drop. Before you install, read the system requirements and the UPGRADE.txt file for the version you are moving to, and check the archive format you download, because the multi-site functionality is only present in the .tar.gz and .tar.xz archives and not in the .zip one.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. textpattern/textpattern on GitHub