Things To Consider When Using WordPress as a CMS (via: Matt)

I’ve been looking for a half-decent content management system for some time, as until now I’ve been writing my own code for each site that I run. This is a real pain, as I never have the time to write an admin interface — and therefore end up using phpMyAdmin — and I’m not as good as designing interfaces as other people. However, I have thought several times about using WordPress as a content management system — even though it started as a blogging platform — which is why the above article is particularly of interest to me.

Reasons why I would consider using WordPress as a CMS:

•  Spam protection: Akismet is by far the most effective anti-spam solution I’ve come across, it probably performs better on blog comments than SpamAssassin does on my email. Sure, there are plugins available for several other systems, but with WordPress the support is practically built-in. Yes, it is technically a plugin, but it comes shipped with the distribution, so there’s one less step to mess around with.
• Familiarity: I use WordPress on several other blogs, so I’m comfortable with the interface and the way the software does things. In a similar vein, readers of my sites/blogs are also more likely to be familiar with the commenting interface for WordPress than for other content management systems
• Theme availability: WordPress seems to have more themes available for it than any other blog or content management system I’ve seen. You can download thousands of free themes, pay less than $100 for an off-the-shelf professionally designed theme, or cough up for a designer to create a unique theme especially for your site — there are plenty of companies and individuals around who offer this service. What’s more, WordPress themes can make your site look unique — one of my major bugbears with Drupal is that all of the themes tend to look like Drupal sites.
• Plugins: Like themes, there are thousands of plugins available, enabling pretty much anything you could possibly want to do with WordPress — from formatting posts with Textile to cross-posting to other sites (e.g. LiveJournal) automatically. I’m not aware of any other system with the same variety of plugins (though Drupal probably comes a close second), and I suspect this is largely due to the ease of creating and installing plugins for WordPress.

1. Select information from database.
2. Assign information to Smarty template.
3. Parse Smarty template to produce a string of HTML.
4. Create a dompdf object with the HTML string as its input.
5. Generate the PDF and save the file to disk.
6. Exit the function.

I erroneously assumed that PHP would perform some garbage collection when exiting the function (i.e. when the object fell out of scope), thus freeing up the memory used by the dompdf object. Unfortunately, PHP didn’t do this, resulting in the script using more and more memory each time I called the function, which eventually broke through the limit set for individual PHP scripts and so execution was halted. As the PDF files differed in size, I couldn’t guarantee when this problem would happen and allow for it.

In order to get round the memory use problem, I tried using the unset function to free up the memory used by the dompdf object. However, unset merely removes the reference to an object, and does not force the garbage collector to free up the memory immediately. As a result, the memory barrier was still being broken at an undetermined point.

Finally, I came across a somewhat forceful but successful method of getting around the problem. Instead of putting the PDF generation code in a function, I moved it into a separate PHP file and then executed this file within my main script using the exec function like so:

exec('/usr/bin/php /path/to/GeneratePDF.php');

Instead of using 16MB for each function call and not freeing the memory, therefore using 160MB for 10 calls, PHP freed up all the memory used by the separate script when it finished executing, so at any one point there was never more than 16MB in total being used. I benchmarked both methods (function calls and exec) by trying to create a number of PDF files, and the results were quite impressive: using the function calls took over 60 seconds and several of the files failed, using exec took 30-40 seconds and every file was generated successfully.

Normally I would not recommend using functions which execute external programs, due to the security implications involved. However, in this case no user-supplied data is passed to exec, and the huge improvement in speed and memory use makes it a no-brainer for this particular example.

Further information

• Batch processing slows down PDF generation — mailing list thread on Google Groups.
• Garbage collection

1. A sensible layout system which would automatically put elements in the correct place — I don’t want to have to manually specify where the text should begin on the page, align each paragraph, trigger a new page etc.
2. The ability to transform HTML into PDF, so that I can use Smarty to produce the PDF files as well as the Web pages.
3. Support for as much CSS as possible.
4. Active mailing list or other method of getting help from the community.
5. Software under active development, i.e. not one of these Sourceforge projects which were started in 2005 and haven’t been updated since.
6. Uses a licence which enables the library to be integrated with closed-source software (e.g. BSD or LGPL).

There are several HTML to PDF tools out there, but most of them are not up to the task. HTMLDOC looks promising at first, until you realise that it only supports part of HTML 4 and doesn’t support CSS at all — at least not according to the FAQ. ReportLab also raised my hopes, despite being written in Python (which I’m not familiar with), but a markup language is only available with the commercial version. HTML 2 PDF didn’t even get off the drawing board by the looks of things, and hasn’t been updated since 2005. Finally I came across dompdf, which seems to fit the bill with the following features:

1. Supports conversion from HTML to PDF.
2. Support for a large chunk of CSS (imperfect but improving).
3. Active mailing list, which includes the developers of the software.
4. Licensed under the LGPL.

Using dompdf at its most basic is a doddle, you simply pass the HTML in as a parameter to the load_html function and choose whether you wish to stream the result to the browser or output to a file. The bare minimum code is shown below:

$html = $template->fetch('template.tpl');
$filename = '/path/to/file.pdf';

$dompdf = new DOMPDF();
$dompdf->load_html($html);
$dompdf->set_paper('a4', 'portrait');
$dompdf->render();
file_put_contents($filename, $dompdf->output());

Assuming $smarty is a reference to an existing Smarty template, this will create a PDF which should look more or less the same as the Web page generated by $smarty->display('template.tpl'). There are other options which allow you greater control over the final PDF, such as altering the page size, loading extra fonts etc., but the above code will produce a working PDF which you can email or print. The size of the PDF is also extremely small — the invoices which I have working on come in at around 2-3KB each.

Things to watch out for include:

1. File permissions — as you’re saving files to disk the Web server user (www-data if you’re running Apache on Debian) will need write access to the relevant directory.
2. Databases — do not store the files in a database. By all means store the meta data, such as filename, last modified time etc., in a database (I do this for ease of management), but don’t store the file itself. I’ll write another post at a later date detailing why storing files in a database is a bad idea.
3. Unicode — unfortunately dompdf doesn’t have full Unicode support yet, so if you want to create documents with this character set you will have to wait a while. I believe it’s possible to make dompdf work with Unicode by using the commercial version of pdflib, but I haven’t tried that myself.

dompdf isn’t perfect of course, it takes a long time to generate PDF files with tables, some CSS rules don’t work and ordered lists are currently unsupported. However, it is under active development, and there have been performance improvements in recent versions. At the moment I have to generate PDFs as part of a cron job instead of on the fly, and employ a bit of a hack to get round memory usage problems, but I expect those problems to gradually diminish over time. Even with these minor blemishes, dompdf is still the best library I’ve found for converting HTML to PDF in PHP.

I encountered this issue on a project I was working on, and after many attempts using trial and error I found that you need to send the following headers before the file is downloaded:

Cache-control: private
Content-Type: application/pdf
Pragma: public

I don’t think the order matters, but the sequence above works for me and I haven’t tried moving the headers around. Of course, you should replace application/pdf with the content type for whatever file you are sending to the browser.

This fix does not affect other browsers, which all seem to download the file perfectly well without the headers, nor does it break downloads on non-SSL sites. I don’t know why it works, but I’m posting it online in the hope that other people who are encountering the same problem won’t have to waste half a day trying to fix it.

The primary reason for building the site was to scratch my own itch. Over the past few years, I’ve been a director of five different companies, each of which has two filing dates (accounts and return) to remember. Whilst I could just enter the dates in my diary each year, I wanted an automated service which would nag me by email until the documents were filed.

The site is completely free to use and you can subscribe to as many companies as you want. At some point in the future I may charge for premium services, or include a sponsor link in the emails, but the basic email service will remain free.

In terms of the technical details, Filing Reminders is written in PHP, uses MySQL for data storage and my UKCD class to fetch the company data.

For anyone interested in the technical details, Curry Gateway is written in PHP and uses MySQL for the data storage.

Cookie: cookiename=cookievalue

When requesting the main PHP page this is a necessary header, because PHP uses it to populate the $_COOKIE array, which is in turn used to check whether a user is logged in to the site. However, with any other files, such as stylesheets and images, this header is ignored, unless you want to ensure that images are only available to authenticated users (you could do this by redirecting any image file requests to a script which only serves the image if the user is logged in).

It might not seem like a big deal, but if we assume that the length of the header is 50 characters, each character is one byte, and we have ten static elements on a page, that’s 500 bytes of unnecessary traffic. In fact, s6.1 of RFC 6265 suggests that browsers should support cookies at least 4096 bytes in length, so in theory you could be unnecessarily transferring four kilobytes with each request for a static file, especially if you use several cookies. This quickly adds up if your users are on slow or unreliable connections, such as dial-up or wireless links.

A simple way to get around this problem is by placing all static files on a different subdomain (e.g. static.example.org), or a completely separate domain (e.g. www.example.net). Both options involve a penalty of an additional DNS lookup when the first page is accessed, and have slightly different effects.

With a separate subdomain, the Cookie header will still be sent if the domain of the cookie is set to .example.org (note the leading ‘.’), as this defines the cookie as being valid across all subdomains of example.org. This might be the case if you have different subdomains for parts of your site, such as forum.example.org, admin.example.org etc.

With a completely different domain, the Cookie header will not be sent, but you do have to incur the cost of registering and managing another domain.

As well as the Cookie header overhead, some proxies may fail to cache images correctly because the Cookie header suggests there is some state associated with the files, even though HTTP is supposed to be a stateless protocol.

So, if you have a lot of static files loaded for each page on a domain which uses cookies, it may be worthwhile running some benchmarks to see how much additional data you are transferring as a result, and whether the overhead of an additional DNS lookup is an acceptable trade off.