Found the Culprit of the Pacman’s Effect

Some time ago I wrote Entity enzyme, or The pacman effect strikes back. It was an article about the pacman effect of the ampersand in WordPress and how to try to solve it with a simple enzyme. Recently I’ve discovered that it’s an escaping / unescaping issue still unresolved in WordPress 2.1, and it’s somewhat nastier than I initially thought.

If you want to write HTML entity codes in a post, and you need to represent that of an ampersand for example (it’s &), then there is no way to get it right. In fact, WordPress will always resolve an entity code.

Thus, if you write &, you’ll get & after the first save roundtrip, and if you try to escape the & into & with &, obtaining & (this looks weird but it’s the way to do it in plain HTML), then the first time you save the post you get & back, and the second time you save the post you get & back.

In general if you write & followed by any number of amp; (like &) then WordPress will make the & eat up an amp; at each saving roundtrip, hence the pacman effect.

But the title of my previous post about this issue was “the pacman effect strikes back.” In fact it’s not only a problem of the post content but also of the custom fields, thus corrupting the last resort we WordPress bloggers have for content AS IS. And this is where I get really upset.

Last tuesday I found the culprit and asked the wp-hackers list wether they considered it a bug or not. I’m still waiting for an answer, so I hope this post will help me to broaden the question and understand if I need to submit it to WordPress Trac or go in for a hack myself.

How to Share Source Code using Chili in IE

I’ve recently realized that copying to the clipboard a snippet highlighted by Chili works differently in Internet Explorer (IE) and in Mozilla Firefox (FF). They both copy two versions of the selected section: TEXT and HTML.

IE TEXT
HTML entities resolved
HTML stripped off
result copied
FF TEXT
HTML entities resolved
BR elements replaced by new lines
HTML stripped off
result copied
IE HTML
HEAD element copied
containment path elements copied
selected text with HTML in place copied
FF HTML
selected text with HTML in place copied

The net result of all this is that IE does the right thing with HTML while FF does the right thing with TEXT, and neither is completely right or wrong.

  • copying from IE to Notepad you get an awful long line, but copying to Word you get all wonderfully colored
  • copying from FF to Notepad you get a properly formatted section, but copying to Word you get all sadly monochromatic

UPDATE (2007/02/24): What follows is obsolete, because I’ve implemented a transparent method in Chili 1.7

In Chili 1.6 I’ve implemented a workaround for IE, so that IE TEXT is like FF TEXT. It’s a workaround because you need to add a button to each highlighted section, and it will copy all the text in that section when clicked.

The button can be as simple as a DIV placed before the PRE, like this:

copy all

alert( "Hello World!" );

Chili will hide any element with a class ie_copy in any browser but IE, where instead it will associate a click handler to it, for copying all the next PRE content as a properly formatted section. You can style the button element as you like, because Chili uses the class only for accessing the element.

You can also place the button wherever you like. If so, i.e. if the button element is not the element preceding the PRE section, then you have to feed Chili the method for getting the PRE content. You can do it globally or locally.

When Chili associates the handler to the button, it will look for a getPRE method inside the button element. If there is one, then it will be used, else Chili will look for a getPRE method inside the global ChiliBook object. If there is one, then it will be used, else Chili will give up and not associate a handler.

You can change the global behavior by changing the declaration of the getPRE method inside the ChiliBook object, and you can change the local behavior by adding a chili metaobject (an object with a class chili) inside the button element, with a getPRE param whose value is the function declaration.

The getPRE function shipped with Chili 1.6 is the following, where the button element is passed into this and the PRE destination is found starting from that origin:

function() { return $( this ).next( "pre" )[0]; }

A button element after the PRE element could then be locally configured like this:


alert( "Hello World!" );
copy all

Chili 1.6 Released Today

UPDATE: Chili 1.7 has been released

Changes

  • Fixed a bug that broke Chili when a code element was empty
  • Added an Internet Explorer workaround for getting the text of a code element with proper white space when copied to the clipboard
  • Improved the clockwork of a dynamic setup: now any given file is loaded once
  • Updated some recipes and added some other
  • Updated the metaobjects plugin to the 1.2 version
  • Added a folder with Enzymes (WordPress Plugin) and its Chili templates
  • Enabled an option for explicitly turning on/off the dynamic loading of recipes

Files

  • download all in a zip
  • read the manual
  • Example: Static Setup, where a set of recipes and stylesheets is loaded at once
  • Example: Dynamic Setup, where Chili loads recipes and stylesheets as needed