Introduction
CMS Made Simple is the content management system that I use to run my web site. It comparison with some of the other content management system out there such as WordPress, it isn't as popular. However, it may just be the most powerful. I used it because it is easy and customizable. Is it perfect? Of course not, but it is certainly one that I have a lot of expectations for.
It is open source so improvements are being made to it every day. Modules are being created expand its list of features. I have even written some modules for it. In fact, below are the modules that I have written specifically just for CMS Made Simple. Expect more to come in the future.
Modules
These are all of the modules that I have written for CMS Made Simple. While the list right now is small, expect it to get larger in the future. To learn more about each of the module, click on the link for it below:
How to Help
If you like to any of these modules and want to help, you are more than free to do it. The only thing you need to do is go to CMS Made Simple and sign up for a free developer account. Once you have done that, go to the development page of the module you want to help build and request to join. Once you are approved, you should be able to have commit access to the Subversion repository.
Development Guidelines
Like everybody else, I have my own strict guidelines on how the modules are to be developed. Using Subversion is a requirement for me because it provides version control and an easy collaboration process most of the time. I gladly accept any help but when you are developing, please follow this guideline.
Phase 1:
Phase 1 is just the setup. In this phase, I will create the development branch for you to work on. All of your development should go to this branch and only this branch. You should not be making changes to anyone else's branch, tags, and especially the trunk.
Since I will take care of the branch creation, all you need to do is to checkout your branch via Subversion. That can easily be done with the following command:
svn co --username [developer] http://svn.cmsmadesimple.org/svn/[module]/branches/[yourbranch]/ [path] svn co --username [developer] http://svn.cmsmadesimple.org/svn/[module]/trunk/ [path2]
Be sure to change "[developer]" to your username in CMS Made Simple (example: duclet), "[module]" to the module you are developing (example: dlsupport), "[yourbranch]" to the name of your branch (example: dev), and "[path]" to the path on your filesystem where the checkout will be located. The second command, you are creating a checkout of the trunk so that you can later merge your finish work into it.
Phase 2:
In this phase, you should be developing the module, testing it, and making commits to the repository as needed. If you look at my work, you will notice that I try to keep the code as clean as possible. So while I don't care how you code it, please keep it clean and keep your syntaxes as close as possible to mines. That means, no spaces between if statements and the link with curly braces directly following the function closing parenthesis and always using curly branches in a for loop, etc.
Another thing I do a lot of is commenting my code. Heck, I would way that if you do a line by line count of comments and code, I would say that the ratio would probably be 60% code to 40% comment. My feelings on things is that no matter how you code it, it is best to have an easy to understand comment that can quickly let someone else know what this block of code does. So with that, please, comment the code appropriately.
Once you are done developing, test your code on your site or some kind of development branch. Be sure to test all of your added functionalities as well as existing functionalities that your modification touches or can affect. It is extremely important that you make a lot of effort to test your code. Even so, don't worry too much if you missed something because that is what experimental releases are for, to test new code. Only when something is truly stable can it be added to the stable release and since we have everything stored in Subversion, we can always revert back if something truly bad happens.
Phase 3:
To me, this is an important phase since it can have dire consequences if it is not followed exactly. While you can do what you want with the previously phases, this phase, you MUST follow the instructions here step for step.
This is the phase where you merge your changes into the trunk of the module. However, you should only get to this phase if you have completely tested your code and make sure that nothing bad is going to happen. Once you are ready, follow these steps:
First, you will need to get the updates from the trunk and merge it into your branch so that you have the latest code from everyone. Do that by executing the following commands:
cd [dev-branch] svn update svn ci -m 'Final commit before merging to trunk' svn log --stop-on-copy [log-of-changes-made-to-your-branch-since-it-was-created] svn merge -r [from:to] http://svn.cmsmadesimple.org/svn/[module]/trunk/ . --dry-run [merge-status] svn merge -r [from:to] http://svn.cmsmadesimple.org/svn/[module]/trunk/ . [merging] svn ci -m 'Merged from /trunk -r [from:to]'
What you do is is first commit all of your changes to your branch. Then you should look at the logs and see when was the last time you merged changes from the trunk to your branch. If it is the first time, use the revision listed on when your branch was created for the "from" revision. Otherwise, you should use the revision number of when it was lasted updated. For example, if you had previously merged the update from the trunk from revision 56 to revision 78, the "from" revision you want to use now is revision 79. The "to" revision should be the revision that is listed when you did the "svn update". The dry run should tell me what will happen when you actually merge. If everything looks okay and there are no conflicts or a lot of them, merge the changes from the trunk to your branch.
Do not however, commit the changes when you are done merging. Instead, you should now test your code with the updated code from the trunk if your development site. Put it through a strict test and make sure everything is working. When you confirm it is, now, commit the trunk update to your branch. Be sure to include the revisions used during the merge so you can use it for reference later on.
Now you are ready to merge your changes to the trunk. Use the following command:
cd [trunk] ./runme.sh 1 svn update svn log [log-of-changes-made-to-the-trunk] svn merge -r [from:to] [dev-branch] . --dry-run [merge-status] svn merge -r [from:to] [module] . [merging] svn ci -m 'Merged from /branches/[dev-branch] -r [from:to]' ./runme.sh 2
The first thing you do here is to make sure that you are the only one working in the trunk right now. When you run that first command, if it is sucessful (meaning that you successfully lock the file), then you are free merge your changes. However, if it failed (another user has already locked it), then you should not be doing anything until that user unlocks it. If you see that it has been a long time since the user lock it, check in with that user to see whats up.
The next step, you do things exactly like it was before when you merge the trunk changes to your branch. When you are done merging, commit your changes and then unlock that file so some else can work on it later.
File Releases
When a module is ready to be released to the public, it will be released the first Friday after the release is ready. However, if you don't want to wait until Friday, you can always check the Subversion repository to see if a new release is ready. Be warned though, while the stuff you look at in the trunk should be stable, it is not guarantee and more changes could be added after you check it. Your best and safest bet is to wait till that Friday to get the release.
There are a couple of ways to get the release. The first is to get directory from Subversion. That can be quickly done via the following command:
svn export http://svn.cmsmadesimple.org/svn/[module]/tags/[version]/
Just replace "[module]" with the unique name of the module you are trying to get and replace "[version]" with the version number you want.
The other alternative is to go to the module web site on CMS Made Simple and download it the File area. There should be three type of files for you to download. You can download it either as an XML file (largest in size since there is practically no compress), ZIP file (middle in term of size), or GZ (smallest in terms of size). Since there is a 10MB limit to what I can upload there, so if a module ever gets so large for a particular type of file, it won't be available. However, 10MB is pretty large for a module so I hope it will never get to that day.