Ten Textpattern Tips, #2: Site Production Status

Continuing with my series of Ten Textpattern Tips, today I want to make sure your site status is set correctly. In my previous article, I covered the visitor logs functionality and recommended you turn it off if you’re not using it – the aim of the game there was to keep your database under control size-wise by not filling it with potentially useless information about your visitors. This article is a little different, but still relates to the same database.

When a Textpattern page is viewed, either to a person or a bot, Textpattern queries a database and extracts data from it. This data may include one or more articles, a page template, some CSS, one or more forms, perhaps information about an image or two, and more. The database is where your data is stored, and it’s accessed whenever views are made. The more views you have, the more the database is accessed, and the more work the server your site is housed on has to do.

Textpattern is, by design, light and flexible. A newly-installed Textpattern instance running on a shared Arvixe server treads lightly. Your site status can be set to Live, Testing or Debugging from the Administration -> Preferences area. When it’s set to Testing, which is the default, extra information is included in the rendered page as comments:

This is useful information if you’re testing, fine-tuning or tweaking your Textpattern for speed and performance. If your status is Testing, anything looking at the source code for your pages will be able to spot that you’re running Textpattern. If you’re happy to advertise this fact, then you need do nothing – but each visitor is also downloading these four lines on each page view, and Textpattern is doing extra work to generate these 4 lines. Most people aren’t interested in website source code, so when you’re done testing, switch to Live mode.

Another useful benefit to Testing mode is that Textpattern errors will be thrown up at the top of the rendered page, before the page content. Useful for testing, useful for debugging, but really ugly for end users – so, make sure that when you’re ready for the site to go live, switch to Live mode. If you’re involved in a heavy-duty, ground-up design on Textpattern it’s tempting to enable Debugging mode as you build so you can have considerably more visibility of what’s going on. When Debugging mode is enabled, your code is rendered to the browser, along with any Textpattern errors at before your content and the 4 lines relating to runtime, queries and memory usage – in addition to this, there’s a whole extra section of text inserted into your browser source code known as a tag trace. This tag trace follows your Textpattern tags and evaluates them, then displays information relating to the query or queries it just undertook. Still with me? It looks something like this (excerpt for brevity):

Notice the first 4 lines. They are similar in format to the 4 lines in Testing mode, but the runtime and query time has increased. Also, the memory use has crept up. The default Textpattern installation outputs around 10,000 characters of source code when viewing the front page – enabling Debugging mode bulks this up to around 16,500 characters, an increase of around two thirds.

Moral of the story today: when you’re ready to go live, choose Live site status. If you’re already live, check that you’re set to Live site status and make the experience for your users as pleasant as you can.

Author Spotlight

Pete Cooper

Pete Cooper has been using Textpattern since 2005. Textpattern is his preferred CMS weapon of choice. Its logical and flexible approach to content management makes Pete happy, as does its lightweight core and helpful user community. Pete's website - petecooper.org - runs on top of Textpattern and chronicles his day-to-day experiences from his home near the Atlantic in north Cornwall, United Kingdom.