Evaluatie Digitalus cms 1.5 beta

Af en toe denk ik er over na om opensourcecms te herschrijven naar het Zend Framework. Er zijn natuurlijk veel php frameworks, toch lijkt Zend daarvan op dit moment de enige te zijn, die een standaard kan worden. Onlangs stuitte ik op Digitalus cms, dat reeds ontwikkeld is op het Zend Framework, het leek mij daarom interessant om eens te bekijken hoe de nieuwe 1.5 beta werkt en in elkaar zit.
Beta bleek al snel een groot wordt. Wat je krijg is de basis, met een installer die redelijk werkt. Pas na het lezen op het forum kwam ik er achter, dat de cache directory chmod 0777 moest hebben. Er wordt in deze beta slechts één module meegeleverd, de contact form module, die overigens niet werkt.
De reden om niet de stable versie maar de beta te testen is dat de stable versie in de eerste plaats niet gebouwd is met het Zend Framework. Ook beschikt de stable versie niet over de mogelijkheid een meertalige website te bouwen. Dit laatste is één van mijn minimale eisen.

MVC

Het cms maakt gebruik van het Model-View-Controller ontwerp patroon dat in Zend Framework geïmplementeerd is. Dit maakt de opzet van het systeem en de code overzichtelijk. In eerste instantie komt het vreemd over dat de views php-code bevatten. Dit is geen manco van Digitalus cms. Dit komt voort uit het Zend Framework. De ontwikkelaars van het Framework zeggen hierover: “PHP is itself a powerful template system”.

Artikelen en pagina’s

Wanneer je binnen het cms een pagina aanmaakt kan daar vervolgens met een html-editor, in dit geval WYSIWYG jQuery Plugin, content aan worden toegevoegd. Dat werkt prima. Zelf zou ik er de voorkeur aan geven om meerder artikelen per pagina te kunnen koppelen. Voordeel daarvan is dat je aan elk artikel apart extra functionaliteiten kunt koppelen. Op termijn zou dit opgelost kunnen worden via een aparte module.
Pagina’s kunnen slechts één module bevatten. Grootste nadeel daarvan is dat je geen content meer boven of onder de module kunt toevoegen. Dit probleem wordt opgelost door onder en boven de module een mogelijkheid te bieden, extra tekst in te voeren.

Automatische metatags

Bij Digitalus cms kan per pagina worden ingesteld wat de metatags (keywords en description) zijn, ook kan de titel van de pagina worden aangepast. Bij het beheren van meerdere website, met veel content wordt dit al snel te arbeidsintensief. Mijn voorkeur zou dan ook zijn dit net als bij Opensourcecms.eu te automatiseren.
De opzet van ./library/DSF/Builder/Action/Page.php maakt dit met een kleine aanpassing, mogelijk in de functie loadContent een aanroep te doen naar $this->setMeta en zo de metatags te maken op basis van de content die via de variabele content->content[‘content’]; beschikbaar is in deze functie.

Meertalige websites

Digitalus cms biedt de mogelijkheid om per artikel een vertaling aan te maken. Op de webpagina’s is dit zichtbaar te maken d.m.v. hyperlinks, die aangeven dat er ook een vertaling aanwezig is. Zelf zie ik de vertaling liever op een hoger (pagina) niveau, zodat niet alleen het artikel vertaald wordt maar ook de url, metatags (indien niet voor automatische metatags gekozen wordt, zie vorige paragraaf) en de menu’s op de betreffende pagina. Deze laatste optie, kan wel tot complexe situaties leiden, indien maar een gedeelte van de website vertaald is. Onmogelijk is het niet, zie bijvoorbeeld http://www.ellenpari.nl/

Modules

Ook de modules zijn opgezet volgen het MVC-partoon. Uitbreiding van het systeem, wordt daarmee eenvoudig en inzichtelijk. Wel vraag ik mij af hoe modules met meer complexere instellingen in de admin interface verwerkt moeten gaan worden. Binnen de interface lijkt wel ruimte te zijn gemaakt om een module in te stellen, maar niet om deze ook werkelijk te beheren, bijvoorbeeld in het geval van een webshop of forum.

Server farm

Installatie in een zgn. Server farm vind ik wenselijk. Hiermee bedoel ik dus dat er meerdere website opzelfde cms-code kunnen draaien. Mede door de MVC-implementatie zou dit mogelijk moeten zijn. In de huidige directory-structuur is hiervoor echter nog geen duidelijk onderscheid gemaakt. Het publieke deel (de feitelijk site) zou uitsluitend moeten bestaan uit templates, css, images en eventueel bijvoorbeeld een .htaccess bestand en een cache-directory.

Geheugengebruik en performance

Rekentijd en geheugengebruik krijgen bij cms-implementaties vaak weinig aandacht. Op zich is dat vreemd want in de eerste plaats bepalen deze factoren de laadtijd van de pagina. Daarnaast bepalen rekentijd en geheugengebruik het aantal gelijktijdige gebruikers dat een website of webserver kan afhandelen.

Ik heb een vergelijking gemaakt tussen Digitalus cms en Opensourcecms.eu, door een pagina te laden, met een artikel, menu, en ‘broodkruimel’-pad.

Digitalus cms:
<!– CPU usage user program: 0.248015 sec –>
<!– CPU usage OS for user program: 0.052003 sec –>
<!– Total cpu usage: 0.300018 sec (user + OS)–>
<!– Memory usage totaal: 5,184,296 bytes –>
<!– Memory usage cms: 5,127,524 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>

Opensourcecms.eu:
<!– CPU usage user program: 0.092006 sec –>
<!– CPU usage OS for user program: 0.044003 sec –>
<!– Total cpu usage: 0.136009 sec (user + OS)–>
<!– Memory usage totaal: 1,708,364 bytes –>
<!– Memory usage cms: 1,468,084 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>
<!– Database version: –>

Naast de langere rekentijd van Digitalus cms is te zien dat het geheugengebruik bijna 3x zo groot is. Mogelijke oorzaken hiervan zijn:

• De overhead van Zend Framework
• In de code kom ik veel nieuwe class/object initalisaties tegen, waar een Singleton misschien efficiënter zou kunnen zijn
• Het cms lijkt voor elke pagina alle beschikbare ‘helpers’ e.d. in te laden terwijl ze niet allemaal nodig zijn
• Hoewel het menu en ‘broodkruimel’-pad op een pagina vaak weinig veranderd, moet het elke keer opnieuw berekend worden, wat vaak gepaard gaat met rekenintensieve recursies.

Hoewel het niet openstellen van de cache-directory fouten gaf bij het installeren, lijkt de cache nu nog niet gebruikt te worden. Dit zou de performance kunnen verbeteren, als is er natuurlijk altijd iemand die de eerste pagina of zijn eerste pagina moet opvragen.

Opensourcecms.eu legt bij wijzigen in de pagina/websitestructuur een cache-bestand aan. Vanuit de in dit cache-bestand opgeslagen paginastructuur, kunnen menu’s, sitemaps en ‘broodkruimel’-paden worden samengesteld, zonder steeds opnieuw dezelfde queries naar de database te hoeven doen.

Code

De code van deze 1.5 beta versie is overzichtelijk en leesbaar. Mede door de inzet van Zend Framework ook consequent van opbouw. Documentatie van de code ontbreekt helaas nog volledig. Ook lijkt er bij de ontwikkeling dus nog weinig aandacht voor performance te zijn.

Conclusie

Digitalus cms laat zien dat er met Zend Framework een goed opgezet cms gebouwd kan worden. De keuze om een splitsing te maken in een public en admin deel, met elk zijn eigen views en controllers vind ik verhelderend. Het meenemen van meertaligheid vind ik goed, al is deze in mijn ogen dus nog niet ver genoeg doorgevoerd. Performance vraagt volgens mij nog wel aandacht. Zonder verdere verbeteringen zullen de vertalingen en menu-opzet op dit moment nog leiden tot het publiceren van ‘duplicate content’, wat dus ook nog aandacht vraagt.
Websites bouwen op een beta versie is natuurlijk sowieso geen aanrader. Zelf ga ik Digitalus cms i.i.g de komende maanden in de gaten houden.
De community lijkt overigens niet heel erg groot en/of actief te zijn. Daarnaast hoop ik dat de ontwikkelaars niet vergeten om eerste een stabiele basis te bouwen, voordat alle nieuwe en mooie functionaliteiten worden uitgewerkt.