Sorry that I've been pretty light on forum posts lately. Life has been busy. My day job is incredibly busy for the next few months and time for CMSMS is getting harder to come by. Anyway, I figured that I should discuss what's upcoming for me as the core team leader and where we're headed.
As some of you know, 1.1 has started development. I started hitting the code pretty hard in the last week or so and laying the groundwork for the changes to come. There is a LOT of work to do.
However, I'm going to lay down some of the fundamentals and changes that were decided on by the dev team (though, I take full responsibility for any flamebait). Some of the changes are drastic, but necessary in order to progress this project further into the realm of the "big boys" out there.
Ok, #1 and most drastic... CMSMS 1.1 is built off of something called ORM. For the non-programmers out there, ORM implements something called the ActiveRecord pattern. It basically allows us to represent a table in the database as an object. That representation basically allows us to map an entire database table to one object and then do things automatically. Things like saving to the database are now done for us, and therefore we don't have 100's of repeated SQL statements littered throughout the code that do the same thing.
However. While I originally wrote the ORM system with intention of it working on both php4 and php5, I've come to find a few bugs in the php4 way of handling dynamic functions and properties. These bugs are marked as "WONTFIX" in the php bug tracking system. In other words... either I dump the code I've written, or we make a hard decision.
I've decided to make the 1.1 branch of CMSMS php5 only. I know it's a hard decision and php4 is still the norm out there. I'm probably taking a risk by doing this, but I'm confident that it's the right choice. Eventually server providers will upgrade. Some already have. And to keep writing buggy code in a buggy system just because the establishment hasn't caught up is just a mistake. I want CMSMS to be a modern, stable system. And trying to get it to run on older versions is getting more and more difficult as we move forward.
As an aside, other systems and frameworks are already making this jump. For instance, mediawiki (as in wikipedia's engine) has made all releases since 1.8 php5 only.
1.0.x will remain in "maintenance" (and therefore, supported) until php5 has made it's way onto more of the major service providers. I'm hoping that this is only about a year or so. Once php5 has penetrated enough of the market, we'll retire it.
Some of the 1.1 changes might get backported to the 1.0.x branch, but chances are that they will only be bugfix type changes and none of the major enhancements.
I'm sure this decision is going to spark controversy and flaming and other downright arguments. But in a year we're not going to care anymore. That's the problem with being in charge... you have to make tough decisions.
Anyway, keep your flames to this thread. *whew* That's out of the way. The rest are good, I swear.
Moving on...#2. The content system has been itching to be rewritten since about 0.9. Well, it's been done (for the most part). The new version of the content system basically works the same, but with the ORM system in place and knowing a lot more than I knew before, it's about 25% of the number of lines of code. It's much less complicated and much more automated. Writing new content types is a LOT easier now. It uses Smarty templates and doesn't reinvent any wheels.
The new content system also reworks how multiple content blocks are handled. Before, multiple content blocks were only good for HTML text. This is incredibly limiting and was put in as an afterthought in 0.7 or 0.8.
Now, we're going to have a system in place to allow different block types to go in each content block. These can be selected while editing the page and not all pages need to have the same type in each block.
We're going to write several different block types for 1.1. The main will be called HTML (this will be default) and basically work like they do now. A WYSIWYG (or none if you have it turned off) for each block. But, we will also add a couple more... markdown text and images are the 2 that come to mind. You will be able to setup a default type for each content block ({content type='image' name='someimage'}) and also be able to lock it so that the block type can't be changed by the end user. This will allow the template designer to really lock the editors into a particular look and particular type of content for each block.
Adding new block types will be easy, and modules will have the ability to do it as well. In fact, we might change the News content type into the News block type so that you're not wasting a whole page on a News listing.
#3. TinyMCE will be the new default WYSIWYG. FCK is bloated and way more than people need to start off with. FCK will be available as an option through the module manager.
#4. Versioning will be in 1.1. It will be included, but will have to be enabled as an option. Basically, that means we will keep all the previous versions of different content, template and stylesheet items and you'll be able to revert to older versions if something happens. The way it will be coded has been worked out, but I have no clue how to handle the interface for this yet. Any ideas are appreciated.
#5. Versioning means that we can then handle a workflow system pretty easily. Though, I'm not sure if this will be in the core, or as a module. Basically, this will mean that editors will be able to make changes to pages, but those changes will have to be approved before they will show up on the site. Again, working out an interface for this is going to be tricky, as will some of the database gymnastics that we'll have to do to make it fast. Again, any ideas are appreciated.
#6. Multilanguage. This will most likely be in the 1.1 branch by default. Katon and I have come up with a nice way to making the multilanguage system a separeate subsystem that other pieces will be able to use easily without modifying their structures too much. He's talking about writing that before 1.1 comes out as an add-on to the 1.0.x branch. I'm not sure of his schedule and timeframe, but he is definitely on board for helping us get it in.
These are only the changes that I know a lot about. The rest of the dev team is going to handling the other aspects of 1.1 and have good ideas as to what is going to show. Things include a permissions system reworking (calguy1000), removing the file and image managers and using rewritten modules instead (silmarillion), and a bunch of other changes. I'm sure they'll chime in when they have more details about the direction and progress.
Anyways, thanks for your patience. 1.1 is expected for late Q1 2007. Expect betas before then... after we figure out how to write the very involved upgrade process. If you have anything to discuss regarding this, please continue in this thread. Try to keep the php5 flames to a dull roar, though.
Thanks!
