For all you PHP hackers trying to write a BASH script and looking for an equivalent for PHP’s realpath function, try readlink. It can expand symbolic links and resolve relative paths like “./” and “../”. In a shell script, try this:

MY_PATH=$(readlink -f $0)

Thanks to Barry.

WordPress 2.5 with its new uploader results in a lot more post attachments. Until now, the Stats plugin didn’t keep track of which attachments were viewed. Stats 1.2.1 contains a minor change that lets us show you which of your attachments are most popular.

Remember, attachment views are only counted if you link to the attachment’s Post URL when inserting from the uploader.

A couple of years ago I had an idea: a tagged cache with versioned tags. It works just like an associative array but with an added hidden layer in the cache interface that salts the key with any tags provided and their version numbers. This facilitates classified mass extinctions by the simple act of incrementing a tag version. The entire cache or any tagged subset can be “flushed” in this way. I call it extinction because although the items are dead (irretrievable by a normal read operation) they are not removed and may still be exhumed—Jurassic Park-style—until an expiration or eviction takes them out.

WordPress.com depends largely on memcached clusters so I modified the WordPress memcached client to operate with versioned tags and it did work as planned. It is not operating today because the core changes needed to make the benefits of the new cache outweigh the performance cost never happened. WordPress does use a “cache group” concept and we have used it successfully to create different cache scopes but it does not use a multi-tagging cache and it does not have a mechanism to flush groups of items. However, let’s keep WordPress in mind because the basic data structures of a blog are simple and thus good example fodder.

For one usage example, there could be a “posts” tag indicating that the cached resource derives from data in the posts table and you would increment the “posts” version every time you changed that table. When you ask the cache for items tagged “posts”, it will only find resources that were stored since the last time the “posts” tag was incremented by a flush. Any operation that changes the table’s structure or its contents would trigger a flush of the “posts” tag.

To add another degree of utility, you can apply any number of tags when storing a resource in the cache. Thus if you stored a rendered page, you could tag it with every table queried while generating that resource and rely on tag flushes instead of specifically deleting the item from the cache. For finer-grained control, tags could be specified for individual table rows (e.g. “posts:142″) but the detrimental effects of increased version array size would have to be outweighed by the benefits of excluding the rest of the “posts” items from an extinction.

The central idea behind this scheme is that you should have multiple paths to remove a key or set of keys without knowing which keys are stored in the cache. If your caching substrate has a good eviction scheme this works. If you can reliably determine the generating factors (tables queried, etc.) for every cached resource, you can forget about cache expirations and let the tags do all the work.

There is also the concept of “tag scope”. It is not universally applicable but in WordPress MU, where each blog has its own tables, each blog must also have its own array of tag versions so that extinctions are not unnecessarily applied out of context. There are also certain global keys that never vary between blogs. By specifying the scope of some tags as local to the blog and others as global, and storing global and local versions separately, we can specify whether to increment a tag version on one or all blogs.

Each blog would have a local array version that can be incremented to flush all tags in the local scope, making it easy to clear out one blog’s poisoned cache. A global array version allows us to trigger a universal cache extinction. With many dedicated memcached servers, this would be a neat time-saver.

Metaversions are the cherry on top: a global “metaversion” for any local tag can be stored in local as well as global version arrays. The local metaversion is checked against the global metaversion and if they differ, the local version and the local metaversion are incremented. Thus when the “posts” tag metaversion is incremented in the global array, each local “posts” version will be incremented. This way, we can trigger mass extinctions of any tag across all scopes.

My experimental client did all of this but it increased page generation times by 5-10%. I am still sure that if the software made smart use of cache tags we could have seen great benefits. Unfortunately, with a package as large as WordPress, the time to improve cache utilization would be many times longer than the two weekends I spent hacking the cache client.

Today at the GeekAustin/Dorkbot happy hour I met up with LinearB who said that on the second third Tuesday in May GeekAustin would like to co-host a social event with WordPress. I know Austin has a lot of WordPress users and consultants that don’t typically come out for the social events so I’m putting the word out early. How about it?

at the top of the main loop, have_posts() and is_404() are mutually exclusive.

Useless Code in WordPress Themes

That is true sometimes, but not always. More specifically, it can be false when a non-permalink URL seeks a non-existent post. For example, /?p=-1.

Issue a 404 if a permalink request doesn’t match any posts. Don’t issue a 404 if one was already issued, if the request was a search, or if the request was a regular query string request rather than a permalink request.

classes.php

Now it makes sense that the single.php template file would check have_posts(). Let the healing begin.

(Are there any documented examples of this bug occurring outside of single.php?)

Have you ever wanted to know the name of a color when all you had was the RGB hex value?

According to Chirag Mehta’s Name That Color tool, #90a090 is nearest to “mantle” (#8B9C90). The same tool has an alphabetical list of over 1,500 colors and a Hue/Saturation/Value (HSV) color picker and it’s licensed cc-by.

via Google

A few weeks ago I read Jeremy Cole’s post on querying MaxMind GeoIP tables but I didn’t know what all that geometric magic was about so I dropped a comment about how we do it here on WordPress.com. (Actually, Nikolay beat me to it.) Jeremy ran some benchmarks and added them to his post. He discovered that my query performed favorably.

Today I saw an article referencing that comment and I wished I had published it here, so here it goes. There is a bonus at the end to make it worth your while if you witnessed the original discussion.

The basic problem is this: you have a MySQL table with columns that define the upper and lower bounds of mutually exclusive integer ranges and you need the row for which a given integer fits within the range and you need it fast.

The basic solution is this: you create an index on the upper bound column and find the first row for which that value is greater than or equal to the given value.

The logic is this: MySQL scans the integer index in ascending order. Every range below the matching range will have an upper bound less than the given value. The first range with an upper bound not less than the given value will include that value if the ranges are contiguous.

Assuming contiguous ranges (no possibility of falling between ranges) this query will find the correct row very quickly:

SELECT * FROM ip2loc WHERE ip_to >= 123456789 LIMIT 1

The MySQL server can find the row with an index scan, a sufficiently fast operation. I can’t think of a faster way to get the row (except maybe reversing the scan when the number is known to be in the upper half of the entire range).

The bonus is this: because the time to scan the index is related to the length of the index, you should keep the index as small as possible. Nikolay found that our GeoIP table had gaps between some ranges and decided to rectify this condition by filling in the gaps with “no country” rows, ensuring that the query would return “no country” instead of a wrong country. I would advise against doing that because it lengthens the index and adds precious query time. Instead, check that the found range’s lower bound is less than or equal to the given value after you have retrieved the row.

Here’s a clever WordPress site: Take My Tech is giving away used gadgets by selecting a random commenter when the number of comments on a gadget reaches one hundred. The site will pay for shipping (and hopefully make the owner a few bucks) with the revenues from advertisements. It is a bit of a gamble for the owner—craigslist or ebay would be the more obvious choices—but I find it clever all the same.

The lottery process, including checking for duplicate comment emails/IP’s, could be automated with a plugin. I suggested building on top of my own Cap Comments plugin.

There has been much discussion of the “low signal-to-noise ratio” on the wp-hackers list of late. Not that we need to move that discussion off wp-hackers, but I wanted to compose some thoughts in my own forum where I can moderate the comments to my heart’s content. This turns up an unfortunate reversal: you don’t have to read any of the comments I didn’t like, but I have to read them all. I wish moderation worked in reverse.

The wp-hackers list now serves something near 1,000 email addresses. I don’t know how big it was when I joined two years ago. I do know that the list traffic has grown to become nearly unbearable. I know that there are busier lists. I am speaking not just about the amount of traffic, but the productivity of the list as a whole.

If productivity is the wrong measure of value for wp-hackers then my nephew is a monkey and I’ll unsubscribe forthwith. By productivity I mean the production of worthwhile code, whether it be core or themes or plugins, and the dissemination of information leading to same.

I would be overjoyed to wake up tomorrow and find wp-hackers messages flooding my inbox if they were mostly productive. The banter, the academic opinions, the griping and nagging and off-topic fussing, these are the things that turned me from a hopeful reader and a contributor into a pessimistic lurker.

It has been said that wp-hackers has followed the typical evolutionary pattern of an open-source software mailing list community. This is probably true—I can’t speak from experience because I have participated little in other OSS projects—but I’m not willing to let it go at that.

Today it was proposed during the IRC meetup that we monthly post a set of rules or guidelines and be more strict about curtailing off-topic and counterproductive list activity. Assuming the manifestation of rules can proceed trouble-free, I’m happy with that.

There is just one thing I want to make clear about wp-hackers: a hacker is not someone who discusses or pays lip service or dissents or casts a vote or says what can or should be done. Hackers aren’t committee members. Hackers are more interested in proving what can be done than arguing about it.

Many important contributions have been made by people who had no interest in hacking or coding or tweaking. I do not mean to exclude them and I do not mean to glorify the archetypal geek who knows no social graces. All productive contributions are welcomed.

Case in point: this post is far too long-winded and unproductive for wp-hackers. It would be a blatant waste of time to send it to the list. To compound the sin, that waste would be multiplied by each and every response. As if it weren’t bad enough, I am afraid to think of how much time some people spend composing rubbish like this.

Let the rules say things like “think before you send” and “consider the size of the audience.” What I want to get across is that sometimes it’s better to self-publish than to use the list. If anybody has trouble setting up a blog, I’ll tell you where you can get one… real cheap.

Here’s a little idea that might improve the web for everyone. I don’t know how to draft or submit a Request For Comments—I could have read RFC 2026 (BCP 9) but I wasn’t interested—but if anyone would like to see this through, I hope you’ll contact me.

We could improve the overall performance and reduce the request load on most of the world wide web if servers supported a way of sending in one response some or all of the resources that will certainly or likely be requested (GET) as a result of parsing the requested resource.

A sufficient implementation might be possible using existing RFCs. Perhaps a media range of “Multipart” in the Accept request-header field could be used to announce that the client can accept such responses.

The ideal implementation might include optimizations for client and proxy caches, such as a Cached request-header whose value would specify for exclusion from the response any already-cached items and their LastModified, ETag, or other conditional request-header values as appropriate.

Static files served in this manner might be parsed by the web server in order to discover which, if any, other resources (images, audio, stylesheets, DTD’s, etc.) should be sent. The server might take cues from a saved list, as from a cache of previous results of parsing or from a manually generated list.

Servers generating resources dynamically might take cues from the program state, or the page generation scripts might cue the server by passing data directly or as a value of an Include response-header. When a proxy detects the Include response-header along with a single-part response, it may assume that the server was incapable of providing a multi-part response and convert the response into a multi-part response if the proxy has a valid copy or wishes to pre-fetch a copy of any or all of the resources indicated by Include.

A typical request might proceed in this way:

1. Client requests /index.html from example.com with Accept: Multipart
2. Server finds index.html and discovers that its display will require a PNG file as a background.
3. Server responds:
   {response-headers}
   {body-part (text/html)}
   –boundary
   {body-part (image/png)}
   –boundary–

In the preceeding example, there is no explicit request for the background image but the client receives it in the payload of the initial response.

Specialized user agents may use the Accept request-header to specify which types of media they prefer to receive but there ought to be a way for agents to specify which types of media they prefer not to receive in multi-part responses. For example, a screen reader probably would want the server to bundle audio but not images. A Reject request-header could indicate unwanted media types or a zero q-value in the Accept header might serve to prevent the server or any proxies from attaching these types.

A proxy handling a non-multi-part request from a client may request resources in multi-part mode and then cache and serve the individual parts as if each had been requested singly. Proxies may construct multi-part responses from parts retrieved individually and they may append additional parts according to any cue, such as by rendering web pages with the engine of their choice (perhaps taking a hint from the User-Agent request-header).

The existence of an entity in a multi-part response should not cause the user agent to display, execute, or otherwise handle the entity. User agents accepting multi-part responses should not store or execute any part which was not used during the course of rendering or interacting with the requested resource.

Does anybody else think that something like this could be beneficial?