Summary
the Zikula project has been around in one form or another since 2001, previously as PostNuke. Since the PostNuke days we've completely rewritten the core from the ground up, trying to keep a nice balance between practicality, performance and good architecture design. There's a strong API, we've had templating for years so output is easily modified by anyone who knows a bit of HTML and CSS, and our biggest thing is enterprise level security.
Many of the things we initially had as a differentiating factor, i.e APIs (most PHP CMSs didn't even have this when PostNuke started out), templating and so on are now in every CMS on the market. One thing we have maintained is the security focus, and I think we have that still over competitors.
Now, the obvious competitors that come to mind like Joomla and Drupal will have more modules, we can't claim to have such a large backing (though the community is big), but I can honestly say that I have never wanted for a module to build one of my sites - and I must have built hundreds. We are lucky in that a few super-powerful modules are flexible enough to cover 90% of situations.
For Fedora, I think the highlights are the security, our caching system (based on smarty), the fine grained permissions system, custom authentication and of course we are modular. The long, 8 year history tells you we're not going to disappear on you, Zikula will be around for a long time yet.
Project Website
Please excuse the slightly disorganised content, we recently refreshed our site and we're still in the process of updating the content and navigation to our liking.
Hardware Requirements
Apache/IIS (recommend Apache to get the best friendly URLs), PHP 5+ (though our 1.x series will work on PHP 4 I can't in good conscience recommend using it) and MySQL 4 or 5 (preferably 5). Gettext for the upcoming 1.2 version as an extension to PHP.
Features
Must have
== Meets the requirement.
== Partially meets the requirement.
.png){kind=small}
== Does not meet the requirement.
| Requirement | Status |
|---|---|
| Good security record |
|
| Proactive, security minded developer community |
|
| Highly responsive, especially to security issues |
|
| Flexible enough auth system to attach to FAS via the json interface |
|
| RSS |
|
| L10n that doesn't break the translator workflow |
|
| Output for Transifex (PO/POT) | |
| Content workflow (write <=> edit => publish) |
|
| Internal version control with rollback capability |
|
| Content expiration (automatic) |
|
| Multiple roles, e.g. writer, team lead, editor, publisher, managing editor |
|
| Categorize/tag content for easy base organization |
|
| Search that works |
|
| Be a CMS as a core function, not an add-on |
|
| Handle making certain pages or content areas static/non-database driven |
|
| Must not lock us in. Data should be portable to another CMS. |
|
| Packaged for Fedora |
|
Like to have
== Meets the requirement.
== Partially meets the requirement.
== Does not meet the requirement.
| Requirement | Status |
|---|---|
| OpenID |
|
| Good WYSIWYG editor |
|
| Easy to organize content by taxonomy, structured and ad hoc | |
| Support for draft->review->$foo->publish workflows |
|
| Workflow to ship the content for l10n only at certain stages | |
| Workflow go back to a certain stage if a mistake/error is found in the source-language content by the translator | |
| Translators have a 'review' step in the workflow for translated content before it is published, so that they can see translations in context | |
| Modern technology with a vibrant community and likelihood of being popular beyond the next twelve months |
|
| Good federation tools to make it easy to find disparate content through one UI | |
| One set of things it is great at, not be all things for all people | |
| Be a modular design (v. monolithic) |
|
| Have an active and large community |
|
| Have support for DocBook |
Explanations
Authentication
We have what we call Auth Modules, which allow us to authenticate against external sources. This can either take the details entered on the site, and send them elsewhere for checking, or alternatively I have previously redirected people to an external page to authenticate and the result of that is passed back to Zikula. I've personally implemented a system to authenticate against 'Raven' which is the authentication system used at the University of Cambridge here in the UK, and we have an OpenID module too
Translation
This is the one I wanted to talk about. With 1.2 (in development), our core at least is translated through gettext. That would be any strings inside the core, e.g status messages and the like. Content is a bit different. We have on our roadmap a plan to provide a generic way of translating content, however it's not there yet. So, translations are dependent on the module you use at the moment. I realise that might not be ideal, but presumably you would be using one main module for most content, so we could code up a better translations interface for one or two modules if it turns out to be a problem.
Search
Two systems, the old system is database-based and IMO does not work that well. We have a new system from the GSOC to replace it based on Zend Search Lucene which is a proper indexer and very nice. Needs some further development but is in a basically working state.
Dynamic/Static Pages
Not completely, no. The caching system either allows full page or page-element caching. Full page caching will reduce SQL queries to 3 or 4, element caching depends on the module. If you were using a particular Short-URL system we could make the pages completely static without breaking anything
Contact
- Name: Simon (simon@zikula.org)
IRC Interview
This information was gained from a chat with Simon (zk-Simon) who represents the Zikula project. This chat was archived and can be read at Zikula IRC Chat Interview.