We have integrated our Adsense code into the postbit vBulletin template after the last post on the page using this syntax:

<if condition="$post['islastshown']">
    Adsense code here.
</if>

The problem happend because Quick Reply uses asynchronous javascript to submit the reply and render the new reply at the and of the page. Since we are embedding the Adsense code if the post is “last shown” this renderd the Google Adsense code twice and FF “broke”.

The fix is quite simple, you just have to check if the post is being sent as a response to the asynchronous request, so the new and working code looks like this:

<if condition="$post['islastshown'] AND !$GLOBALS['vbulletin']->GPC['ajax']">
    Adsense code here.
</if>

Of course this is not the only case which causes vBulletin forum to render a blank page. For a list of other possible reasons take a look at this chapter in the  official documentation.

If you are interested you can also take a look at this exhaustive list of conditionals which you can use in your vBulletin templates.

Paying subscribers to our site have an option of downloading PDF files of the magazine. With Lighttpd we were using mod_secdownload to provide this functionality without exposing the files to the public. We compiled Nginx with the secure_download_module and it kinda worked.

Files were downloading as expected but the file names where all messed up. Download links where generated for each user and they looked something like this: /pdf/645.pdf/097ac16cb19ff6c163d6f813fdd44b4d/4b283bfa and the browser saved the file to the users hard drive with the file name of 4b283bfa. Since the file name didn’t have an extension it was impossible for the OS to know that is has to use a PDF reader to open the file.

Finally we managed to force the file name to the browser (download client) with a configuration directive that looks something like this:

    # PDF download
    location /pdf {
        secure_download on;
        secure_download_secret $request_addr;
        secure_download_path_mode file;
        root /path/to/dir/with/pdfs
 
        # Extract the name of the PDF
        if ($uri ~ "^/pdf/(.+\.pdf)$") {
            set $filename $1;
        }
        # Set appropriate headers
        add_header Content-Disposition "attachment; filename=$filename";
    }

And that’s all there is to it.

Since the creators of TinyMCE moved to Github it was a great opportunity to try and push these changes to the master branch. If you need this you can look at the changes that need to be made to the PSpellShell adapter or just clone my fork of the spellcheck plugin.

p.s. Have I mentioned how awesome Git and Github are?

You can find more info at the devzone.

We hooked a legacy URI “plugin” in our error controller so that checking for old URIs does not interfere with the loading times of our system unless really necessary and created 301 (permanent) redirects to our new URI scheme patted ourselves on the back an forgot all about it until recently.

While checking the access logs for some unusual traffic spikes we where getting we noticed that Google stills checks our old category URIs and follows the redirects that we have created. The most unusual things was that the URIs where checked very often. Links to our news category pages where crawled by Google a couple of times a minute during the course of couple of days. To add to the confusion the categories that are most often crawled our the ones that list articles from our print issue which get updated once a week, the ones that are updated many times a day get crawled at a regular pace.

Any ideas what could cause something like this?

Hudson definitively won me over with its clean interface and easy to setup tasks. Even plugin installation is a breeze and you can even do it right out of the comfort of your browser.

I found a quite nice tutorial about setting up Hudson with PHP here but I had some questions marks hovering over my head during the installation so I have decided to write a more detailed installation tutorial.

If you are running a Debian flavored distribution (yes I mean Ubuntu) take a look at the tutorial, you should have Hudson working with your PHP projects in no time.

Bonus points if you integrate your Hudson installation to act as your staging server.

Open up Terminal.app and enter “sudo su” and enter your password when asked (I guess you must be using an account with administrator privileges).

pear upgrade PEAR
pear channel-discover pear.phpunit.de
pear install –alldeps phpunit/PHPUnit

That’s it. phpunit binary should be in your path now.

p.s.

For some reason phpUnit that is being used by Zend Studios (6.1) does not have mbstring extension compiled and that makes it unusable for me. I guess there is a way to force PHP interpreter that is being used in the Zend Studio to run with the mbstring extension, but this is a faster approach. Hudson or phpUnderControl (whichever you like) will take care of the code coverage reports.

Since a have reinstalled my computer with a fresh copy of Snow Leopard couple of weeks ago I found myself browsing through the System preferences looking for the same option again.

So, as a future reminder for myself you have to press the Ctrl + F7, or open up System Preferences -> Keyboard -> Keyboard Shortcuts and select “All controls” in the bottom of your screen.

Since I do not like to repeat myself I wanted a system that is capable of generating documentation in variety of formats, PDF being the most important one.

DocBook is the first thing that came to mind, but as it is usually the case the things are not so simple as they should be. After playing fore the most part of the day with DocBook and various utilities I decided to write it down for future reference.

I will not contemplate on the DocBook syntax as there are various sources on the internet that will teach you how to use the DocBook syntax for writing. The place that got me started was a blog post by Pádraic Brady. I am using the directory structure he created as well as sample files, with little modifications. Take a look ad DocBook samples he provides.

For starters I do not use any PHP code in my documentation so I do not have the need for Phing tasks that take care of syntax highlighting program listings (yet). Other modifications I made include dropping the DocBook DTD from the manual.xml. That is the line that in his sample starts with “<!DOCTYPE book PUBLIC “-//OASIS//DTD DocBook XML V5.0//EN” …”.

Another thing I needed to add was language information for my <book> so for Croatian language it now looks like this:

<book lang="hr" version="5.0" xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:mml="http://www.w3.org/1998/Math/MathML"
xmlns:html="http://www.w3.org/1999/xhtml"
xmlns:db="http://docbook.org/ns/docbook">

“hr” is a two-letter country code for Croatia. I will explain later why the language attribute is important.

To create a PDF from your DocBook XML files you will need to download:

• Apache FOP
• FOP XML Hyphenation Patterns
• DocBook XSL stylesheets

If you also want to validate the syntax of your XML files you will need the DocBook 5.0 DTD. I will not go into details on validating DocBoox syntax, but it is recommended that you validate your files because I guess it is faster than invoking Apache FOP to generate you PDF and realising that somewhere at the end of your documentation there is a syntax error.

DocBook XSL

After you extract the archive of DocBoox XSL stylesheets you will get a myriad of files and folders. In the “fo” folders you will find XSL documents used for transformation of your XML documents, and the file you will have to pass to Apache FOP is located in “fo/docbook.xsl”.

Files located in the “common” folder contain common terms used in creation of a book based on the language attribute of your book. As a specified that my book is written in Croatian Apache FOP will use “common/hr.xml” to look for terms such as “Table of Content”, “Chapter”, etc. This XML file is the one you want to edit if you want to change the output strings used for creation of the PDF document.

Apache FOP

Since the Apache FOP will probably complain about hyphenation, grab the hyphenation patterns and copy the jar file fop-hyph.jar into the lib directory of the your FOP installation (the place where you have extracted Apache FOP).

Encoding (UTF-8) problems with Apache FOP

There are 14 most used fonts that you can use in your PDF files that do not require you to embedd the font file itself into the PDF. The problems is that these fonts do not have support for all the characters you are probably using if your are converting a document that is not written in English. Accented characters are replaced with hashes if you do not use a font that supports multi-byte characters.

There is an explanation about embedding fonts in the PDF using Apache FOP at their site but this documentation is written for Apache FOP 0.94 and since 0.95 (the current stable release) it is not necessary to create a font metrics file and trying to create one will probably result in an error.

To get the font file embedded into our PDF we need to tell Apache FOP to embed the fonts. Open up the “conf/fop.xconf” file with a text editor and find the part of the configuration file that is enclosed in <renderer mime=”application/pdf”><fonts> … </font></renderer> and insert

<font kerning="yes" embed-url="/Users/gog/Desktop/fop-0.95/times-roman.ttf">
<font-triplet name="Times-Roman" style="normal" weight="normal"/>
<font-triplet name="Times-Roman" style="normal" weight="bold"/>
</font>

Of course you will have to replace the embed-url with the path to Times New Roman.ttf file on your system.

Wrap it all up

And finally to generate the PDF navigate to the folder where you extracted the Apache FOP archive and run:

./fop -c conf/fop.xconf -xml manual.xml -xsl docbook.xsl -param body.font.family Times-Roman -param title.font.family Times-Roman -pdf manual.pdf

In case you are using Windows you probably just need to replace “./fop” at the end of the line with “fop.bat”. Ofcourse you will have to change manual.xml with the full path to your DocBook document and docbook.xsl with the full path to that file located in the DocBook XSL stylesheets inside the “fo” folder.

The important part to notice is that we needed to tell the XML processor to use Times-Roman font for body and title text and that we configured Apache FOP to embed the “Times-Roman” font into the PDF document.

I guess there is a better way to customize the output of your PDF files without using “-param” during the invocation of the FOP. Maybe I’ll come back to it later, for now this works for me.