You can remove these decorators, as they’re known, but the code ends up being rather unwieldy and repetitive. For each text element you need to add:

$email->removeDecorator('label');
$email->removeDecorator('htmlTag');

Confusingly, buttons have a different decorator:

$submit->removeDecorator('DtDdWrapper');

For a short form, such as the login one used in the book, removing the decorators is a minor irritation, but when it comes to larger forms the process soon becomes a nuisance. Since I use Twitter Bootstrap to provide an initial design framework for most new sites, I wondered if I could configure Zend_Form to produce HTML which would work with the various styles provided by Bootstrap.

Before having a go myself, I figured it was worth quickly searching to see if anyone else had come across the same issue, at which point I found the excellent Bootstrap-Zend-Framework project. All you have to do is add one line to your application.ini file, place the files in your library folder and extend your classes from Twitter_Form instead of Zend_Form. A few minutes later I had beautifully-styled forms and could go back to concentrating on application design rather than fiddling with decorators, HTML and CSS.

The salary isn’t too bad for the voluntary sector – if it was a full-time position it would work out at around £26,000, plus there is a decent (by modern standards) pension contribution. Benefits include flexible hours and a permanent contract, and it appears from the description that this role is not tied to any specific pot of funding which might be withdrawn.

The closing date is 22nd April 2012, so you have just under three weeks to prepare and submit an application.

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.