Archive for the ‘Code’ Category

IIS Fails with Multiple Referers, but not Referrers

August 24th, 2009

This is something I came across today when we launched a new section for a website. It’s something I’ve never encountered before, and I ended up spending most of my afternoon debugging what was causing our issue. Let me begin by saying the correct spelling of Referrer does have two r’s, however it is misspelled in the HTTP Specification. To the end user, this should mean nothing as most software that uses the HTTP Spec uses the incorrect spelling, as it’s what was defined in the spec.

When we launched the site, we checked it out in all our normal browsers and everything was good. Then we fired up IE 6 (unfortunately the client in question needs IE 6 support), navigated to the new secti-OH CRAP! The page itself would load, but none of the external assets (images, stylesheets and scripts) were loading. Refresh the page and bingo! it works fine! What the heck is going on?!

It turns out IE 6 was sending not one, but two referers to the web server. While it’s odd to have 2 referers, it shouldn’t cause 4xx Errors when sending a request. From this, we were able to find out a few things:

  1. IIS accepts both Referer and Referrer as valid HTTP headers.
  2. IIS will not accept more than one Referer.
  3. IIS will accept more than one Referrer (note this is the dictionary spelling of referrer, not the spec spelling).
  4. IE 6 will add 2 referrers if the link you clicked is located inside of a Flash element for all external assets: the URI to the Flash file and the URI of the page you are on.

Read more »

Show Only Children Pages on Parent Page

August 3rd, 2009

There is still much to be desired within WordPress when it comes to dealing with parent and children pages. The core code is there, and it’s usable, but there’s not a lot “out of the box” to play with.

We’ve developed a bit of code to help make your life a little easier.

Adding the code below to your functions.php file will let you remove the other children pages while on the parent page.

add_filter('wp_list_pages_excludes', 'remove_others_children');
function remove_others_children($excludes = array()) {
  $all_pages = get_pages();
  $all_children = (array) get_page_children(true, $all_pages);
  foreach ( $all_children as $child )
    $excludes[] = $child->ID;

  if ( ! is_page() )
    return $excludes;

  global $post;

  $this_heirarchy = (array) $post->ancestors;
  $this_children = (array) get_page_children($post->ID, $all_pages);
  foreach ( $this_heirarchy as $ancestor )
    $this_children = array_merge($this_children, (array) get_page_children($ancestor, $all_pages));

  foreach ($this_children as $child)
    $this_heirarchy[] = $child->ID;

  return array_diff($excludes, $this_heirarchy);
}

Here are some examples of what it would like without the code, then with the code.

WordPress:  Remove Children Pages from Parent Pages

A huge thanks goes out to Matt Martz for working with us on helping get this code ready.

The Power of XSL

February 22nd, 2008

When we did the last rewrite of Christian Lyrics I spent a good bit of time working on the template system. I loathe Smarty due to how bloated it is, but almost went with it because needed modular caching (guests all see the same static files, logged in users see their user info, etc…). We ended up using a Savant style system (no stupid custom tags, no parsing, just PHP) that works pretty well, but has some short comings still. After we finished the rewrite, I spent some time exploring other options. Only one caught my eye: XSL.

The eXtensible Stylesheet Language (XSL) is a family of transformation languages which allows one to describe how files encoded in the XML standard are to be formatted or transformed. XSL is designed to be data driven and strongly encourages the Inversion of control design pattern. There are three languages in the family:

  1. XSL Transformations (XSLT): an XML language for transforming XML documents
  2. XSL Formatting Objects (XSL-FO): an XML language for specifying the visual formatting of an XML document
  3. the XML Path Language (XPath): a non-XML language used by XSLT, and also available for use in non-XSLT contexts, for addressing the parts of an XML document.

Source: Wikipedia

In a nutshell, XSL can be used to transform a plain XML document into a full-fledged HTML document. One thing I really like about XSL is that the processing can be done either server-side or client-side. Most modern browsers understand XSL and do all the dirty work for you, leaving your server to do other, more important, things. Not only that, but if you send the XML to the client for processing, then you have the base of your API already done.

But the best part is how modular you can make the caching. Here’s how I do it:

  1. If the data is cacheable it gets saved to disk in an XML file. Queries are only done to the SQL server for this data if the cache file doesn’t exist or has expired.
  2. If it’s not cacheable, insert it into the cached XML document on the fly.

Then the XSL document handles the rest. I can’t think of any simpler way to do it.

However, there are downsides (when aren’t there?):

  • IE has notoriously bad support for XSL (of course).
  • PHP has XSL support natively in PHP5, but PHP4 requires a PECL library (I can’t find the extension on PECL for some reason).
  • More syntax to remember
  • The only good documentation I’ve come across is the specification itself. W3Schools, which usually has a pretty decent overview, I found lacking.
  • Most variable processing has to be done before you transform the XML. It is possible to use variables in the XSL itself, but it is very limited.
  • Javascript does not work on the XML document itself, just the generated source. This means if you use AJAX to grab eg. a list of languages, you have to either do the transformation server-side or in the Javascript itself. Thankfully, Google has an excellent Javascript library to do XSL transformations! Some browsers (Mozilla is one I believe) also have built-in XSLT support in Javascript.
  • Unless you do the transformation on the server-side search engine crawlers will not be able to index your site. Of course you could set it up to only transform server-side if a crawler comes.

Now I ask: why don’t more sites use XSL? I know I’ll be building most of my sites in the future with XSL, the benefits far outweigh the downsides in my opinion.

Update: I completely forgot to mention a very important downside. I bolded it in the list.