EngineCMS is a CMS that i’m working on developing to fill a specific set of features that I haven’t been able to find in other systems.

1. Use the file system, instead of a database, to store content. This is important so that we can use command line tools to work with the files.
2. Revision control
3. Authentication, Permissions, ACLs against local users (unix auth), built in users (to the CMS), Active Directories Users/Groups/OUs, and IP based authentication.
4. Easily integrate external applications, without resorting to having to use rewrite rules in apache
5. simple ’server’ scripts to handle the rendering and display, providing a robust and stable developing platform. That is, once the rendering engine is developed thats it. All the ‘new’ features will be on the ‘back end’
6. back end, the CMS part, is separate from the rendering engine allowing it to be located on a separate server.
7. system is designed in such a way that no one has to have access to the public web server.
8. Individual pages need to be able to have different themes applied to them, instead of the default theme
9. Fallback — if you specify “images/banner.gif” it will search the current directory for a directory “images” and “banner.gif” inside of it. If it doesn’t exist it will work its way back up the directory tree until it does. Same thing for any file, such as “leftNavigation.php”
10. Easy for people with no web development experience to create and maintain pages

There are some other influences as well, but those are the big ones. I’ve been looking at several CMSs over the years. Drupal and Zope/Plone come the closest to providing what I am looking for, but fall short.

Drupal, currently, doesn’t support ACL properly in version 6 and its been out since February. Version 7 is already in development. A lot of the *core* features i want are in modules that lag far behind the main system. This worries me and makes me think that I will get stuck in an old version of drupal.

Drupal also requires all “addons” to be drupal modules. In some cases there are things that we will want to throw up that will be easy to throw together, but not easy as a module. An example would be a temporary application that might be up for 1 semester, and we only have 1 week to develop it.

Drupal’s revision control is also lacking a bit.

Zope/Plone is a great system. I used it for years on my own personal website and I still use it on the Library Intranet website (until this new system is ready at least). Problem is, everything has to be done via the web interface. You can’t use common commandline tools to work with files. If i am out of town on a 56k dial up, i want to be able to use emacs to make an edit instead of having to use a web browser. This is my biggest complaint about Zope, which kills it for me.

Enter EngineCMS

EngineCMS, for lack of a better name, addresses everything above and is very alpha at this point. I’m currently implementing the authentication system. Once the authentication system is done, which i hope to get done by 8/11/2008 (that might be wishful thinking), the Engine/Front-End part will be ‘feature complete’ and I will be able to start working on the back end.

The back end is where all the actual CMS magic happens. It is where web authors will go to do their thing. The front end is merely what will render the pages that are on the server. Once the front end is done I will begin converting the library’s intranet to the new CMS, by hand, so that I have a test bed for the back end CMS stuff. It will also give me a frequently used, but private, area to debug problems with the front end so that it is rock solid by the time we are ready to move it to live-public-production servers.

Development is being done in PHP, which is something i’ve resisted for years … but it is starting to grow on me. It allows for a lot of neat things without having to develop an actual server, like I’ve done in the past (and like zope still does).

I’ve been wanting to learn ruby for a while now, and I finally had a project at work that seemed like it would be great to learn the basics on. I could have coded and debugged it in Perl in a couple of hours, but it was the last step in a larger project and I had the week to work on it.

Pulled out the fresh Programming Ruby book (Which, btw, I would not recommend) that the library had purchased. Read over some of the example programs to get a feel for the syntax and went to town. 15 minutes later I had a scrip that read in the XML data (a 17mb file, with ~3500 items), spit out some results.

Things that i noticed right away:

• ReXML, the default XML parser for RUBY is horribly slow. By ‘horribly slow’ I mean, you may as well go get lunch while its reading in your data. In Perl that same file loads in less than 1 minute using XML::Simple. In Ruby using ReXML, 8 to 10 minutes depending on machine load. Then, you have to go through the data which involved a couple calls to the ReXML library. Another 8 to 10 minutes.

• ReXML expects all XML transformations to come from XSLT. This is all well and good, i guess. But what happens if you don’t want to, or can’t, use XSL? The DTD for this particular spec does not allow for a style sheet. In fact, if you assign one in the XML the program that reads in the XML file will fail because it does not expect it … so XSL isn’t an option for me.

What do you do if you need to do something as simple as sorting the XML data? Throw it into a Ruby Hash, then sort it.

Ugh.

I plan on using Ruby a bit more, with the exception of XML it seems pretty nice. But if you have any XML projects, you might be better off programming it in BrainFuck than ruby. It would be faster.