Jerome just published a few suggestions on future developments, and features he would like to see implemented in WPFF. Here's my position on these issues, as usual I welcome any feedback or attempts to make me change my views.
1. Templates I have never liked Smarty, even though I knew about it since the first proposal and even stated my views on the matter (can't find the link anymore, sorry). I won't switch to another templating system for some time, and when I do it will be my ZPT implementation. ZPT is simply the best templating engine available, writing for it is a pleasure (of course, Python has something to do with it). I know there's a PHP implementation already available, and even though it is used for MediaWiki (the Wikipedia Wiki engine), I don't like it very much and won't use it in my code. As for the question of leftover template variables, it's a feature not a bug. If you see something like {my_variable} in the HTML output it means there's a bug somewhere. And if you don't like this behaviour you can just change the Template constructor arguments to hide missing vars:
$tpl =& new Template($path, 'remove');
2. Missing Features As Jerome says, new feeds are very easy to develop requiring only a new template. I will add them in a future release, even though they're not essential since RSS2 is enough for most needs.
WP get vars/permalinks compatibility is not at the top of my list either. I need WP compatibility only at the DB level, I don't much like its architecture and have no desire to delve into layer upon layer of code every time I need a new feature, only to preserve compatibility. And in the long run, I will write a new backend based on a radically different DB schema, and WPFF will become its frontend. If somebody wants to add WP compatibility though, I will welcome a patch.
Search is a feature I will add soon, as we are discussing adding it to our blogs. It won't be very sophisticated (people use Google anyway most of the time), and it will definitely use MySQL's full text functions. It will proably be implemented as a plugin (which will require a slightly more sophisticated hook than the ones already there), so that people that don't need it can skip the relevant code and keep their frontend a bit faster.
The last one (render content once) is definitely on the top of the list, but will be implemented in the new backend. I totally agree with Jerome in that complex things should be done once and stored in the DB, as it's pretty stupid to transform thousands of times content that changes once or twice in all its lifetime. What I will do is store the "raw" content, its "content-type" (text, HTML, Markdown, etc.), and the rendered version for each post.
3. Caching Caching will be the last feature to be added to WPFF, with something similar to PEAR's Cache:Lite. It will probably be a plugin at the page rendering level.
Glad to hear that you're sticking to your principles. :)
I like the idea of adding functionality via plugins. Your plugin architecture is very lean and this makes the core simple & streamlined.
I may just write the WP compatibility plugins myself, except for permalinks - the patches I've sent you so far meet my permalink needs.
One other suggestion: move the comments retrieval from within renderComments() to a separate getComments() function. That way comments can be modified more easily by plugins or code placed in between Frontend instantiation and ->startRender(). It also leaves open the option to use another rendering system.
Thanks Jerome :)
I did not think of WP compatibility as a plugin, but as a patch that changes all the GET vars to be like WP GET vars. Then you will maybe need a plugin for permalinks, etc.
As for getComments() you're reading my mind, as I was just thinking about this today. Made a few changes, will release a3 in the next few days.
Sorry, I wasn't referring the the request variables - those would need to be added at source. To be honest, I'm not even sure how necessary that is anyway. Key "WP compatibility" is getting around the problem of unformatted data (posts & comments) in the database.
Right now I'm making a simple authentication plugin to reproduce the login and "edit this" links - I'm too lazy to navigate the WP back-end.