tgreenaway.com

When you are interacting with WordPress’s Query Posts function the codex page gives great examples.

However, the one glaring omission is documentation on how to handle variables with spaces. For example you might want to query for posts with the tag “Converse”, this is easily achievable with:

# the query terms are not case sensitive, so converse==ConVERsE==Converse

query_posts('showposts=1&tag=converse');

But what if you wanted to query for a tag that contained spaces in it, like “Onitsuka Tiger”? Unfortunately none of the examples on the WordPress page currently provide an answer and giving the query_posts function spaces doesn’t result in anything. And while you might assume urlencode or rawurlencode might be the answer – they’re not.

The answer is that the spaces must be replaced with hyphens:

$manufacturer_tag=str_replace(' ', '-', $manufacturer_name);

query_posts('showposts=1&tag=' . $manufacturer_tag);

Apart from that omission the WordPress codex is still undeniably one of the greatest examples of an OSource API.

After debugging an Ajax Internet Explorer issue for about 3 hours today at work wherein what should’ve been some simple JSON data being returned by a jQuery $.post call the server instead returned the website’s main splash page.

I eventually discovered the problem was also clearing the user’s checkout basket. Upon realising that I discovered the user’s session was dematerialising on the server-side as well.

A few google’s later I found this post on the Magento forum (finally their forum is useful):

http://www.magentocommerce.com/boards/viewthread/27475/

So basically there are options in Magento’s admin backend that cause disruptions in IE for sessions and result in user’s losing their entire session.

In my case it was disrupting Ajax calls all the time. Why have the Magento developers made a buggy set of options the default for the admin panel when the bug affects the most common browser in existence?

Those options do sound great in terms of security but until they’re stable and tested they shouldn’t be made the default.

I use the following plugin for the highlighted code on this blog:

http://wordpress.org/extend/plugins/syntaxhighlighter/

However, I found code was never indented properly. After rummaging around and reading a few other blogs it seems the answer is to wrap your Syntax Highlighting tags with the HTML ‘pre’ tags.

In my case that is like so:

<pre>[/sourcecode]</pre>

Here’s a basic jQuery sorting plugin for generic parent child relationships I wrote.

Wherein ‘element’ is the html you wish to insert and ‘value’ is what the associated weight of the element I’m inserting. For now it compares the weight value to the DOM text within the other children.

$.fn.insertSort = function(element, value) {
  selector = this;
  if ($(selector).length > 0) {
    $(selector).attr("inserted", "false");
    $(selector).children().each(function() {
      if (parseInt($(this).text()) > parseInt(value)) {
        $(this).before(element);
        $(selector).attr("inserted", "true");
        return false;
      }
    });
    if ($(selector).attr("inserted") == "false") {
      $(selector).append(element);
    }
  } else {
    $(selector).append(element);
  }
  $(selector).removeAttr("inserted");
};

It should be noted that this is an insertion sort. It’d be good to extend the plugin to be able to sort an existing piece of html for any parent/child relationship. Possibly with the ability to specify a particular level of depth?

Once and a while you may want to get a collection of the regions that are associated with a country in Magento. For example, the United States is of course a collection of… states. In Magento these are referred to as regions (Japan’s prefectures would hence be referred to as regions as well.)

So for a given country (and that country’s ID or country code) you might want to find all the regions in that country. Which are usually used to populate a dropdown menu on the address selection pages or shipping tax pages.

$collection = Mage::getModel('directory/region')->getResourceCollection()
->addCountryFilter($this->getCountryId())
->load();

It’s great when ORM works for a developer. The problem with Magento I find is the complete lack of documentation. I only discovered the above technique after 20 minutes of grepping the app/code/core directory…

And remember to use Magento’s log method:

foreach($collection as $region) {

Mage::log(print_r($region, true));

}

Note some of the more useful attributes of that $region object are:

• $region->default_name
• $region->code

Which give responses along the lines of South Australia and SA, respectively.