This affected IE6, IE7 and IE8 in my testing. The way I was serving the file was through PHP via readfile. Before sending the contents of the file, I was, of course, setting some header parameters so that the browser would handle the file and the user wouldn’t just see some binary garbage on their screen. In my case, I was serving a PDF file that was being generated server-side and sent to the client. The basic header parameters are as follows:

// We'll be outputting a PDF
header('Content-type: application/pdf');
// It will be called your_file.pdf
header('Content-Disposition: attachment; filename="your_file.pdf"');
// declare Files Size here (for the sake of peoples sanity, please add this
header('Content-Length: '.filesize($filename));

This works just fine in most situations, but once you introduce a secure connection, IE fails with the above error. Of course, like most IE problems, this doesn’t happen in any other browser. Ugh.

Luckily, I noticed some additional parameters in the first example on the readfile page, namely the ‘Pragma’ parameter. Reading some comments on the header function, I stumbled upon this one. It basically, says that once you add HTTPS, you need to also tell IE how to handle caching the file. So now, my headers look like this:

// Force clear cache
header('Pragma: public'); // Fix for IE
header("Expires: 0"); //always expire
header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
// We'll be outputting a PDF
header('Content-type: application/pdf');
// It will be called your_file.pdf
header('Content-Disposition: attachment; filename="your_file.pdf"');
// declare Files Size here (for the sake pf peoples sanity, please add this
header('Content-Length: '.filesize($filename));

Directly following these header calls is the readfile call and a call to exit to stop the script from executing anything else and alert the browser that the entire file has been delivered.

It seems like the Pragma parameter controls how browsers handle caching, and adding the other cache parameters to the header are just added enforcement. Now, IE works exactly as expected and I’ve got happy clients once again!

generate.php

This script is where the user is sent when they click “download” on the parameter choice page. This is where the asynchronous magic has to happen. From here, the user is immediately sent to download.php.

download.php

This script gives the user either a “please wait” message of a “click here to download” message, depending on where the target PDF has been generated yet.

My problem was, even though was added the header redirect code (shown below) to generate.php, the browser would still wait for the PDF to be generated before sending the user to download.php. In other words, it was only synchronous PHP, which didn’t help me at all.

header("Location: download.php");

Thanks to this comment on php.net, I was able to make it work! Basically, you need to tell the browser that you are done sending it data, even though the PHP script will keep executing. Code below:

//redirects the browser to the new url, but continues processing in the background
function redirect_and_continue($sURL) {
header( "Location: ".$sURL );
ob_end_clean();
header("Connection: close");
ignore_user_abort();
ob_start();
header("Content-Length: 0");
ob_end_flush();
flush();
session_write_close();
}

So, the user is sent to generate.php, which immediately calls redirect_and_continue(‘download.php’), redirecting the user to download.php while still continuing to execute generate.php (and make the PDF file). Once the user is at download.php, the script checks for the existence of the generated PDF file (as indicated by the filename sent through the session) and uses a meta refresh tag in the HTML to keep reloading download.php. Once the PDF file exists, it provides the user with a link to the PDF file for download.

Granted, I could easily replace WordPress for the sake of my blog here (and probably still will at some point), but that’s not why I was planning to learn it. I wanted something that would allow me to crank out new pages quickly without constantly restarting from scratch. I do have a very weak framework I’ve written to try to achieve this, but every time I start a new site, I feel compelled to re-do at least part of it, so in the end I don’t save any time. In fact, I lose time because I have to re-learn the changes I made for each site when I need to maintain them.

A while back, I started looking into frameworks to use at work. I’m still enthralled with Symfony, but it’s way too hard to just jump in to. In order to take advantage of all of its niceties, there’s a lot you need to learn. It’s almost like learning a new language on its own, which is fine and all, but it doesn’t help me get things done quickly. It’s hard to be motivated to learn new frameworks and techniques unless you have something to work on, and any new projects I have need to be done in a timely manner, so I can’t take too long to jump into something new.

Anyway, one other framework that stood out when I we were doing our research was CodeIgniter. Not because it’s better, but because it has more of an a-la-carte mentality. Don’t want to use the full MVC design pattern? No problem, just use the parts you want to; you can use it as a simple controller mechanism only if you so choose. Don’t feel like getting into a full ORM? Skip it, they have a built-in ActiveRecord style interpreter, which means you don’t need to create your own class for each table in your database. Of course, ou can write your queries completely by hand if you choose to too. Best of all, no command line magic to make your code work, and on top of it all, the entire framework is 3.3MB with the user guide included, under 2MB without it.

I’ve spent a couple nights reading through the documentation (which is pretty well done) and I already have a good understanding of how it all works. And, since it’s almost Christmas again, it’s time to get my annual list manager online again. So, I’ve got a new tool to play with and a simple project to do it with. As a result, Drupal’s on hold while I work on that. I’ll report back on how it goes.

I’ve spent some time reading about Symfony, which looks like an amazing project. I’m positive I can make it do anything I would need, but the learning curve is pretty steep and I’m worried that the time I’d take to learn it wouldn’t really pay off in the end. I like a lot of the concepts, but I’m just not completely sold on it.

So what does that have to do with WordPress? Well, I’ve recently revisited a project that I spent some time with in the past but never really did much with. That project is Drupal.

While it’s not nearly as flexible as Symfony is, it seems like a very useful platform for putting a site together. I followed a quick tutorial last week that outlined just how easy it was, and after reading through their Getting Started guide, I’m pretty sure it can be bent into anything I might need. To me honest, most of the sites I’ve put together didn’t really need much of anything.

But, again, how does this relate to WordPress? Well, I’ve grown tired of WordPress, and it seems like Drupal would make for a great blogging tool. I have no doubt that I could add a lot more than a simple blog should I choose to as well, which makes it that much more appealing. From what I’ve seen, it also runs significantly faster than WordPress does, which is always a nice perk.

So, in an effort to spend more time using and learning Drupal, I’m planning to port all of my WordPress posts to Drupal and use it exclusively to run this site. Worst case scenario, I end up with nothing more than a blog running on Drupal. That’s not too different that the blog I have running on WordPress now, so that’s not too bad of a worst case. Look for the change to happen soon (hopefully this week). You’ll know when it happens as it’s unlikely I’ll spend the time working on a theme just yet, so this site will live in default Drupal mode while I continue my Drupal education. Fun stuff!

The reason I do this is to keep of people out of articles that only privileged users should really be seeing. Articles about server configurations, software development, new ideas for sites, etc. Making a hidden namespace and allowing only specific groups to access it is the simplest way to go about this task.

Doing this is pretty straightforward. I won’t get in to all the specifics though; instead I’ll post links to the exact information you’ll need to pull it off.

User Rights
Custom Namespaces
Group Permissions
Setting permissions for a Group on a whole new Namespace

There you have it, nice and easy! Now I just need to fix/reinstall our personal wiki….