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.

It's been a while since 1.1 came out, and we have taken the time to fix as many of the issues that came up as we could. This release should solve many of the problems people encountered with the 1.1 release, namely: - The News module permission - News module pagination issues - Various issues with TinyMCE - Some over zealous input parameter cleaning - Fixes to the umask test and global umask settings - Fixes for postgres installs - Rationalization to the order of the submit/apply/cancel buttons - Lots of other little stuff. The files are available from the download page, along with diff releases to allow you to upgrade your 1.1 site easily.