So I got this bug in my head a while back that there really needed to be a better lookup function for WordPress code information. Maybe its true that everyone who knows how to just greps the source, and the Codex search is only for beginners who don’t care if it takes a while to find what they want. I personally don’t believe that. Yes, looking through the source with ack-grep (or having your IDE do it for you) is going to be the quickest way to find what a given function does, or what order the arguments it takes should go in.

But there’s a few weaknesses to depending on the inline documentation. First, I already mentioned the problem of beginners who may be perfectly capable of putting together a theme, but are intimidated from searching through the source. Second, there are some classes in WordPress that are so complex that even with very good inline documentation, its much easier to follow a Codex entry than to view the source. Compare, for example, the Codex entry for WP_List_Table with the source.

Basic issue, so many people put so much effort into improving the Codex documentation, and so many questions are asked and answered on support forums that could be solved by simply searching the Codex, that I figured making the Codex more searchable would be a win for all involved.

So… the process

First step was to get a list of the pages on the Codex where redirects would be useful. I looked at exporting the Codex to work with locally, as per Eric Mann’s answer here on Stack Exchange. But that seemed like too much overhead for me. I didn’t need page text or revision history, just the page title was enough for me. So, I went with a simpler scraper on scraperwiki which pulled the page titles of every public entry in the Codex.

Running this function over http://codex.wordpress.org/index.php?title=Special:AllPages takes a few minutes, and gives me 4117 pages. Very nice. Now, a lot of these pages are in foreign languages which I don’t want to mess with. Actually, this stuff is not in any real order, so I decided not to try to handle everything with one function. Its probably safer to deal with the “Function Reference” entries separately from the “Template Tags” or “Plugin API” entries. So, I’m searching for titles that contain “Function Reference” and don’t contain a colon, as in es:Function Reference/wp_blahblahblah. Here’s my first stab at getting just the articles that need to be redirected:


Query: select * from `codex_pages` where title like “%Function Reference/%” and title not like “%:%”

That seems workable enough for my purposes. Its possible that I’ve missed some, but this is really just a first pass… There is still a lot of hand-tuning necessary to fix the entries whose titles don’t translate well into Mediawiki’s naming formats (like __(), for one). But creating 1000 good redirects is still useful.

For those who are interested, here’s how I ran the bot. I used Wikimate, an unofficial PHP SDK for mediawiki.

login($username,$password))) {
	$error = $wiki->getError();
	var_dump( $error );
	exit;
}

$x = file_get_contents( 'https://api.scraperwiki.com/api/1.0/datastore/sqlite?format=jsondict&name=wp_codex&query=select%20*%20from%20%60codex_pages%60%20where%20title%20like%20%22%25Function%20Reference%2F%25%22%20and%20title%20not%20like%20%22%25%3A%25%22%20' );
$pages = json_decode( $x );

foreach ( $pages as $i => $page ) {

	$title = trim( $page->title, '/' );
	$href = trim( $page->href, '/' );

	$function_name = end( explode( '/', $title ) );
	$function_href = end( explode( '/', $href ) );

	if ( $function_name === $title || strstr( $title, '$' ) )
		continue;

	// check if the page exists or not

	$create_page = $wiki->getPage( strtolower( $function_name ) );
	if ( $create_page->exists() ) {
		echo "E\t$function_name\t$function_href\n";
		continue 1; 
	}

	// Create redirect page

	if (!$error = $create_page->setText( '#REDIRECT [['.$page->title.']]' ) ) {
		var_dump( $create_page->getError() );
	} else {
		echo "N\t$function_name\t$function_href > $href\n";
	}

}

So… does it work? Let’s see:



<form action="http://codex.wordpress.org/">
	<input type="text" name="search" />
	<input type="submit" value="Search" />
</form>

Try searching for a function name. You should get directed straight to the relevant Codex page, if one exists.

Last year, I did a few mobile projects using the jQuery Mobile library, which is a really nice framework for getting started quickly with mobile interactions (listening for swipe gestures and taps, animating page transitions, and building one-page javascript apps). I had intended at the time to take the leap right away into building mobile apps, but got sidetracked.

Fast forward to this week. I’m working on a pretty fun canvas app using fabric.js that I plan on releasing as both a Facebook app and a mobile app (will do Android first, then worry about iOS later). While I was stuck on some annoying text-rendering bugs in fabric, I decided to try out the process of packaging and publishing an app, so as to be prepared when I got to that stage.

Mythology: The App

For an app, I dug up an old scraper project that I worked on a long time ago. I have a scraper up on scraperwiki.com to scrape all the entries from pantheon.org. Its a nice geeky wiki site with sentence or two definitions of gods, heroes, and monsters from like every pantheon in history. Unfortunately, its somewhat abandoned (hasn’t been updated since 2009 or so), hard-to-navigate, and in some places desperately needing to be fleshed out with source material, images, or whatnot. Still, its the best source for this information I could find, and I figured what better way to motivate people to contribute to a project than to do something that gets its info out to more people.

My scraper was about 100 lines of PHP, done with the Simple_HTML_Dom class. Was a bit of a pain to write, if only because the source pages were a little awkward to figure out how to parse. It went fairly smoothly though. My scraper pulled in 5380 records, the site says it has 7296. Either there are a lot of duplicates on the site, or some pages didn’t follow the same markup and my scraper missed them, or some pages on the site aren’t linked to from anywhere and my scraper coudn’t find them. Oh well. I still managed to get a lot of data. It’ll do for government work.

I decided to be completely lazy when it came to building the app. If anyone actually uses it, I can always go back and do it right. So I just built a one-page app in jQm that queries the datastore at scraperwiki. (Is that against the Terms of Service? Surprisingly, I don’t think so. That site is pretty awesome.) So, on opening the app, it immediately makes two calls to the scraperwiki api, to generate the list of categories (about 300b) and to pre-fetch the names of all entries (about 26K). I suppose I could get rid of that larger call, but it seemed to make the app run much faster, so I left it in. Then on choosing a record to view, the app makes another call to scraperwiki to retrieve the record.

How would this be done correctly? I guess it would be faster to just include the entire sqlite database with the app. I didn’t go that route because one, getting phonegap to handle large database creation looked like a huge chore (there are some promising libraries out there that handle that, like html5sql.js, which I will try out when I go back to update the app); and two, adding a 3MB sql resource with my app would triple the size of my app, and really, this is some basic stuff… I can’t justify taking up that much disk space for something that should be next to nothing in size.

I seriously put next to no effort into design here. Took the default jQm theme, threw in a little Trajan font and some free stock photo of parchment for background, and put it all together. Easy enough, if you don’t mind looking like every other site out there. Luckily, the transitions built into jQm work pretty well for my purpose.

Next post I’ll tell the story of packaging and publishing the app. Right now I’m still waiting for Google to approve my developer account.

Related, if you want to get into using jQuery Mobile, you might want to check out my boilerplate for jQuery Mobile WordPress themes. Its really a bare minimum, but it should get you started on the framework.

While working on my Recommended Links plugin, I wanted a way to auto-populate the link title field based on the URL entered. I was stuck for a while dealing with cross-domain XHR issues and initially fell back to using a WP Ajax request, using wp_remote_get to get the remote link and returning that to PHP… however, it was slow and not all that elegant. Why bootstrap the entire WP environment for one simple Ajax request?

Did some researching, though, and I discovered YQL, which I had played with before, but never thought of as a tool for getting around cross-domain request issues. Apparently, however, its been widely used for that purpose for a year or so — there’s even a jQuery plugin that converts all external Ajax requests to YQL queries. Sweet!

The one problem I had, though, was that YQL’s html table only includes the <body> element, and I wanted to retrieve the <title> text.

So I looked through the Open Data Tables available, and lo and behold, there’s an htmlstring table that returns the entire html of a document as a string. So all I had to do was a little regex matching to find the <title> element, and I was all set.

— Read more —

One of my favorite political news sites for several years has been Counterpunch, and lately, with all the news coming out of Tunisia, Egypt, and the Arab world, I’ve found myself visiting their site a couple of times to read up on current events and analysis.

Actually, its a site that I would like to keep up with more regularly, and I probably would, too, if the 1997-style website didn’t make it so hard to keep up with. Seriously, its still maintained in Adobe PageMill. In 2011. Last time I opened that program was probably 1998, and even then it was dated.

— Read more —