For the first time seven members of the core development met in person. Copenhagen, Denmark's capital, was the host city of this meeting. Core team members attending were (from top left): Samuel Goldstein (SjG), Tatu Wikman (tsw), Daniel Westergren (westis), René Helminsen (reneh), Morten Poulsen (Silmarillion), Ted Kulp (Ted), and Keith Lauchlan (Utter). We got together for three productive days to plan the future of CMS Made Simple. Here's an overview of what we discussed.

Organisation

First up we looked at transforming the organisation around CMSMS to give ourselves a more formal structure, enable applications for grants and loans and put the whole outfit on a more stable footing. Many other open source groups have formed non-profit foundations and that's the model we're looking to. Responsible: Samuel and Keith

Promotion and Marketing

Given how great CMSMS really is we're way behind with getting the message out there. Keith and Daniel will be far more rigorous at targeting the online and print-based press with articles and information on our product. This involves becoming more aware of who our target audience really is and pushing CMSMS at them more aggressively. One way of putting CMSMS on the map would be to put together a book with a publisher like Packt. Since we're now one of the finalists in the Packt CMS Awards this may be a real possibility and will be pursued over the next few weeks. Other topics touched on were:

• a much better themes site (Tatu will work on this) and a competition to design the new CMSMS site (already launched)
• better screencasts of important tasks on the site, as well as new features in new versions
• better feature list on the site (completed)

Responsible: Keith and Daniel

Documentation

• Ted joined the documentation team for taking the lead in core and module developer documentation.

• We will move the documentation from the wiki to CMSMS pages. We will also make use of the Comments and Questions modules. This way it will be properly centralised and easier to locate. Only members of the Documentation Team will be able to add and edit articles, but anyone can make comments to improve the documentation. This way we keep better control of what is in the documentation, while still letting users contribute. We're still working on how the documentation may be multi-lingual in this system. Most likely only English, German and French will be available until CMSMS 2.0 makes multi-lingual sites easier. (Daniel)

• A new print functionality will be written that can combine pages into one page and export them to PDF. This should eventually allow for the creation of screen and print versions of docs right out of CMSMS. (Morten and Ted).

• More screencasts will be produced about how to accomplish different tasks and to present how CMSMS works for new users. All these and any other forms of media used to document the sitebuilding process could be included on CD with the book. (Tatu)

Documentation on the site will eventually be separated into 4 areas:

• FAQ
• Tutorials
• Handbook for everything
• Developer documentation (API, module writing etc.)

The new documentation structure should be up and running within three weeks. Responsible: Gunnar

Training

There was a fair bit of discussion around how to organise CMSMS training and it was felt that we first needed to do some fairly extensive market research to determine who wanted it and where in the world they were likely to be. Amongst the suggestions were that training could be dispensed in a variety of ways such as at annual gatherings or even regularly from specific locations (say, once a month in London etc.) It was also suggested that we could operate a sort of franchise structure so that 'approved' CMSMS developers or users would be recommended for training using specific training materials developed from the documentation when it was finished. On a more advanced basis, companies could be offered commercial training packages for developers and users. A poll will be put up on the CMSMS site to gauge the level of interest for this although nothing too ambitious is likely to be undertaken until the documentation is ready. As with many aspects of the discussion it was felt that the organisational and promotional aspects of elements like training would become simpler when/if there was a foundation group. This is a more long-term project.

Themes site

As was mentioned earlier in this article, the Themes site is seen as an important contributor to the success of CMSMS. The discussion centered around how to structure the site more like the one at www.oswd.org so that themes could be better categorised, previewed, rated, commented upon and downloaded. Responsible: Tatu

Modules and the new forge

The present forge is too inflexible and needs rewriting. Samuel is creating the new Forge in Ruby on Rails and it will hopefully be complete by the end of the year. A QA team will be responsible for testing and overseeing modules and projects Some of the new and improved features will include:

• modules can be recommended: yes/no set by QA team (with version)
• a "works for me / doesn't work for me" feature (along with CMS version, module version, PHP version and comments) submitted by users
• comments and ratings: specify which version of module comment and rating applies to. Admin has delete button for comments
• ability to have a matrix or some other means to say what version of CMSMS a module works with
• ability to set modules as outdated if they haven't had activity in a certain amount of time
• Optional field for next planned release
• Modules can be tagged and categorised with a tag cloud for project category
• news, with RSS
• most recently released modules, with RSS
• a subscription feature for bugs, features and projects

In addition, there'll be changes to the admin of a CMSMS install to reflect these improvements:

• ModuleManager will show only modules compatible to installed version
• ModuleManager will show module name, module version, last release date, recommended (or not)

Responsible: Samuel

Translations

• The translations will be stored in a database, rather than in files like now. That will make it possible to dynamically update translations from the admin panel without having to wait for a new release of the core or a module.
• The changelog will be split up, so that it's easier for translators to see when the changelog has been updated and needs translation.
• It will be possible to change translations locally, i.e. for a specific site. When the translation is updated it will not overwrite the local translation.
• Ways for translators to be notified when there are new translations to be made, on a module-per-module basis.
• Sorting language strings by new, updated, all etc.
• Re-usable language strings from the core (submit, cancel, apply etc.)
• More tweaks to make life easier for translators
  

Responsible: Reneh

CMSMS Version 1.2

1.2 is going to be the last supported 1.x version. After 1.2 is released there will be a feature freeze and only bug and security fixes will be released. From now on all development will be focused on version 2.0. Responsible: Robert

CMSMS Version 2.0

There's been plenty written about the next version of CMSMS. These are a few extra ideas we discussed. One idea was to split the language files so as to use less memory, not having to load everything, like admin/front page. We also thought admin users can create new menus and assign to user groups. The admin theme will be an easily editable xml file.

• Module upgrade warning + automatic backups
• Roadmap for 2.0 is
• early-Dec: pre-beta
• Dec 20: 2.0 beta1
• Jan 15: Final beta
• Feb 5: RELEASE!!!

Responsible: Ted

The End

We spent a couple of hours bug-busting and then went to the pub...

The fastest of you noticed the defacement of cmsmadesimple.org site several days ago. The site had been defaced by a script kiddie. The actual script that had been used was r57shell (google). Its a litlle tool one can use to upload / download and query stuff from the server. The script had been there for a while and gone unnoticed as it wasn't used for anything else than removing the log entries from that time :/ One thing is certain, the hole they have used is old, it looks like the FCKEditorX filemanager hole was used, but we cant be sure. We have checked that the release files are intact, and as far as we know no data has been compromised. We are still trying to dig more info about this incident, and are in the process of securing the server up a notch. Sorry about the problems.

Development discussion for CMS Made Simple is still sort of scattered. Generally, the devs hang out in IRC and bounce ideas off of each other. Easy enough. However, if everyone isn't around and it's one of those ideas or decisions that really needs some conversation to flesh out, it usually drags out for days in a series of "@later tell" conversations. Again, using git as a bit of a guinea pig, I'm interested in their development model. Development discussion is focused into one mailing list. New ideas are sparked up, patches are constantly submitted and critiqued, and all in all it seems very productive. My idea is to make something similar for development. Sure, quick ideas will probably be asked, agreed upon and committed in IRC before anyone could even open up an email client... but that's not really the point. The point is to have a place for the long conversations, the fleshing out of ideas, and contribution by other people. There is another motivation as well. In my quest to de-centralize the CMSMS development model, this gives a perfect place for people outside of our "inner circle" (read: commit access) to contribute their patches. Using either svn or preferably git (read this for more information on that), patches can be submitted directly to the mailing list and VERY easily discussed, critiqued, and rolled in. It allows the community at large to handle patches instead of getting emailed to individual people and forgotten about. This is also a place for people to suggest features, but to a certain extent. Prepare for constructive criticism or asked to please submit a patch. Though, don't worry, the tone will never get nasty... it's just not the way we roll. Mailing list information lives here and anyone is welcome to sign up. However, keep in mind that this is a focused mailing list. If you contribute to low signal to noise ratio, you will have your posting privileges revoked. As a side note, I've moved the announcements mailing list over to mailman as well. Anyone that was subscribed was re-subscribed to the new list and properly spammed with the information. ;) Sorry about that. At least they should work again, as I believe they were broken in the server move several months ago.

I'll warn everyone now that this is a fairly geeky post. If you're not into core development, source code management or *gasp* command line... feel free to run screaming. Still here? Excellent. Come, let's geek out a bit. What is Git? Git is a source code management system. Though, if you read it's description, it doesn't say that. Don't listen to them! It's a subversion-like system for managing source code. It was written by Linus for the Linux kernel after their fallout with Bitkeeper. It is similar to Bitkeeper in some ways, but it's very unique as well. Git is very unix-y still. Just like CVS and Subversion are by default. It's still too new to have a lot of fluffy GUIs like Tortoisesvn or the like. However, for a regular console jockey, this isn't an issue. Uhh... Why? But you already have subversion. It works well. You've been using it since CMSMS first started. Why would you want to use something else? I totally agree. Subversion is still the right tool for the CMSMS universe. It offers the lowest barrier to entry and reliability. However, I don't necessarily think it's the best tool for myself as a developer, and I have several reasons for this.

1. I can branch as much as I want. Branching and merging is not painful. Not nearly as painful as it is in svn. In fact, branching is so painful in subversion that I barely use it... and in a large scale system with a lot of users, that's not a good thing. Committing everything to trunk even if it's broken is just wrong.
2. It pretty much seemlessly integrates with svn. There is an added piece in git that allows you to basically push and pull from an upstream respository. This basically means you can use git on your local machine and not screw it up for everyone else. You branch/merge/etc to your hearts content, and then push it all up to the subversion server when you're done.
3. It's distributed. The more people that use this, the more people I don't have to give subversion commit access to. It's very painless for me to get patches via email and merge them in and commit to subversion. It means I can watch the patches coming in and make sure that we're not allowing junk to get into the core. And end users can screw around with the code as much as they want... it never has to touch the main repository.
4. It's disconnected. I can branch and merge as much as I want without being online. For a person like me who lives on a laptop and codes whenever they get a free moment, it's essential. No more waiting to get online to switch from trunk to 1.2 or another branch, etc. I can even diff against another version without touching the internet... this is huge.
5. The history is totally pulled off to everyone's machine. The more people that use git, the more backups we have of our project history. Everytime you clone, you have the whole history on your local machine. And distributed backups are the best kind.

Anyway, for those who don't know, I develop almost entirely on my Macbook Pro. I run apache/php/mysql locally, and usually run several versions of CMSMS at once. I'm obviously a perfect test case for this, and other results may vary. More after the break.... I'm intrigued. Let's see some examples. I installed git from MacPorts (sudo port install git-core +svn). You can do this any way you want... from source, prepackaged binaries, apt-get, etc. Take a look at http://git.or.cz/ for details on how to get it setup. Now get yourself to a command line. First thing you're going to want to do is setup a local checkout from the CMSMS core respository. git svn init -T trunk -t tags -b branches http://svn.cmsmadesimple.org/svn/cmsmadesimple cms-git This will create a cms-git directory and have all the proper pointers to the svn respository in it. It's also empty still. Now you need to pull down some data. Normally you would do: cd cms-git git svn fetch That would pull the whole repository locally. Branches, tags, etc. However, git-svn doesn't seem to like a repository move I did way back at revision 2719. Instead, you should pull the data for revision 3000 and above. Actually, I recommend 4000 if you're not a purist... it's more than enough history for anyone's needs. cd cms-git git svn fetch -r 4000:HEAD Then you wait. And wait. When it's done, you'll have a nice snapshot of the CMSMS core development. git branch If you do this, you'll only see master listed. Without getting into explaining git entirely (and there are much better texts for this), let's just say that's a local branch. That master branch automatically points to the trunk of your subversion repository. Let's say you want to work on 1.2 instead. You do something like, git checkout -b 1.2 branches/1.2.x This will do 2 things. First it creates a local branch pointing to the 1.2.x branch in subversion. It will then "checkout" that code into the local directory. So now you have an up to date version of 1.2.x ready to be developed on. What next? Let's say you're going to work on a new feature or bug fix. The best way to handle this would be to make a new local branch and work in that. That way, if you want to work on several changes simultaneously and not make a big mess. In this example, we'll say there's a bug in the admin panel login procedure. It's bug #1234 in the bug tracker. git checkout -b bug_1234_login_problem 1.2 You're now making a copy of the 1.2 local branch and making a topic branch specifically for bug 1234. You can change things to your heart's content. If you commit, your changes live in that branch and don't pollute anything else. You can commit as much as you want and no one has to see it. If you decide you hate everything you've coded, you can reset or toss the branch away or whatever you'd like. No one has to know that your code was absolutely dreadful... and there's no reason to every push broken code back up to the svn repository. Ok, you've fixed the bug. It was a one-liner in admin/login.php. Now commit it. git commit -a -s Just like subversion, an editor will pop up and you can explain what you did. You'll notice that an extra line was added that shows "Signed-off by: Ted Kulp <ted@cmsmadesimple.org>" or whatever your email is. The -s did this, and it allows you to have an audit log if you're passing patches around. It's a good habit to get into and I highly recommend doing it for every commit. Ok, you're branch is now good to go. Now what I would do is now merge this branch back into your "1.2" branch. This way, you can be sure that it's being applied cleanly before you either push it back to the svn repository or send it out via email to a maintainer. git checkout 1.2 git svn rebase git merge bug_1234_login_problem What you've essentially done is go back to the master 1.2 branch (which should match svn), update it with the latest changes from svn (if there are any) and then merge in your changes from your topic branch. If the merge caused any conflicts, you can easily fix them now and now that when you apply these changes to the upstream repository, they'll apply cleanly. Now, if you do have commit access to the repository, you can just do the following. git svn dcommit This will apply any changes to the repository and anyone using svn will be none the wiser. However (and here's the beauty), if you don't have commit access, then you can easily send out a patch via email to the maintainer. git format-patch -M -n -o patches/ origin git send-email --to ted@cmsmadesimple.org patches rm -fr patches Now those patches are sent directly to the maintainer for easily integration into the source code. It's a beautiful thing. Conclusion Git isn't for everyone. It's not even for the masses yet. It's a specialized tool that requires a certain mindset to even use. But once you "get it" you wonder what you did before. Also, this isn't the end-all of tutorials for git. Look below for some great links on getting started with it. If anyone is going to do any major core development, I'd like you do at least examine this option. It allows us to not give commit access to the free world and allows for great amounts of experimentation by the end user without interrupting other users. It's a very viable solution, so please at least give it a look and see for yourself. Enjoy! Important links:

• http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
• http://utsl.gen.nz/talks/git-svn/intro.html
• http://www.kernel.org/pub/software/scm/git/docs/everyday.html
• http://git.or.cz/

CMS Made Simple has made it to the final stage in the Packt CMS Awards! And that in both classes where CMSMS could be voted for: Overall and Best PHP Open Source CMS. Voting is now open until October 26th for the five finalists in each category. Please vote for CMS Made Simple and help spread the word! Thanks for everyone who voted to take us this far! The link to vote: http://www.packtpub.com/article/2007-open-source-cms-award-finalists

Yes. You've read correctly. There will be a 1.2 release of CMS Made Simple before 2.0 comes out. It should be in beta within the next couple of weeks. 1.2 will attempt to address some of the major glaring features that people have asked for and will be the LAST release of the 1.x series of CMS Made Simple (except for any security flaws that come up). Beta testing will be exteremely important in this release, as we don't intend to have a 1.2.1, and with the exception of security fixes, we'll avoid it at all cost. We need to focus our efforts on 2.0 from now on. We expect, and hope that the user community can once again contribute with testing of this release to make it stable, and usable. Here are the major things that will be in 1.2: a) Frontend Wysiwygs Some modules (News 2.5) support text areas in the front end. Modules will now be able to provide a wysiwyg on the front end instead of just a plain text area. b) News 2.5 Has an 'extra' field for additional information (maybe an image) Supports frontend article submission c) Allow gid == 1 (the admin group) to have all permissions, not just uid == 1 (The first user) d) Fixes to pagination issues (particularly in the admin log) e) Defaults for new pages There will be a new page or tab in the global settings menu that allows you to set the defaults for newly created pages (set the default metadata, cachable, show in menu, etc). f) A security enhanced content editor People without 'Modify Page Structure' permission will not be able to change the 'show in menu', 'page alias', or active flags of a content item g) Additional Editor Groups Along with 'user' additional editors, you'll be able to select groups as additional editors h) Enhancements to debug mode to assist with debugging issues i) An enhanced module manager that will not allow you to install modules that are not compatible with your version of CMS Made Simple.... and that will 'optionally' only show the latest version of a module. j) A replacement file manager k) More batch operations in Content >> Pages. Including the ability to export pages to pdf. l) Batch operations in Layout >> Templates, and Layout >> Stylesheets As well, the development team as been making an extra effort to close off some of the glaring bugs in the forge. We can't get to them all, but hopefully many of the bigger ones can be closed for 1.2 The feature list of 1.2 is pretty much locked in at this time. We've had extensive discussions about the topic over the past few weeks, and this is the set of features we thought we could implement in a reasonable period of time without dramatic overhauls to the way things work, so additional feature requests are probably off of the table for this release. As you can probably see, this will be a considerable step forward for CMS Made Simple, and its stability is paramount. I'll keep you posted, but would like to take this time to call for volunteers for beta testing. Our testing team can only do a limited amount, and can't possibly test all the permutations and combinations of problems that you can. [addendum] The beta cycle for this will be short.... 1 week per beta.... and we want to have no more than one or two betas. So please, test, test, and test.... 1.2 would be perfect for all of the sites that are 'in development' but won't be rolled out for a while.