For those of you who’d like to customise things further, here are a few pointers…

The plugin only defines two of the constants associated with custom headers, HEADER_IMAGE_WIDTH and HEADER_IMAGE_HEIGHT. There are a few others which you could also define in the same way:

• HEADER_TEXTCOLOR sets the colour of the text that would go over the header image. Tarski doesn’t use this value, but other themes do.
• NO_HEADER_TEXT is set to true by Tarski, because it doesn’t have an option to put text over the header. Again, this is more useful when using other themes.
• HEADER_IMAGE sets the default header image. In Tarski this is set to the image you chose on the Tarski options page, which would then be overridden by any custom header image you set up.

Please note that if you have the WP_DEBUG constant set to true (this is usually only used by developers) then you’ll see a bunch of warnings as Tarski will attempt to redefine these constants. This will be fixed in the next version of Tarski.

The entire process is now automated, pulling the documentation straight from the inline documentation in the Tarski source code, so further updates to the hooks reference will happen entirely silently as new releases of Tarski come out.

If you’re interested in the code I use to do this, it’s available on GitHub.

Download Tarski 2.4

You can also get this release as a Git tag or a Subversion tag or branch.

We strongly recommend following the upgrade guide. Always back up your files and database before running a WordPress or Tarski upgrade. Please ensure that you upgrade WordPress before installing the new version of Tarski.

Tarski 2.3 was an extremely stable release, so while there are a lot of changes in 2.4, they’re almost all in support of new features. A lot of behind-the-scenes work to make Tarski’s code cleaner, more robust and compatible with WordPress 2.7 has taken place, but the interesting parts for most users will be the two major functionality changes to comments and the options page.

Tarski now supports the new threaded comments functionality added in WordPress 2.7. Threading and paging are both built into the WP core, and are pretty configurable from the admin panel. One can decide whether comments should be paginated, and if so, how many top-level comments should appear on each page (if threading is disabled, all comments will be top-level ones). The maximum level of nesting can be set from 1 to 10, and comment threads can be set to automatically close after a certain period of time.

The changes made to accommodate this new functionality mean that Tarski’s comments are now ‘inline’ with the main content area, and are no longer forced down by the sidebar. This decision was difficult to make; Tarski’s distinctive comments were, to my mind, one of the more elegant features of the theme and the limitations they imposed were minor compared to the benefits of better spacing and a decent content area for comments to fit into. However, given Tarski’s ability to swap columns around and the need to support RTL languages, the development and ongoing support burden would have been too much, given the vast amounts of added complexity that the new comments system brings.

Obviously the biggest user-facing change in WordPress 2.7 is the new, completely redesigned admin panel. When it became clear just how radical the changes were, I decided that despite the Tarski options page being thoroughly overhauled not too long ago in version 2.1, I had to revisit both the aesthetics and the functionality. The result is, I think, a cleaner and more effective options page which doesn’t feel out of place in the new admin area.

There have also been some changes to the way options are saved to the database: Tarski now uses the WordPress generic admin POST handler, which both leads to more modular code and bakes in a certain amount of additional security protection. Furthermore, building on the security improvements in version 2.3, the options handlers now check the referrer to protect against CSRF attacks—a type of attack that Tarski’s login and logout links are also now hardened against, thanks to Mark Jaquith’s thoughtfulness.

Tarski’s update notifier now uses the new HTTP API, which has several advantages over Tarski’s native update notifier code. To begin with, it will work across a far wider range of transports, potentially making update notifications available to many more people whose servers don’t support libcurl or fsockopen. Just as importantly, it will be supported by the core WordPress team, reducing the amount of complex and highly specialised code in Tarski. This leaves me more time to focus on Tarski’s core competencies and reduces the opportunities for bugs in the update notifier (something that has been an ongoing issue ever since it was introduced).

Thanks to those who tested the release candidates; I hope everyone enjoys using the new version.

Please post any bugs or suggestions on the forum.

Tarski 2.4 RC2 has much better trackback support, adds an extra save button to the bottom of the options page, and improves the update notifier’s HTTP transport checking. There are also various bits of refactoring that shouldn’t impact on the user experience. I should also note that the tag is on GitHub if you want to grab it that way.

Tarski 2.4 RC1 is essentially feature-complete; it will only work on WordPress 2.7, so if you have WordPress 2.6 or earlier, don’t install this version of Tarski. Bug reports are extremely welcome and should be posted on the forum.

Update: Ryan Boren tells us that “The final release of 2.7 won’t be here until next week.” Tarski 2.4 will follow shortly after that.

What is important is Tarski’s quality as a project, its options, its features and its extensibility.