gog's info

While launching the Google Adsense on Gameplay and its forum (vBulletin 3.8) we ran into a strange issue while posting quick reply messages to the forum with Firefox. After hitting submit the page turned blank although the comment was apparently posted.

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.

When we switched from Lighttpd to Nginx a couple of months ago we were faced with an annoying problem.

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.

If you have tried using the the TinyMCE spell check plugin on UTF-8 encoded page with the PSpellShell adapter you probably noticed that the implementation is broken. The spelling suggestions do not contain properly encoded UTF-8 characters.

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?