LightPress

Since moving this site to TextDrive, things have progressed at an astonishing speed.

The news of the day is that LightPress is now an officially supported TextDrive project. I am very impressed by what Jason and the TXD people are doing, and becoming part of the team is both an honour, and a challenge.

As for LightPress, we have not been idle after releasing 1.1.0alpha1. Jerome has started working on our own distribution of WordPress, which will feature an integrated install for both WP and LP, and a few patches to the WP code to enhance usability.

For my part, I have put my modest web design skills to test and started work on a new template, to replace Kubrick as our default. While Kubrick is nice to stress WP compatibility, it's getting a bit old. The new template is an elastic design, and you can see a test install on my English blog. It's not finished, but I hope to be able to release it in the next couple of days. BTW, if you have web designer skills, why don't you join the LightPress development team?

I have just uploaded 1.1.0 alpha2 to Sourceforge. This new version features the much needed WP plugin that lets users configure LightPress from the admin console, and it's also the first version of LightPress to run from the WP plugins folder (well, most of it). In short, you can now try LightPress without messing with your WP files (it was possible even before, but it was much much harder to do).

We have mixed feelings about LightPress running from the WP folder, so if you have an opinion about this (and other LP features too), please let us know by commenting to this post or sending us an email. We still have lots to do (apart from spotting and fixing the inevitable bugs) before declaring 1.1.0 stable, mainly in the WP plugin (checking and setting .htaccess, checking options for consistency, etc.), so you still have a chance to ask for new features.

I'm progressing with the WP plugin for WordPress, which is the main thing missing before releasing 1.1.0-alpha1. It will alow users to set options, and activate/deactivate/configure plugins.

It's a lot of (boring) work, but seeing the LP console taking shape and knowing users will have a graphical install/configuration tool integrated with WP is pretty exciting. Stay tuned. :)

Jerome has been busy this weekend merging his dev branch and bug checking all the new additions. I have no excuse then to postpone the release of the first 1.1.0 alpha much further, so I spent some time this morning before getting to work merging the (unreleased) general cleanup I did last week to the 1.0 branch with the trunk, which is now officially tagged as

.

In the eat your own dogfood spirit, I have also update this site to 1.1.0-a1 so that we can properly test it, and so that you can see a few of the new features in action. The more visible feature (and the one I find more interesting) is what I call contextual content: showing different information depending on the context (category, archive, post) the user is in. More on this later. I have also enabled caching, so general users (i.e. users without a WP/LP cookie) should notice a speedup in rendering times.

Before I release a1, I'd like to finish the WP plugins to manage our configuration options from the WP console. Hope it will not take too long, stay tuned.

A few quick notes on the current status of development.

The mock-up for the "split" architecture involving a sort of mvc layout for Frontend did not go too well: the code is much more complex and, though more flexible in some situations, it also seems a bit slower so iI have abandoned it for the time being.

In the last couple of days I have concentrated on speed in the 1.0.0 maintenance branch:

• removed all PEAR dependencies and switched all classes to the PHP error system

• refactored Frontend to allow context-dependent queries before we fetch posts

• added a getLastModified() method to Frontend which checks the last modification date for the context posts and optionally comments

• added two caching classes

The Cache classes are a very clean db-based one which I like a lot and a filesystem-based one. Both classes give a 7x performance boost checking LastModified(), to do better we have to integrate with the WP backend like the excellent wp-cache does. The fs-class still needs work, and the integration with Frontend is sub-optimal. Will work a bit more on that in the next few days, if there's any interest. The new code can be found in CVS.

One of the benefits we might get from the new architecture I'm testing is a much more integrated and simpler feed management, so while adapting the current code to the new class layout I took the occasion to revise or support for Conditional Get.

I had already adapted Simon Willison's code to work around a bug in PHP's

formats (fixed in 4.3.11), but the code was a bit too complex for my tastes, and re-reading the relevant parts of the HTTP/1.1 specification, I noticed that full compliance requires supporting three different date formats, all in GMT:

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123


Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036


Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format

All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception.

HTTP/1.1 clients and servers that parse the date value MUST accept all three formats (for compatibility with HTTP/1.0), though they MUST only generate the RFC 1123 format for representing HTTP-date values in header fields.

As LightPress stabilizes, we can start asking ourselves a few questions on its architecture, some of which Jerome and I have already discussed in private. Given the increasing interest in LightPress, I thought it better to move the development discussions here, to give readers the opportunity to influence our decisions.

The question I've been meditating this weekend is whether the current Frontend class is trying to do too many things at once, and if it would be better to split it into separate classes. I'm not trying to start a religious discussion on design patterns, OO vs functional programming, or leaky abstractions, I'm just wondering what (if) we would gain/lose from splitting Frontend into more manageable/consistent classes.

If you are not familiar with Frontend, you may notice by looking at this rough UML diagram that its methods are already split into categories:

As promised a couple of days ago, today I have spent half
an hour on the SQL queries emitted by a default WP installation. To do
so, I have logged the quries in mysql and written a simple PHP test
script. Here is the first run of the script, comparing 500 runs of
each of WP's and LP's queries (LP is missing two queries, one for
users as I have not enabled Jerome's AdminOptions plugin, and one for
static pages as they are not emitted by default):

WP queries
----------
1. users:                       0.090523 ms
2. options:                     0.118955 ms
3. posts:                       0.222328 ms
4. posts (count):               0.049981 ms
5. posts (categories):          0.190947 ms
6. posts (comments):            0.100817 ms
7. posts (meta):                0.053948 ms
8. categories (flat):           0.138303 ms
9. categories (flat, again):    0.137282 ms
10. categories (posts count):   0.125479 ms
11. archives:                   0.060956 ms
12. archives (again):           0.063106 ms
13. static pages:               0.086774 ms
14. link categories:            0.073251 ms
15. links (first category):     0.262116 ms
16. links (second category):    0.289843 ms
total:                          2.064609 ms

LP queries
----------
1. posts:                       0.192770 ms
2. posts (count):               0.049936 ms
3. posts (comments):            0.056783 ms
4. posts (categories):          0.190775 ms
5. categories:                  0.168887 ms
6. archives:                    0.062130 ms
7. links:                       0.085729 ms
total:                          0.807010 ms

After the WP/MySQL discussion of a couple of days ago, I have taken a few minutes today to set up a test envornment with WP and Lightpress, configured with the same exact features and running against the same DB taken from a 1k posts production site.

I have then logged all queries sent to MySQL (

) by the index page of the two frontends, and written a quick script to benchmark each statement after having primed it a few times to make sure table data is in memory. The results are pretty much what I expected (citing from memory as I don't have the test environment on my laptop): WP runs 16 or 17 queries against LP's 7 queries, and LP is faster by an order of magnitude.

I hope to be able to post a detailed analysis soon, and maybe a few suggestions on how to improve WP queries without changing their nature, as I have no patience to delve into WP's code, and I would end up with something very similar to what LP is already doing.

A couple of hours of free time before getting to work this morning have produced Google Sitemap support for LightPress, and a new 1.0.6 beta release. It's a beta since Sitemap support is not well tested, and I would like to add gz compression support before declaring it stable. Our Sitemap implementation has a few interesting features:

• the "home" Sitemap lists URLs for all categories, archives, and the latest

  posts_per_rss

  posts

• each category and each archive has its own Sitemap, listing itself and all its posts

• a SiteIndex lists all the available Sitemap

• the

  lastmod

  element is set to the date of the last post for categories and for the current month in archives, and for the last day of the month in old archives

• Last-Modified/Etag support, since it shares our feed serving code

1.0.6b can be downloaded from the usual place, where you can also find its ChangeLog (also copied below). After having written this post, I noticed a couple of bugs in feed.php, which you can patch by applying this small patch to 1.0.6b if you do not want to wait for 1.0.6 final. [tag: sitemap]

Update After modifying the root element in the templates according to Google Sitemap Help, both our sitemap and sitemap index validate.

The new 1.0.5 release attempts to fix a couple of minor bugs when formatting newly inserted comments, and backports a few new features from unstable:

• a proper archives permalink and a general cleanup of archives-related code

• archives list rendered with the faster parseBlock() Template method

• a new template variable

  post_comments

  , set to 'comment' when there's 1 comment, 'comments' when there are 0 or more than 1 comments

• comment insertion moved to Frontend, with a hook to attach different spam checking plugins

As usual, you can download 1.0.5 from the project filelist, or read its ChangeLog (also copied below for convenience).