Needing a break from bug-fixing, testing and support I have decided to open up a conversation on version 5 – (why don’t we use codenames by the way?)
I would like this conversation to include Paul, James, David (if he is still around) but would suggest we keep content under our hat for quite a while yet as we still don’t know what we will be able to deliver.
First though… 4.3 – this version will, by it’s very nature, be content neutered as it’s release must coincide with WP3.0 – the WP and WPMU merge. I suggest we keep new items to simple and easy tasks to avoid the need for weeks of beta testing because, as we all know, the Mullenweg likes to drop releases early if possible with minimal advance notice. So small new things, bug fixes and merge ought to be our target.
I doubt we will be able to get away without a 4.3.1 and maybe even a 4.3.2 although we have discussed the notion of a subforum for ‘patches’ if they are small and simple enough. The main opposition to that method are the WP team themselves that never seem happy unless they throw in a couple of changes we need to deal with in each update.
Which brings us to 5. And I think we should start the discussion by throwing out all new features and concentrating on the philosophy.
PHP
I have no idea when the Mullenweg will decide the time is right to move up to php5. We, of course, are not bound by that decision and could declare php5 as a minimum any time we like. But as with all technical mandates like this it is only worth doing if we genuinely need php5 features and, at the moment, we do not (for current code).
Seems to me that the main reason for adopting php5 is for the OOP and while I would sort of like to go down that route it is a major commitment, a big learning curve and one hell of a lot of rewriting… although, there again, we are planning one hell of a lot of rewriting anyway. In many respects I do not have a preference and that may well just be coloured by the learning needed to do things the proper php5 way. Perhaps the right question should be: ‘Would adopting php5 make our task any easier, our codebase smaller, performance faster and ongoing development simpler?’
MYSQL
MySQL is a different matter altogether although hosts seem more reluctant to upgrade MySQL to V5 than they do php. But for us MySQL5 has some definite and useful advantages. Views, Stored Procedures – even Triggers (I believe) come into play. These can boost performance dramatically as well as take some of the strain out of the codebase.
I fully support mandating MySQL V5 as a minimum requirement although we have to take into account how that would play out in the real world of recalcitrant hosts.
MY VISION OF SPF5
So move along now to what we want to see as the goals of SPF5. As stated, I believe we should forget all about features for now and concentrate on the framework – even if that means ripping out most of what we have now to accommodate what we believe is the right way to go forward.
So this is my top level list:
Display Templates: Move completely away from the hard-coded, rigid display method we now have to a templating system where the user can decide what goes where and in what sequence. I see no reason why this should follow the WP theme model which is actually quite difficult for most users to deal with and fully support the design of our own templating sub-system to try and make it as easy as possible.
CSS Sprites: Move away from the use of icon sets to single images containing a complete set positioned by CSS. This is actually a little more difficult for the average user but gives us great gains in performance and http requests.
CSS UI: Allow the end user to alter forum CSS via a UI. This could work by storing all of the CSS in a database table from which we can generate a CSS file. The CSS could be broken down into small sections with identifiable names linked to the template.
Simplified Visuals: Allow for forum displays with no or fewer) icons and a simplified look. Tis would, of course, be tied onto the templating system.
SPF Plugins: This doesn’t have to be that clever. We should be able to simply define a folder and allow the end user to store code in that folder (with one main file like WP) that we optionally include.
Highslide: Replace Highslide with the alternative, more lightweight version written by Gene (a user).
Editors: Let’s at least try and get rid of TinyMCE although we must always remember that it actually doesn’t do that bad a job of stripping out the garbage and formatting to valid HTML.
Database Queries: Handle database errors gracefully and properly into an error log file (as we have akrady done on Search queries).
Display As-You-Go: We currently create the whole page in memory before displaying it. As things have become more complex it is time to at least look at more normal page display.
Message Strings: Allow the user to alter the more common and public message strings (front end only).
Mobile Browsing: We can’t ignore this any longer. Seems like the main problem to resolve is the javascript and editor.
Login/Registration: If we get what we want for this finally deal with it in an acceptable and organised way.
(Since starting to write this we just learned that WP3.0 has been pushed back two more weeks to early May – was originally late March – so I giess that makes this a little more premature than I expected but hey – it’s never to early to start talking.)
and wouldnt use, but we should get full support going
