CMSMS | CMS Made Simple

As you all know by now, CMSMS 2.0 development is now if full swing. Both calguy and myself have been hitting the code pretty hard over the last couple of weeks trying to finish it up and get a beta ready to go. While there is still a lot to do, I’m starting to see the end in sight.

A few random folks have asked about helping out with development of 2.0, which I love. However, being the control freak that I am, I’m a bit worried still about giving the world free reign on subversion commit access. A few months ago, I discussed using git for core development. Yes, I still use this model for my 2.0 work and can’t imagine switching back to pure subversion. I can be as A.D.D. as usual by having scattered branches of the various things I’m working on, and only commit them back when I feel stuff is ready.

Anyhoo, github has gone live. This is pretty much the ultimate geek social network. It allows you to setup your git respoistories to the world. Better yet, it allows anyone else to essentially “fork” that repository, make their changes at will, and easily alert the original person to take a look at your changes. It’s terribly brilliant and REALLY useful.

I push the CMSMS code up to git every day or so from my personal mirror of the current svn repository. It’ll usually be up to date. If I know people are working from it, I’ll make sure it’s always up to date within a few hours. The main repository is located here. Fork to your hearts content, people.

So, do yourself a favor. Learn git. Use git. Love git. And once you wrap your head around it, use github to make those wild and crazy changes to the CMSMS 2.0 code and tell me about them. The proof is in the code, my friends. Get coding!

Want to seriously be amazed at the power of git? Read this account. For some good links (even though there is a ruby spin), look here.

Enjoy!

Bookmark to:

Just because the blog has been deserted doesn’t mean nothing is happening. About 3 weeks ago, I got myself into a position where I can resume the 2.0 development cycle. Not only that, I’m starting to get to enjoy all the work I did in the beginning of cleaning up and moving code around to make a more consistent API. New features are falling into place pretty quickly and I’m making some rapid progress.

Some highlights of the last few weeks include:

* Fixed the issues everyone was having with the installer. It’s ugly, but it works.

* Added the hierarchical permissions editing for content. It still needs to be added in a few more places, but it’s a good start.

* Start adding a test suite for things that I’m working on. It’s by no means complete or even covering a major portion of the code, but it’s the direction I’ll continue down as I develop.

* Removed xajax totally from the codebase and instead made my own version that’s entirely written using jQuery. It does just what I need and nothing more.

* Added active flags to stylesheets and removed them from templates.

* Removed the built-in print functionality. It was ugly. Use print stylesheets.

* Added methods to make sure all tables created by the api make proper utf-8 collations

* Redid a lot of the Events system. It’s now easier to create and use events, and also allows for attaching to events on the fly instead of having to register in the database.

* Redid a lot of the module api. Moved the tabs to their own class. Removed methods that weren’t really used. Moved the wysiwyg and styler methods to their own subclass. Added a backwards compatibility layer for older modules that still needs some work to be fully functional.

* Created an acts_as_list dropin for the ORM system. This basically means that modules (or core items) that want to be ordered can add 2 lines of code and one field to the database and get a ton of functionality for ordering and reordering items.

* Changed the parameter sanitization methods in the module api to use the new stuff built directly into php 5.2+.

* Rewrote the menu manager to use nested templates. This basically means that menu manager templates will be MUCH easier to understand. It also means you can use different templates (or options) for children if you’d like.

* Started a brand new blog module which will be included in the default installation. It will basically have all the main blog features that people ask for and should allow CMSMS to be a viable replacement for those people use Wordpress as a CMS. This also allows me to test that all the changes to the module api are good.

* Moved all module templates to be administered in a central location. Not only that, but multiple templates for the same function are now supported by default. Modules no longer have to handle templates themselves, instead they just register the template on install and are good to go.

Needless to say, it’s moving right along. I still have no solid date for a beta, but I’m shooting for a couple of months from now. As long as I can continue at this pace, it shouldn’t be a problem.

Bookmark to:

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…

Bookmark to:

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….

(more…)

Bookmark to:

Needless to say, I’m a bit frustrated. Take a look at this review…

Very clean and simple CMS. Editing stylesheets and templates is a bit awkward, but after some time creating your own stuff, one can get used to it.
The quality of the user-submitted modules is abysmal. Many of them are fundamentally flawed and their PHP code is often plainly wrong.
If you avoid 3rd party modules, CMS does the job very well.

This comes from our page on opensourcecms.com, which is pretty much the largest pusher of traffic to our site from the outside world. A lot of our new users find our name on the list and check us out. And this is pretty much the first thing they see now.

The developer’s forge is a great idea, but it almost seems like it’s hindering as much as it’s helping. It’s not the first time I’ve heard this complaint, so we as a group need to try and figure out what we can do about it. Whether it requires a more strenuous testing/acceptance procedure (which we don’t really have the manpower to do), or if we just only approve projects that we now will be done right… well, we just don’t know.

Any suggestions? This needs to be corrected or it will become a downfall of this project. And I refuse to let that happen.

Bookmark to:

CMS Made Simple is gladly joining in the gophp5.org mission. On 5 February 2008, many PHP projects, including us, will not be releasing any more versions that will be compatible with anything less that PHP 5.2.0. This is to help push ISPs into supporting php5 finally… which has been out for 3 years already.

In actuality, we’ve already said that CMSMS 2.0 will only support php5, but this seals the deal on a version number (5.2.0) and also gives us leverage for this decision. CMSMS 2.0 will also be coming out before that date, but that just means we’ll be a few months ahead of the curve.

If you’re having trouble and worrying about a host supporting future releases, then you should probably check out the list of hosts on this page and get your migration plans ready.

Thanks to the folks at gophp5.org for giving us a reason to finally push php acceptance in forward and positive motion. It really is THAT much better that php 4.

Bookmark to:

As you might have noticed dev.cmsmadesimple.org hasnt responded for a while. We have small problems with the server and are now moving it to a new server.

While the move is in progress forge and svn will be down, we’ll let you know the moment we get the server back up.

Hopefully this wont take too long.

UPDATE: Everything is basically up. Translation center hasn’t moved yet and neither has email. A few smaller things related to cron jobs haven’t either, but for the most part everything for devs and end user should be functional. Thanks for your patience!

Bookmark to:

Just wanted to make a quick comment about the number of releases in the last couple of weeks. We’ve basically had 2 major security releases in a matter of a week, and I’m sure that raises a red flag with some of the more established users.

I just want to emphasize something… this is a good thing. Sure it takes you several minutes to update your sites to the latest version and there isn’t an automated way of doing that yet. But as we gain users and gain popularity (very, very quickly I might add), more and more people are banging on the system and deconstructing it… finding these great obscure bugs that some hacker might’ve found first. And I make sure that we as a group jump on them as soon as I can. Instead of just sitting on them and waiting for a bunch to come in and bundle them up like Microsoft does, the group does all they can to get a new release out and get the word out quickly. This has become a philosphy for us and luckily all of the devs support it.

Annoying? Sure. Responsible? Definitely.

We’re trying out best to make a great, safe product with the little team that could. And sometimes this is the best we can do.

Thanks for you patience! Someday this gig will be fulltime for us and we can put a lot more time into making this the great app it should be.

Bookmark to:

Yesterday we held a developer conference in IRC. I’ll post a transcription of it as soon as I can get it together, but here is the rundown…

1.1
We are going to do an rc3 version. This is mainly because of some translation issues (mostly in French for some reason) and also because TinyMCE wasn’t in the rc2 build (my fault). The idea is to release rc3 today, and then have 1.1 out in the middle of next week. We just need some quick user testing to make sure everything is correct now.

Dev Team Additions
ThomasM and Reneh (both of their IRC nicks) have been added to the dev team. Both have been a great help to the cause, especially on IRC. We will update the About Us page soon. We also realized that DeeEye isn’t on the About Us page either, so we need to correct that.

2.0
The dev team is committed to finishing up 1.1 and moving that into maintenance status. At that point, the trunk will be changed over to the 2.0 code and the others along with myself will start working on it. While not said in the meeting, I’m still hoping for a beta in the September timeframe.

Forge Rewrite
As stated previously, I’m in the process of rewriting a simple gforge replacement. I just gave a quick overview of what is there and what is needed for launch. Hoping to beta that in about 2 weeks.

Dev Team Meetup
This was kind of the big topic we wanted to discuss. Basically, the dev team wants to finally meet face to face later this summer. We’ve set a date of the weekend of September 8th in Copenhagen, Denmark. We’ve chosen this location because 1) we have a team member there who has an apartment we can do some work in, and 2) because it’s pretty central to several people on the team. Of course, for those of us in North America, it’s pretty darn expensive and will probably require some fundraising, but we’ll get there. Luckily, it’s only 3 of us.

Plans for what we’re going to do while there haven’t been fleshed out. I’m hoping for a decent social/work mix, but it’s going to be kind of up in the air in order to keep everyone content. Though, it does seem like the 2.0 beta will hopefully be poking up it’s head around that time, so there will probably be stuff to discuss/work on.

Conclusion
Another productive meeting. We took right around the allotted 2 hours and got a lot accomplished. We agreed that we wouldn’t probably meet again until after 1.1 is released and it was time to start figuring out the 2.0 duties for the devs. The transscription (with some email addresses and urls removed to not promote spam) can be found here: http://cmsmadesimple.org/uploads/devmeeting-2006-06-06.txt

Bookmark to:

All good developers using the CMSMS know how flexible it is and easy it is to develop a good website with solid design and good functionality. One caveat of the dilligent work we put into making websites is that 9 times out of 10 the client wants to take a stab at making the changes themselves. This is a major selling point for people, many of then used to phoning up a web company, only to request a few changes, wait forever for the work to be done to the right standard, meanwhile their own deadlines are shifting and bosses giving hassle wanting to know what is going on. Eventually when an invoice comes in the door in exchange for the hassle, they will only jump at the chance to take this painstaiking process out of their work day.

The important part to know about developing a site with the CMSMS is that the site isn’t done on launch day. The training element is crucial to the successful website. Many days spent on validation and good code can be wrecked by someone in the client’s company copy and pasting from Front Page, or Word, or some other horror that has been imposed on us all. This can invalidate the good put into the site and in the end affects your own reputation as a developer.

It is a good idea to think of the CMSMS not from your own familiar point of view of it, but from the client’s noobie look at the back-end. Simple things like restricting their access to the really important (and dangerous) items such as custom content blocks, templates, stylesheets, php code etc can save alot of grief and questions in the long run. The more comfortable a client is with non-technical areas of the site and the less bewildered they are at the total package, the more eager they will be to make an effort at making changes without worrying about ‘breaking’ something.

Compliant standard editors (we use x-standard as a default) are helpful to clean up bad code inserted from the above mentioned offenders of bad code. But added to this, a small user manual is often helpful. Take the main important sections of the site that a client will be using and put the process clearly down on paper. Numbered lists of what to do in a step-by-step basis, along with screenshots helps guide them through editing or adding pages and images. This gets rid of the fear factor often seen by clients facing an imposing admin panel.

Taking the time go sit with them and go over the manual helps build your relationship with the client, adds to their own assurances that they will not ‘break’ the site and incur the wrath of their respective bosses, and lets them know they haven’t been left on their own to fend for themselves. In our own experience as much as a client wants to ‘do it all all by themselves’, when the time comes to make the leap, they tend to hesitate on actually pushing the ’submit’ button. A little hand-holding in the way of training goes a long long way to the future success of the website.

Bookmark to: