MonthFebruary 2007

Changing ISP

I’m thinking about changing my ISP. Hurricane Electric worked fine so far, but I started to care about some things that are simply impossible with this ISP.

  • pros: per month contract, no setup fees, no hidden costs, reselling allowed
  • cons: only one database per account, subdomains not allowed, no PHP 5, no Ruby, very basic admin interface

I thought that could be a good alternative, but I’m not sure anymore, after carefully reading their site. The price announced is the classic “starting from” which I hate: it refers to the 24 months prepaid contract. For any contract less than 12 months there is a 30 dollars setup fee. And the minimum contract is 3 months. They give you lots of space, but reselling is not allowed. An interesting feature is that they allow adult content, as long as it is legal in California. has the same pricing structure, even if they say “no hidden costs”. Besides they charge 10 dollars for each domain… They don’t allow any adult content, nor nudity, nor anything related. An interesting feature is that you have to edit lingerie pictures if you can see through!

How to write a safe RegExp for Opera

The PHP recipe for Chili contains a big regular expression (32862 chars) to account for the thousands of PHP functions.

Internet Explorer and Firefox accept such a giant, but Opera does not. No way. It’s a problem at the core level. So the only solution, very simple though, is not to use a literal expression: use new RegExp( "..." ); instead of /.../.

Remember to escape the expression for strings: for my recipe it was very simple because the step only contains a long list of words, between two word boundaries, which need an extra backslash.

Chili 1.7 Released Today

UPDATE: Chili 1.8 has been released


  • Fixed Internet Explorer copy functionality
    you can now copy source code in PRE elements transparently and seamlessly in IE, Firefox and Opera (try to copy some lines from any PRE in the examples below)
  • Fixed the PHP recipe for Opera


  • 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

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.

HTML entities resolved
HTML stripped off
result copied
HTML entities resolved
BR elements replaced by new lines
HTML stripped off
result copied
HEAD element copied
containment path elements copied
selected text with HTML in place copied
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

© 2017 Notes Log

Theme by Anders NorenUp ↑