Why Textpattern? An Interview with the Authors of Textpattern Solutions
Published on July 2, 2007
Digital Web: Web developers have many options these days when choosing a CMS or blogging engine. Why has Textpattern become your preferred solution?
Nathan Smith: In 2004, I initially chose Textpattern because of its templating syntax. I used to be one of the webmasters at a small graduate school, where we simply updated thousands of HTML pages by hand. This is all well and good for a site with mostly static content, but I yearned for a better way to build sites for freelance clients. One of the most frequent questions I heard was, “How do I update my site?” The answer, “Learn HTML,” was not sufficient, so I started looking for different CMS options. At the time, WordPress did not natively support multiple site sections, and Movable Type’s licensing was becoming ever more restrictive.
Since I already had experience writing my own markup and CSS, Textpattern immediately appealed to me because it did not get in my way. Some of the other open source systems out there presuppose that you want a columnar layout, lock you into templates built using tables, or revolve around pre-packaged themes. I like that the templates in Textpattern are based on a tag system that closely resembles XML, and implicitly, XHTML. It gets out of my way, and allows me to get things done. It reflects the old adage, Software should be smart, not clever. Textpattern gives you the tools to build a site, but doesn’t coddle you with superfluous automated features.
The ubiquitous availability of PHP in just about every hosting environment is also a big plus—you’ll know that Textpattern will be compatible nearly everywhere, and it has a small foot/files/includes/print.css when it comes to system resources and speed.
Kevin Potts: Textpattern stands apart from many other CMSes in many ways. First and foremost, it is a designer’s CMS—there are no server-side development skills (such as PHP or MySQL) needed to build complex and fully functional websites. If a designer is fluent in CSS and HTML, it is a simple matter of employing Textpattern’s friendly, natural-language tags to build a complete website. (Of course, for the adventurous, the system does completely support custom PHP development.)
That simplicity and elegance also appeals to clients. Having rolled out Textpattern-driven sites for a number of clients, many of them remark about its ease of use. They also love its free license.
Beyond that, the Textpattern community is great. There are many active developers working on the core system, and new plugins are being constantly released.
Rob Sable: When I first found Textpattern and installed an early gamma release, I was immediately comfortable working with it. The logical separation of content from presentation made it easy to understand how to begin building sites. As I come from a development rather than design background, within a few days of installing Textpattern, I was tinkering with the plugin framework and extending Textpattern where I needed. That flexibility is one of the biggest reasons I continue to use Textpattern.
I think the design and implementation of Textpattern is much cleaner than other CMSes out there. The tag-based templating is very intuitive and easier for non-developers to deal with, compared to other applications that have a mix of PHP code and HTML.
DW: What are the limitations of Textpattern? Are there certain types of sites or situations where you wouldn’t recommend using it?
NS: I would not recommend Textpattern for hobbyists who just want a simple blog and do not know how to write HTML/CSS (unless of course, you want the /files/includes/default.css look and feel—then, be my guest). That being said, if someone is simply editing content with Textpattern after the site has been created by a designer/developer, then using the system is a breeze. Textile is easy to learn, and there is a cheat-sheet built into the interface in case you forget the syntax.
The Textpattern site says it best: “A free, flexible, elegant, easy-to-use content management system for all kinds of websites, even weblogs.” Note here that powering a weblog is only one of its capabilities. There is a slight learning curve to Textpattern, so the aspiring developer should be willing to put in the time necessary in order to become familiar with the system. However, the learning curve is not as steep as a full-blown application framework such as Django, where a great deal of customization is required.
Unlike some systems, Textpattern does not try to be the all-encompassing solution to every possible need. For instance, it does not have a forum as part of its core focus (though, there is a plugin for that). This is not necessarily a drawback, in my opinion, because I tend to like single-function products—I do not own a camera-phone. For forums, the best option available, by far (again, in my opinion) is PunBB by Rickard Andersson. It is open source, and shares the same spirit of Textpattern—make a product that does something really well, rather than spreading it too thin by trying to do everything.
RS: From my perspective, there are very few limitations if you’re willing to pound out some plugin code. There are also hundreds of plugins out there already that enhance Textpattern’s basic capabilities. If you’re not up for relying on plugin authors or your own coding skills, Textpattern is still perfectly suited for anyone wishing to publish content online, whether it’s a personal site, corporate site, online publication, etc.
DW: I started building sites with one of the early releases of Textpattern, and have kept up pretty well with the software and community since then. What does your book, Textpattern Solutions, have to offer an old hand at Textpattern like me?
KP: Textpattern is a deep program. The flexibility is amazing. Because of this, there are always newer, more efficient ways of doing things, and tips and tricks that other users have discovered that may save you tremendous effort in your own installations. This book is riddled with them. Every time I open it up, I learn something new.
Also, the book delves into some more complex issues that are beyond what’s normally found in the forums. Rob’s chapter on creating plugins is a perfect example. For site builders, there’s information on creating custom error pages, adding unique metadata to articles, e-commerce solutions, and more.
RS: Even as an old hand myself, the day after I received my copies of the book in the mail, I actually re-read the chapter on comments as I was updating a site. I’ve built dozens of sites using Textpattern, and I still find new ways of doing things; the wealth of experience that this group of authors brings should be helpful to any Textpattern user. With nearly five hundred pages of explanations and examples, there is no doubt that the book would benefit any level of user. If nothing else, the tag, global variable, and helper function references come in handy for even the most advanced users.
DW: Lately, there has been talk of a lack of a development roadmap and uncertain future for Textpattern. What are your thoughts on this?
Mary Fredborg: In a nutshell, a roadmap is primarily for the developers—a kind of list of what needs to be done, how it should be done, and when. The problem with such documents being made available to the general public is that very often people think that if something appears on the roadmap, it is a guarantee. On the contrary, some things will invariably be dropped from the list for one reason or another, such as time constraints or unforeseen difficulties. This is especially true for open-source projects where everything gets worked on in each developer’s spare time. When this happens, users feel very disappointed, and often cheated or mislead, because they were counting upon said feature or fix being there by the previously appointed time. The Textpattern developers have simply chosen a different route.
As for the casual contributor, a roadmap doesn’t tell him what he can actually work on. If that’s the sort of thing you want to know, the answer is very simple: decide on something specific that you want to actually work on, and then approach us. We’ll be able to tell you whether it can happen now or at all, and what you can actually do about it. Just ask, and we’ll tell you what you need to know. A roadmap simply can’t contain an answer to every conceivable question or concern, regardless of how much one would like it to.
That is not to say we never let people in on where we’re headed. Far from it. The majority of the time, we make note of changes and plans in our Subversion (SVN) repository log: what we’ve changed and why, and often, what this means for the future. For those interested in what specific tag changes and additions are coming, there’s a page in the Textpattern WIKI dedicated to listing these for people who don’t want to follow the Subversion log. For items of general interest, we usually make an announcement on our weblog or mention it on the forum in the appropriate place (such as Feature Ideas, for example). And for those who are interested in what the overall goals are, we tell anyone who expresses interest. For the current major version (4.0.x), it is long-term stability—bug fixes but no sweeping feature changes or additions. For the next major version (4.1.x), it will be a complete overhaul of the CMS. This can already be seen, right now, in SVN. It will still be Textpattern, but it’ll be even better.
NS: While I think there is some validity over the concern that a project has/lacks a roadmap, I do not necessarily think it makes for better software. For instance, ExpressionEngine, one of the premier commercial content management systems on the market, does not make use of a roadmap, by the admission of company CEO Rick Ellis. Drupal is a quality open source CMS that has an informal roadmap, which is not set in stone.
To me, the real question is not, “Is there a roadmap?” It is rather, “Is the CMS a quality product?” Absence of a publicized roadmap is not necessarily indicative of stagnation in development. One need only check the Textpattern development timeline as proof of constant iteration. There was also a recent announcement about bundling jQuery with Textpattern in an upcoming version (4.0.5). Incremental improvements, with a focus on quality and security—rather than feature-bloat—are what make Textpattern appealing to me.
It is not unlike the children’s story of The Tortoise and The Hare—a focused, steady pace wins the race. Such an approach does not appeal to people who crave bells and whistles, but is music to the ears of picky designers and developers. One of the topics that creeps up from time to time on the Textpattern forum is that of trackbacks, which are often abused by spammers. This has never been a core focus of Textpattern, and anytime I happen upon such a thread, I always weigh in and discourage it. Such functionality is available as a plugin, but I would rather not see Textpattern become the tool of choice for spammers by including trackbacks in the core build. There are plenty of other systems available for that.
RS: Again, my perspective has always been that I could extend Textpattern with a plugin if I needed to, rather than wait for someone else to add a feature. While some people would feel more comfortable with a detailed roadmap for Textpattern, some of those same people would endlessly debate when and why features were being added. Textpattern is a flexible, simple, and free platform for publishing on the web, and always will be. That is all the roadmap I’ve ever needed.
DW: Can you point out some sites that are using Textpattern in advanced or unexpected ways?
NS: One of my favorite Textpattern-powered sites is Cobalt Engineering. Terry Evans of Vibe9Design did Cobalt’s site. For a vast listing of beautifully designed sites that use Textpattern, check out the all sites gallery at TXP Magazine.
RS: The book contains three case studies which explore the Textpattern implementations of three different types of sites, including Popular Wedding Favors, an e-commerce site. And Nathan already mentioned the TXP Magazine listing of sites, which includes lots of great examples.
Robert Sable has over ten years of experience designing and developing web-based applications for small businesses up to Fortune 50 companies. From its early gamma releases, Rob recognized the power and flexibility of Textpattern. He has published over 20 Textpattern plugins and numerous tutorials on his website at wilshire|one.
Nathan Smith is a goofy guy who enjoys practicing and preaching web standards. He works as a UX Developer at Fellowship Tech. He writes semi-regularly at SonSpring and Godbit. He has been described by family and friends as mildly amusing, but is really quite dull.
Mary Fredborg is a freelance web developer, who spends much of her time working on and providing support for the Textpattern content management system. She resides in southern Alberta, Canada.
Kevin Potts has been working on the web for almost ten years, having started his career designing his first employer’s website with Netscape and Notepad. He has spent the bulk of his design career working in-house as both a graphic designer and internal web developer. Coupled with years of freelance and agency work, Kevin has created dozens of websites for businesses of all sizes in an array of industries. He blogs at graphicPUSH.com.
Andrea Schwandt-Arbogast is a web designer living in Eureka, California. Her day job is Web Manager of Humboldt State University, where she attempts to bring web standards to the university as an army of one. In her spare time she blogs about web standards, university web development, and life at Interllectual.com, runs a community project called Jangly Ganglia, and is the editor-in-chief of Bite Size Standards. She had a previous career as a biologist and is overly fond of margaritas.