On behalf of the entire WordPress team, I’m proud and excited to announce the immediate availability of version 2.2 “Getz” for download. This version includes a number of new features, most notably Widgets integration, and over two hundred bug fixes. It’s named in honor of tenor saxophonist Stan Getz.
–Matt, from WordPress

Here’s my “short list” of observations:

• Widgets (ie, AJAX-y sidebar thingies)
• Full Atom support (plus new XML-RPC APIs)
• Blogger.com integration
• jQuery used for internal functions on admin page
• Optionally set “home” and “siteurl” options in wp-config.php instead of the database (useful when supporting a dev/prod setup)
• Tenor players (eg, Getz) rule

if you followed my previous post regarding subversion access to WP code, I can attest that the upgrade is now as easy as:

svn switch http://svn.automattic.com/wordpress/trunk/

…and hitting the database upgrade link. I needed to svn switch since, as you may have noticed, I had checked out the 2.1.3 tag, not the trunk. Switching to trunk should mean that all future upgrades are as easy as svn upgrade. Whee, etc!

Last year, Murali, from his Thought Garage, expanded on some perspectives I offered in the comments of a Berkun Blog comparing those who “complexify” and those who “simplify.” For simplifiers familiar with the often-debilitating effects of complexifiers (at least, in the world of software development, where “real world” issues like deadlines and deliverables reign,) the problem is what do we do with redundancy when we can’t take it out back and shoot it in the head?

The irony of adding to a lengthy discussion on the topic is hopefully not lost on us, but I feel compelled to add that this is precisely the problem Zen addresses. That is, there is a way to directly experience the truth of our situation without expending excess energy on processes that do not serve us. During walking meditation yesterday, it occurred to me that Yeats said this very thing to me in The Coming of Wisdom with Time:

THOUGH leaves are many, the root is one;
Through all the lying days of my youth
I swayed my leaves and flowers in the sun;
Now I may wither into the truth.
–Yeats, William Butler

So, the solution? Read. Read more. Read even yet still more.

Then, go ask a tree.

The following is a method for Catalyst sites using Template Toolkit with a site-wide WRAPPER directive to selectively return partial HTML for the purpose of serving Asynchronous HTML and HTTP (ie, “AHAH’).

Catalyst is a powerful and versatile web development framework that aims to be Perl’s counterpart to Ruby on Rails, fusing a Model-View-Controller (MVC) environment with the depth, breadth, and power of CPAN. If you build web sites with Perl, you should check it out.

The problem: you want to use TT’s WRAPPER directive to supply a site-wide wrapper template, but you also want to be able to selectively turn the wrapper off so that you can serve some pages as partial HTML. At first glance, Catalyst’s config() method might suggest that one could reconfigure your view in your action’s end(), but that proves fruitless and it clucks in the following manner:

[warn] Setting config after setup has been run is not a good idea.

My solution: create an end() in your controller that emits “partial” HTML fragments by creating a new Template Toolkit object with a locally-defined configuration. (Note that since we override the root controller’s end(), we must call forward/detach to it if we do not specify the “partial” parameter.)

sub end : Private {
my ($self, $c, $file) = @_;
my $params = $c->request->parameters;
if (exists $params->{'partial'}) {
my $html;
my $tt = Template->new({
%{ $c->config->{'View::TT'} },
INCLUDE_PATH => $c->path_to('root'),
WRAPPER => undef,
});
$tt->process($file, $c->stash, \$html) or $c->log->warn($tt->error);
$c->response->content_type('text/html');
$c->response->body($html);
}
else {
$c->detach(qw/CE::Controller::Root end/);
}
}


A more robust solution better-suited for larger projects might be a new view with an alternate configuration (eg, a custom View::TTpartial,) but I wanted to show the logic directly in my controller, allowing full control of the configuration and direct access to the $html.

Coming soon: the “data island” solution I ultimately opted for to obviate AHAH for serving map marker data to a Google map.

i just migrated from the tarballed wordpress source code to a locally checked-out copy of the subversion repository. this should allow me to upgrade in the future by using svn update or some equivalent.

here’s how i did it. see the upgrade documentation for details.

mkdir mijit.com-new
( cd mijit.com-new && svn co http://svn.automattic.com/wordpress/tags/2.1.3 . )
cp -pr mijit.com/{.htaccess,wp-config.php,wp-content} mijit.com-new
mv mijit.com mijit.com-old && mv mijit.com-new/ mijit.com


note: on my production server, i ran into a problem where the upgrade page didn’t work – it simply showed a white page, no matter how many times i reloaded it. i peppered the php code with die('x') to see what was failing, but it seemed to just crap out at some point in the script execution. then, i discovered the following in my apache error_log:

Allowed memory size of 8388608 bytes exhausted (tried to allocate 0 bytes)

aha – so sucktastic php is crapping out and barely giving any indication that it is to blame! (i don’t blame the wordpress people for not slavishly checking every memory allocation, but you’d think php itself could put something cunning like “php” in its log lines so i know the error is neither with wordpress nor apache.)

googling that line brings the solution, to increase the memory available to php. not that that stopped me from wondering why the hell an upgrade script (which presumably just updates a version string, based on a cursory examination of the code,) needs a ton of memory anyway:

in /etc/php.ini, bump from 8M to 16M:

memory_limit = 16M

installation proceeded flawlessly.