What is Textpattern CMS, and why should I use it?

Target audience

This article is aimed at web authors, designers, and administrators who don’t know much if anything about dynamic web publishing in general or Textpattern in particular. You should know enough about HTML and CSS to be able to work directly in those languages. It’s possible to get into dynamic web publishing without that knowledge, by sticking to an off-the-shelf system and theme, but that is not this article’s focus.

If you are already familiar with CMS concepts and are evaluating Textpattern, you may still find the Textpattern characteristics section useful.

Static vs. dynamic websites

A traditional website, what I will call a static website, is basically a folder of HTML files on a web server. Viewing pages in the site involves reading those files into a web browser, each page’s URI matching an actual file path. The page may also include CSS, images, videos, and other files, which can reside inside or outside the site. Maintaining the site involves editing the various files and uploading them to the server via FTP.

A dynamic website is an application on a web server. When a browser requests a page the application spins into gear and assembles it by pulling components from a data store. A page URI isn’t a request for a file; it’s more of a recipe telling the web application what to mix into the page. To the browser, and to the user, the page is indistinguishable from static HTML. Maintaining the site typically involves visiting a protected section of the site and editing and issuing commands through a web browser. This kind of application is called a Content Management System, CMS for short.

Why use a CMS?

In one sense maintaining a static site is very easy. The direct binding of HTML file to web page is conceptually obvious and makes it easy to know exactly what file to edit when you want to change something. With CMS-driven sites, where pages are assembled from scattered parts, it is not always so easy to find things. And because many parts appear on more than one page, editing to change one page can have unintended consequences elsewhere.

Static publishing workflow

Static site maintenance is not without its challenges—surely I am not the only one ever to have gotten lost amidst a group of windows all titled “index.html”—and becomes ever more awkward as the site grows. Need to make a change that affects every page on the site? While this can be made manageable with multi-file find and replace, mistakes can be disastrous if you don’t catch them in time.

Scripting languages such as server side includes can also help a lot, allowing you to separate common elements into their own files. This is, of course, a kind of dynamic publishing, pages assembled on the fly by the web server. Conceptually, though, it is still on the static model: each page corresponds to an actual file on the web server, as does each included element.

If this sounds like a distinction without a difference, here’s a concrete example of how a truly dynamic site is fundamentally different. You are the publisher of a news website, a static site. One of your freelancers sends you a sports story, so you open a new HTML file based on your sports article template, convert the story to HTML and paste it in, then upload the file. No one will know the file is online until you post links to it, so you also have to update the sports index page and the home page, and perhaps an archive page. Posting a new article already involves editing four different files. You also might want to cross-link between your new article and existing articles, and now the complexity multiplies.

CMS workflow

The process is much simpler on a CMS-based site. Log in, navigate to the content editing section, and paste in your new article. You’ll probably format the article in a WYSIWYG editor or by using a simplified markup language that gets automatically converted to HTML. The title and an excerpt go into separate input fields, and you select appropriate categories and other metadata from drop-down menus. Click the save button and you’re done. The site’s home page, sports index, and article archive are instantly updated with a link to the new article. The article is cross-linked with other articles in the same category. Maybe there’s also a page showing all articles by this author—that got updated too. As soon as you save the article, all of this happens automatically.

This is not just a matter of saving time and effort, although that is important, and can make for a much higher quality website. Automatic linking between pages practically eliminates broken internal links. And the ease of adding articles frees publishers to focus on content rather than technical chores. It also allows authors with no technical web training to directly post and edit articles.

But more important still is the benefit to site visitors that comes from intelligently inter-linked content. This is the heart of dynamic publishing, the fundamental conceptual difference from static publishing.

Not every website needs a CMS

The rosy picture I just painted is true: it really is that easy to add articles to a well-crafted CMS site. But I am guilty of rhetorical sleight-of-hand in glossing over what that “well-crafted” entails. Any website benefits from advance planning and design work, as to which static and dynamic sites are much the same. But there’s an extra dimension to the planning of a CMS site, and extra work setting it up. There’s also an extra tool to learn.

Static sites tend to be easy to manage at first, becoming less so over time. CMS sites trade extra pain up front for greater benefits down the line. Static sites do not scale well. CMS sites scale beautifully. This is true both for workload on the back end, and user experience on the front end. But a small and simple website may never get to the point where a CMS pays dividends.

Is a CMS right for my needs?

Consider your website needs from both sides: visitor experience (front end) and ease of administration (back end). We’ll assume you have an existing static site and are considering making it dynamic. On the front end, are you getting your visitors the content they want? Can they find their way around? Would they benefit from better cross-content linking or search, or would that be gilding the lily?

On the back end, what is the misery index? How often do you find yourself putting off chores because they’re too much of a hassle? Would it make a difference to the quality of the content if things were easier for you? Or is it all pretty manageable?

What about collaboration? Would you benefit from allowing non-technical authors direct but limited access to post their own articles, without risk of messing up other parts of the site? Do you have an existing admin team? If so, are they open to the idea of a change? Or are you a solo operation, intending to stay that way?

If you can’t point to a compelling need in at least one of these areas, stick to static.

Is Textpattern right for my needs?

Textpattern is an excellent CMS, but it is not the right tool for every job.

Technical requirements

Textpattern’s technical requirements are pretty easy to meet. Indeed, if you can’t run Textpattern on your server you are probably dealing with a setup so crippled that your CMS options will be severely limited.

Live and local servers

With static web development it is smart to make and preview changes locally or on a development server before “going live” with them. This is equally true of dynamic sites, but while you can preview static pages in a design tool such as Dreamweaver or by opening HTML files directly in a browser, to preview a CMS-based site you need a full-blown web server. This is easier than it might sound; there are pre-packaged component stacks available for every OS flavor, and Mac and Linux come with built-in web servers. And your development site doesn’t have to be local—you could set up a password-protected copy of your site on the live server. But a local copy is great to have, especially if you are working solo.

Database administration

Textpattern uses MySQL as its data store. You don’t have to know much about databases to run a Textpattern site, but backing up the site or moving changes between live and development servers does require basic database operations. This can be done from the command line if you are so inclined, through the ubiquitous web-based phpMyAdmin, or through a desktop tool such as the excellent (and free) Sequel Pro for the Mac. At the very least you (or your website administrator) need to be able to import and export individual tables and the full database. This isn’t difficult, but it is an extra step—extra because you still need FTP for certain files.

Textpattern characteristics

This is (necessarily) a superficial look at Textpattern: there’s no substitute for trying it out yourself. It’s not (mainly) a “features and limitations” list, owing to my view that “features” can be liabilities, while constraints can be empowering. It’s a “warts and all” view: I think Textpattern is an excellent system for many site types, but it isn’t one-size-fits-all (no CMS is), and it certainly has its quirks.

Free and open source

I’m not an open-source evangelist, so to me this is simply a characteristic, with good and bad points. Textpattern has never been a major player in the CMS world and its community is on the small side. But Textpattern is well established, with an active support forum and development team, and users from around the world.

Core & plugins

The core application aims to be lean and mean. The admin interface is quite simple, hence easy to navigate and use. By avoiding bloat the developers can stay focused on security and performance, so both are good—pages render fast, and vulnerabilities are not an issue if you take reasonable precautions.

Extra features can be added through Textpattern’s excellent plugin system. Plugins are easy to install, and you can configure your site with the exact features you need.

The drawback of the lean-core-plus-plugins philosophy is that most Textpattern sites do rely on plugins, and most of these come from independent developers. It is very much caveat emptor: some of the more complex plugins occasionally conflict with each other, and a plugin could introduce a security hole. In practice the system works well, because most plugins are very simple.

Templating system

Page templates are a mix of normal XHTML markup and Textpattern tags. Their familiar XHTML-like syntax eases the transition from traditional web design, and makes for an elegant templating language. The tag builder feature allows quick creation of some of the more common tags.

Templating is divided between page templates and forms. Textpattern forms are simply reusable template chunks, some of which act as mini-templates for certain content types. It is a versatile and powerful system, but is conceptually more complex than straight page templates.

Language support

On the admin side, Textpattern’s localization is excellent. There are about 40 languages available, out of the box. Multi-lingual publishing is another story. There are methods using core components, and there is the MLP Pack extension. If this is a key feature for you, check carefully.

Limited theming support

There’s good support for admin-side themes, but if you want your site visitors to be able to reformat the site to suit their whims, look elsewhere. Why you’d want to do that I don’t know, but it’s your website.

If you want to start from a pre-packaged design, options exist but can be fussy to install. Out of the box, Textpattern is the Model T of CMSs — you can have any design you want, so long as it’s the default.

Textile

Textile, the “Humane Web Text Generator”, is a simplified markup language at the core of Textpattern’s article publishing. You’d better like using it if you’re going to use Textpattern, because it’s baked in. You can turn it off, selectively or completely, and you can modify your installation to use a different language or even a WYSIWYG editor, but I suggest sticking to Textile. I find it an elegant language that lets me focus on writing rather than markup, and I love using it.

Bells & whistles

Syndication (i.e., news feeds—the little “XML” or “RSS” links you see on many sites) couldn’t be easier. Just slap a <txp:feed_link /> tag into your page template, the rest is automatic.

Setting up a search feature is also easy and works well, although the core search algorithm is pretty simple.

Site structure

Textpattern is best suited to sites with a fairly flat overall structure. Sites are divided into sections, and there is no native support for subsections, so if you need an elaborate site hierarchy you will have to work around the system rather than with it. Many other CMSs have the same issue, but some do have native subsection support.

This may seem like a crippling limitation, but it gets to the heart of how a CMS differs from a static site: it’s all about creating a network of inter-linked content rather than a strict hierarchy. Don’t reject Textpattern on this basis without taking a serious look at the benefits of this kind of structure.

Content model

Textpattern’s content model is based around a few strictly defined content types. This is good in that many websites fit comfortably within this scheme, making it quick and easy to get up and running. Less good in that it is difficult to bend the scheme to fit a different content model. The article reigns supreme among content types, and much of the work of designing a Textpattern site involves manipulating article lists. Custom field support for expanding the article type is basic but workable for most purposes.

The other content types—images, links, files, and comments—are pretty much set in stone. None of these has native custom field support, nor is there a generic, fully-customizable content type in Textpattern.

A frequent refrain on the forums is, “It’s a CMS, not a blog!” There is not a little defensiveness in this claim. Textpattern:

• started life as a blogging engine,
• came of age when blogging was all the rage,
• still works very well as a blogging engine,
• looks suspiciously bloggy on a brand-new installation.

To me this is not an important distinction, but then I don’t have a strict definition of “blog”, which is where the defensiveness comes from. My point is that Textpattern’s origins as a blogging engine are a good clue to its current content model.

Community portals

Textpattern is not a natural candidate for a community portal site. There are some ambitious plugins that aim to fill this need, and it can certainly be done, but this is far from plug-and-play.

E-Commerce

As with community-portal features, this will be plugin based. Options exist, but check them out carefully if this is a key feature that needs to be tightly integrated into your site. Bear in mind that with any CMS, e-commerce is really a separate web application, even if it is packaged as a plugin. The same could be said of community portal features.

Documentation

Typical of a free, open-source application, Textpattern’s documentation is good in some places, spotty in others. The online tag reference is excellent, and Textpattern CMS User Documentation, the documentation Wiki, is overall a strong effort. Tutorials are hit or miss. Textpattern also has built-in help, although some of the entries are blank.

Making the evaluation

For most web publishers the transition from static to dynamic publishing involves a steep learning curve of general concepts along with the specifics of the chosen CMS. If you’ve decided to take the plunge, and if you are going to be doing the work yourself, make sure you have a solid chunk of time to devote to this initial phase.

It’s helpful to look at existing sites based on the systems you’re considering. Just remember not to be overly influenced by visual site design—you can apply any design to any CMS. (This is easier with some CMSs than with others, though, and in Textpattern it is certainly easy.) Look at information architecture, functionality, and usability instead. http://welovetxp.com/ is a good portfolio of Textpattern sites.

“Small to medium” aptly describes several aspects of Textpattern. It has a lightweight code base and simple admin interface, although there are other CMSs that are smaller and simpler still. It is well suited to websites in the small-to-medium range of size and complexity, and a typical site development cycle is pretty quick for an experienced user. Sites are easily administered by a single publisher, or with more complex workflows using a team of contributors with varying levels of access. Its user base is not large, but there is an active support community and development team.

Posted 2009-09-28 (last modified 2011-01-06)