PHP


This is a series of post starting here, in which I look at different CMS installations and despair.

At the end there’s only two left to consider, Magnolia and Joomla! And I’ll go for Magnolia first. Simply because I will need to tinker a fair bit with the system, and  Magnolia seems a lot more friendly to a Java developer than Joomla! Don’t get me wrong, I can program in PHP as well, but I’d rather not, and the  Joomla! template PHP is rather cluttered.

As for extensions? This may be a problem for other sites, but I don’t think it will be for this particular setup. Even if so, I can install some WebService stacks parallel to the Magnolia apps and use JSTL and ordinary JSP to serve the content in the templates.

Multilingual content? Joomla! has it, but all too contrived. Doing separate directory structures for separate languages may not be optimal for everyone, but it’ll work for this installation. And I can already see myself doing some templating tricks for the rest.

Joomla! is a runner up, and if the client is not happy with the Magnolia editing functions I’ll have them try Joomla! instead. In either case I think I’ll be happy to work with any of the two systems.

This is a series of post starting here, in which I look at different CMS installations and despair.

Magnolia came in late in my research but I immediately started thinking that I perhaps had found something good. As several other systems it comes with one “community” version and one “enterprise” version, but I don’t mind as long as the feature set isn’t too crippled on the community install.

The Good

  • Easy installation. Two WAR files dropped in and that’s it. Very good. Apparently comes with Apache Derby bundled so you don’t even have to configure a database. Although, more on this later…
  • Stage environment. Two separate installations, one for editing and one public. Very good indeed, although there’s a down side as well.
  • Uncluttered and very good AJAX gui.
  • Easy to editor pages. And easy to understand and change the site structure.

The Semi-Good

  • Multilingual content. It is not supported, but it is officially not supported with an “no, but of course you can do it, and easily” answer.  Meaning most sites will end up with  separate directories for each language, and when you really need one page/many languages, you can actually do it. 
  • No themes. But officially no themes. But very simple templates. This is counted on good in my book as I’ll end up designing the site anyway, starting from scratch with a clean and simple templating system is just as good as a full-fledged, community supported, themeing engine for my purpose.

The Semi-Bad

  • Bundled database. Good for installation but you should really document very clearly how to reconfigure it to use an external database, I can do with Derby but would prefer MySQL.
  • Stage environment. Although the idea is very good it means that you most probably will end up having two parallel applications running, thus cluttering up the site URL’s. This can be solved of course but it takes some tinkering. I was thinking of installing the stage installation on a separate domain instead, so you’d get, for example, “www.mysite.com” and “edit.mysite.com”. I shall have to think about that.

The Bad

  • Somewhat small community. Or I haven’t really found them yet.
  • No 3rd party modules? Is that because of the point above? Or have I missed something?

Conclusion
Very good package. And probably a winner. I really like the cleanliness. And the the easy page administration (saves a lot of support time). I like the templating. On the downside, I’ll be looking for 3rd party modules if I need them and may be forced to write my own, but I would need to do so in any case for any system to a certain extent, so that is only a minor scratch on the whole. Multilingual content? Well, considering the competition Magnolia comes out smelling of roses, I’d much rather take an honest “no, but it easy to do”, than a “yes, but it is rather complicated”.

This is a series of post starting here, in which I look at different CMS installations and despair.

AtLeap is a relatively new CMS from Blandware. Despite it seeming a bit immature, I was intrigued enough to install it simple because 1) it was easy; and 2) it screams “multilingual” at you at it’s front page.

The Good

  • Easy installation for anyone familiar with Java / Ant. For anyone else I image it’d be a pain.
  • Completely server / database agnostic. Impressive!
  • Multilinual content out of the box. Why doesn’t everyone have this?

The Bad

  • Cluttered admin GUI. One big menu with both admin items and real site items? No thank you.

Conclusion
I admit not spending too much time on AtLeap. It is obviously somewhat immature. I imagine it would be a very good base for larger projects with a lot of custom development, you get the goods right at you door and don’t mind writing your own themes and extensions. As it is, I probably won’t have time for it.

This is a series of post starting here, in which I look at different CMS installations and despair.

Many hours were spent looking at systems which for various reasons didn’t even make it to any local installation or if they did, were immediately dumped. They include, but are not limited to:

  • Alfresco. For the life of me I couldn’t find any information on how to change the default MySQL user/password for a WAR file installation. “alfresco” / “alfresco”? No thank you, that’s not an option it’s an insult. Too bad, otherwise it looked ok, and the Spring, Hibernate, Lucene, MyFaces, JSR 168, JSR 170 list together with built in WebService support had been very nice indeed for a Java buff such as myself.
  • Drupal. Multilingual content?
  • OpenCMS. No non-root WAR file installation AFAICS.
  • Liferay. Same as above. Which is a shame, I think I would have liked it. Struts, Hibernate, Spring etc. Plus tones themes and a lot of extensions. Pity, if I get to run on a dedicated server I may try it out.
  • Jahaia. Seems ok, but does not support multilingual content in the community edition. Too bad.
  • Apache Lenya. A bit too immature, but interesting. Too bad my experiences with the Coocon framework aren’t the best. Never the less, I may install and try this one later on.

And on we go…

BĂ„stad Chamber Music Festival wants a new web site. And who can blame them? But naturally it should be a CMS of some sort. Thus the task for the weekend was: Find a decent CMS to use. This turned out to be cumbersome and boring.

These were my requirements when I started:

  • Ease of use. The editors of the site should not have to be more than normal computer users to edit the site. Without any education. A WYSIWYG editor is implicit here folks.
  • Simple to administer. I don’t need a lot o features, I need something which is simple and flexible and clean.
  • Multilingual content. It must support multiple content languages, and still be easy to use.
  • It must be possible to install on any decent web host without root access as I don’t know  as yet how the hosting will be provided. With decent I mean: MySQL and possibly Java on a reliable web host.

I would also like, but do not require:

  • Java. As I’m no fan of PHP (aving worked to little with it) I’d prefer Java.
  • A lot of extensions and themes. Although I don’t particularly need the extensions for this client and will probably end up doing a new theme, the choices would be nice to have.

I absolutely don’t want:

  • Cluttered PHP.
  • Cluttered installations or cluttered admin interfaces A cluttered interface, be it disc or gui or api points to a cluttered mind.

Check the next post for our first contendant, Joomla!