ionfish / tarski

This would make Tarski's Recent Articles widget a lot nicer and easier to maintain; the downside is that it means breaking backwards compatibility with WordPress 2.7, something that has thus far been maintained in Tarski 2.5 development versions.

WordPress 2.8 includes the automatic_feed_links() function, which replicates this functionality. Tarski already uses this function if it's available, but by using it exclusively we could remove the large and hairy feeds() method from the Asset class.

This would involve dropping support for WordPress 2.7 from Tarski 2.5, although requiring the most recent version of WordPress has been usual for recent Tarski releases. An additional consideration might be that Tarski 2.4 was released over five months ago, and requiring a WordPress upgrade is not an onerous requirement since users should be upgrading anyway.

Calling it Options, given PHP4's lack of namespacing, was a really stupid idea in the first place. Such a generic name is extremely likely to be used by either WordPress itself or another plugin or child theme; it's amazing this hasn't caused all kinds of problems before now.

The basic problem is transferring old options data if the class is renamed; the unserialize() function tends to go haywire if the class name which the serialised object is supposed to be an instance of doesn't exist. Worse, WordPress' get_option() function automatically calls unserialize() on options which are serialised objects, so we don't have a chance fiddle with the raw data unless we start writing our own version of get_option() and screwing around with SQL.

If these problems can be overcome then this would be a good change to make. If not, well, it's survived this far without screams of outrage, so it can probably just sit there looking smug for another three years.

Probably won't require any other markup changes. We'll be conservative about introducing new elements for the time being, so as not to break backwards compatibility with older browsers.

Time to drop this.

Time for this to go.

Should link to #respond instead.

If one deletes all the default Tarski headers, all one gets is an inscrutable (to the end user) PHP error message. This can be better handled with a message suggesting that the user upload some new ones or restore the default ones.

Currently there's just an undefined variable error. We could instead present the user with a message stating that there are no alternate styles available, and explaining where to upload them.

Should add a README file with a basic introduction to Tarski and links to the online documentation.

For HTML5 (which does not support the 'profile' attribute) we should add a link instead.

http://microformats.org/wiki/profile-uris#.28X.29HTML_5_.2F_XHTML_2

This would make the whole thing more pluggable and allow easier reordering of the links.

This would allow for simpler programmatic manipulation of the navbar.

Since the internals of the TarskiOptions class have changed quite drastically for the next release, the current upgrade routines are completely broken. This must be resolved for release.

This is really badly documented at the moment, it's easiest just to read the WP source.

WP core is now minifying a lot more stuff, and this can help a lot with the load times for people whose hosts don't have gzip enabled (and a little for those that do).

This would be more pressing if Tarski loaded a lot of JavaScript, but its JS dependencies are currently very small; this may change in the future.

Currently it's quite hard to customise the display of post metadata, outside the limited options available for individual elements (dates, authors). Emmanuel Gravel has proposed a single action hook, th_metadata. My approach would more likely be along the lines of the tarski_navbar hook, where elements are added and removed via filters.

The 'Asides' functionality is all hard-coded, limited to one category, can't be disabled programmatically etc. Improving it would allow plugin authors to extend or remove it, while keeping its default mode of operation the same.

PHP not having many good facilities for abstraction is no reason to anger the object-oriented gods. We can peel a few layers from this particular onion and still retain backwards-compatibility with regards to its API.

Lots of things end up in odd places, so this needs the same care and attention that the theme stylesheet has had.

Need to make sure everything is up to scratch with respect to the new escape functions in WP 2.8.

http://comox.textdrive.com/pipermail/wp-hackers/2009-May/026242.html

Currently this is ruled out by the various IDs in use, plus probably some other issues. I tried to do this once but ran out of patience. A decent theme ought to be able to manage this.

Should include the translations for all versions of Tarski. Binary (.mo) files should be included in the repository only when relevant source files (.po) do not exist. There are some other pieces of work that would need to be done in concert with this:

• Create new gettext generation tool for Tarski, to make it easier to automatically generate the POT file upon release
• Create new translation packaging tool to generate translation binaries from source and zip them up

See this forum discussion for further details.