I've started a new CMSMS branch this week. Making some signicant changes under the hood and I figured I'd bring the regulars up to speed on where I'm going with this.
Removing the prerendering loop
All of the tags used in CMSMS will be proper Smarty tags now. Including content, html_blob, title, etc.
Why is this good?
A lot of logic will make more sense now, and we remove the "it's all smarty but THIS aspect". Plus, you'll be able to do regular smarty type things with these tags as well. For instance, {title | capitalize} will now work. It also seems a little faster now, because the SQL queries aren't as intense.
What might break
ContentPreRender isn't going to have the same data in it. Before, it was content + template + title tags and html_blobs. Now it will be JUST {content}.
Removing moduleinterface.php
Currently, we use the moduleinterface.php file to do any pages where a module takes over the {content}, like when you click on News Detail. I'd like to remove this and use index.php for all of this.
Why is it good?
Less code, less pages. Removing of some duplicated code.
What might break?
Anything that hardcodes to moduleinterface.php could have a problem. Though, for now, I'll probably just include moduleinterface.php to keep things backwards compatible. It will probably be removed after 0.11 officially comes out.
Adding a pageinfo object
Because timestamp checks are going to be done separate for content and templates, I've decided to make a pageinfo object that grabs necessary information about a page and throws it in $gCms.
Why is this good?
People have been asking for a long time now how to override the title, alias, etc of a page from a module. You'll now be able to do this. More importantly, it keeps the SQL queries low and still allows for separate caching of templates and content.
What might break?
Anyone that might've stuck their own code in $gCms->variables['pageinfo'].
Prettier module api URLs
This one hasn't been started yet. But, basically, links to the module API is U-G-L-Y! They've always bugged me and I'd like to fix them up a bit. Was thinking of taking the id, action, and module name and compressing it a bit. Something like index.php?mact=News|1|detail, where you need the module name, id and action all in one shot. After that, then regular parameters can be displayed as normal... or be further compressed to something like index.php?mact=News|1|detail&1params=name|value|name|value
Why is this good?
Did I mention the URLs are ugly yet? Plus, I figure it's a logicall progression to a more RESTful architecture for modules.
What might break?
Nothing. All of these changes will be done before stuff is handed off to the module API. That's why you're using it in the first place, right people?
Anyway, these are the things that are delaying 0.11beta2. And when it does come out (probably end of this week), it will need some SERIOUS testing, because I did touch a lot of files and might've missed something. The code is solid enough now that I can probably merge it back into the trunk sometime today and the dailys will start having it. But, keep in mind, that it's far from stable, so only use it in a testing environment.
Thanks for everything. We'll keep pressing on to make this the best open source CMS out there, even if it's bit by bit.
Looks very good al the progress that is being made for the upcoming release. Keep up the good work. I will wait for the next release to implement it at one of my clients sites...
