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.
Ah, good. My concern with the MVC split was that the finished product would become bloated due to all the "glue" required to hold things together.
I'm merging 1.0.6 into my dev branch today and I want to set up another site using the 1.1 unstable branch too. So expect a few patches to be committed…
I can also take a look at the new caching classes and integrate them with WordPress via a plugin.
If you are merging into your unstable, you might as well merge the latest from the Frontend_1-0-maintenance branch. I know, I should have used HEAD for the new stuff, but I got carried away…..
What do you think of changing the default LP installation, so that everything will live in wp-content/plugins/LightPress and only the index.php file (and feed/sitemap/trackback if we leave them like they are now) will need to be copied to the main dir? Coupled with a decent WP plugin it may render life easier for end-users.
I was a little surprised that you made the changes to the 1.0 branch - we do need to get 1.1 moving, you've already put a lot of good stuff in there!
My approach is to catch up with the latest release before diving into anything new. I may just bypass your post-1.0.6 changes though and go straight to 1.1. My dev branch isn't that different from the 1.0 branch anyway, just a few tweaks that I hope aren't needed in 1.1.
As for the install directory, I like the current setup. Besides, reliance on WordPress is temporary until the backend is completed. I'm also considering making a fork of WP 1.5.1.2 that can be downloaded with LightPress, and tweak the admin interface for LP. What do you think?
Darn, every bug I've found so far you've already fixed on the maintenance branch… :)
Wow, a fork?? Why not? :)
I will be away today, will start to catch up with your commits tonight.
Erm, you may want to apply your context fixes to this site so that pagination works properly…
Ugh, I borke context_url in 1.0.6. Fixed on this site, will commit to CVS in a couple of hours (soccer match now :)
Ok, can we make a rule that changes to the maintenance branch always have to be ported to the trunk? I'm getting a little frustrated working with 1.1-dev knowing that you've fixed some of these things already. But I can't make sense of what's new in the trunk vs. what's new in the maintenance branch.
That's what I meant above when I said I should have left the maintenance branch alone…. shall I assume then that you like the changes I merged on the trunk from my devel branch?
If so, I will integrate everything between today and tomorrow, and maybe roll back the maintenance branch to 1.0.6.
The changes look good, but you don't have to roll them back, just roll them forward into the dev branch.
Uhm into the dev branch you mean?
Ugh, the maintenance branch :)