Evaluatie Frog CMS

Op mijn eerder blog over Digitalus cms kwam een reactie om ook eens naar Frog CMS te kijken. Dat heb ik inmiddels gedaan. De installatie ging soepel en de performance van dit CMS bleek in eerste instantie uitstekend te zijn.

Installatie

Na het downloaden kan Frog CMS geïnstalleerd worden via de geleverde installer. In eerste instantie gaf die de volgende foutmeldingen:

Error: config.php must be writable
Error: public/ folder must be writable

Jammer, dat die controle niet werd uitgevoerd voor het invullen van de databasegegevens. Nu moest ik deze nog een keer invullen na het aanpassen van de rechten. Verder werkt het prima. Na de installatie had ik meteen een werkende website. Deze website (demo) is opgezet als een blog (Artikelen met archieven). Dit geeft in eerste instantie de indruk dat het CMS ook het beste gebruikt kan worden voor het schrijven van blogs. Als een blogartikelen aan een pagina koppelt heb je opeens een site. Zo groot is dat verschil dus niet. Bijvoorbeeld Expression engine en WordPress werken overigens ook op die manier.

Performance

Net als bij Digitalus cms heb ik voor Frog CMS ook naar de performance gekeken. Daarbij kijk ik dus naar het geheugengebruik en de rekentijd voor genereren van een pagina. Ik heb steeds dezelfde pagina gebruikt met dezelfde layout. De test is geen benchmark, maar wel een indicatie. Voor ik Digitalus cms testte had ik eerst een aanpassing gemaakt, zodat per pagina automatisch metatags werden aangemaakt. Dit heb ik ook eerst voor Frog CMS gedaan. Bij alle tests werd dezelfde php-class gebruikt voor het bepalen van de metatags (description en keywords). Voor Frog CMS heb ik de aanpassing in de layout gedaan. De resultaten waren verrassend:

Frog CMS:
<!– CPU usage user program: 0.048003 sec –>
<!– CPU usage OS for user program: 0.004 sec –>
<!– Total cpu usage: 0.052003 sec (user + OS)–>
<!– Memory usage totaal: 413,388 bytes –>
<!– Memory usage cms: 307,732 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) –>

Frog CMS heeft dus een uitstekende performance. Het geheugengebruik is laag, minder dan een kwart van dat van Opensourcecms.eu. De rekentijd is slechts een tiende t.o.v. Opensourcecms.eu. Oeps, toch eens uitzoeken waar dat aan ligt.

Frog CMS heeft ook een cache module. De module slaat de complete pagina op en toont deze weer als er niets veranderd is. Uiteraard komt dat de performance ten goede, maar het is niet echt zinvol dit te vergelijken bovengenoemde tests. Gezien het een module is die niet tot de core van het systeem behoort is er wel het risico, dat het bekijken van de cache niet het eerste is wat het systeem doet. Op die manier zou er nog best wat rekentijd en geheugen verbruikt kunnen worden. Toch maar even de cijfers:

Frog CMS pagina uit de cache:
<!– CPU usage user program: 0.0080000000000027 sec –>
<!– CPU usage OS for user program: 0.004 sec –>
<!– Total cpu usage: 0.012000000000003 sec (user + OS)–>
<!– Memory usage totaal: 393,804 bytes –>
<!– Memory usage cms: 288,484 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>

De cache module levert dus wel een extra voordeel op.

In /frog/app/frontend/main.php wordt als eerste uitgevoerd:

// Intialize Setting and Plugin
Setting::init();
Plugin::init();

Daarmee is dus alleen niet gezegd, dat de cache plugin ook al eerste van de plugins wordt uitgevoerd. Ter vergelijking als ik de html van de pagina direct naar de browser echo:

<!– CPU usage user program: 0 sec –>
<!– CPU usage OS for user program: 0 sec –>
<!– Total cpu usage: 0 sec (user + OS)–>
<!– Memory usage totaal: 116,548 bytes –>
<!– Memory usage cms: 1,568 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>

Het installeren van deze plugin verliep overigens zeer eenvoudig.

Meertaligheid

De nieuwste versie van Frog CMS zou een betere ondersteuning hebben voor meertalige websites. Omdat ik nieuwsgierig was geworden door de goede performance, heb ik ook de laatste versie via SVN geïnstalleerd. Taal instellingen en vertaalmogelijkheden kon ik echter niet terug vinden. Op het form heb ik de volgende discussie hierover gevonden. De suggestie die gedaan wordt om de gehele websitestructuur te kopiëren en vervolgens te vertalen, lijkt mij geen optie. In de eerste plaats is het zeer bewerkelijk en bovendien heb je op die manier geen relatie meer tussen de vertalingen. Op een pagina kun je dus niet meer linken naar de vertaling van de betreffende pagina. De laatste post verwijst naar een WordPress Plugin met de naam qTranslate. Die aanpak lijkt mij veel beter. Voor Frog CMS zou dat beteken dat een dergelijke opzet niet alleen voor de pagina’s wordt gemaakt. Ook de artikelen gekoppeld aan een pagina zouden op deze manier opgezet moeten worden.

Pagina’s en artikelen

Na het installeren van Frog CMS vond ik het in eerste instantie verwarrend dat er een “Home” was waarop artikelen getoond werden van de pagina “Articles”. Waarschijnlijk is dit alleen als voorbeeld bedoeld. Aan “Home” kunnen net zoals aan “Articles” losse artikelen gekoppeld worden. Op die manier kun je dus prima een websitestructuur bouwen, met meerder artikelen per pagina. Het voorbeeld toont de artikelen op volgorde van toevoeging. Voor een website zou je dat dus niet willen. Het paginaoverzicht heeft ook de optie om te kunnen herschikken (drag and drop). Ik neem aan dat die volgorde ook gebruikt kan worden om de artikelen op de pagina’s te tonen.

Wat ik (nog) niet helemaal begreep. De “Articles” pagina is een pagina van het type archive. Toch bevat de inhoud van deze pagina een stuk php-code om de artikelen te tonen. Voor mij is niet duidelijk wat het nut van een pagina van het type archief dan is. Tenzij dit alleen bedoeld is om aan te geven dan het een archief is. Als dat inderdaad zo is, bemoeilijkt dit de inzet van Frog CMS voor het onderhoud van de site door niet php-programmeurs. Ik kan iemand vertellen, maak een pagina aan van het type archief. Als je dat gedaan hebt worden alle onderliggende pagina op die pagina als artikel getoond. Zou daar nog een stap bijkomen, voeg nu aan de content van die pagina het volgende stukje php-code toe, dan gaat dat net wat te ver. Ook voor wel php-programmeurs lijkt dat omslachtig.

Plugins / Modules

Om nog wat andere zaken te bekijken heb ik nog een extra module geïnstalleerd. Op deze pagina, is een flinke lijst met modules te vinden. Opvallend is dat veel modules gericht zijn op het systeem en onderhoud. De rest van de plugins voegen een eenvoudige functionaliteit toe. Complexere modules zoals een forum of een webshop zijn er niet.
Ik heb gekozen voor de “whois” plugin. De installatie was opnieuw eenvoudig:

1 – Unzip and upload this plugin to the Frog plugins directory.
2 – IF NECESSARY, edit the index.php file and change the variables.
All variables are well commented in the code.
3 – Access the Frog Administration screen and activate the plugin.
4 – Place the following code in your desired page: <? whois(); ?>

En zo werkte het ook. Ik kon dus een nieuwe pagina aanmaken en daarin de <? whois(); ?> code opnemen. Door deze manier van implementeren kan er dus nog steeds tekst boven of onder de module geplaatst worden. Ik had verwacht dat ik <? whois(); ?> code ook een een zgn. snippet (snipper) zou kunnen zetten. Dat kan ook, maar geeft in dit geval alleen content als de code in de content van een pagina wordt getoond. Plaats ik de snippet in de layout of in een artikel, dan wordt de inhoud niet getoond.
Verder neem ik aan dat er ook plugins zouden zijn die je aan een pagina koppelt. Op de manier van; deze pagina is van het type <plugin>. Eigenlijk net zoals bij de archive-plugin, die dus ook niet helemaal deed wat ik verwachtte.
Ondanks dat de <? whois(); ?> niet overal output geeft lijkt deze wel ‘globaal’ beschikbaar. Deze opzet zou er bij veel of grote plugins dus voor zorgen dat de performance hard achteruit holt.
Inderdaad is na het activeren van de plugin op alle pagina’s te zien dat de hoeveelheid gebruikt geheugen toeneemt:

<!– CPU usage user program: 0.032002 sec –>
<!– CPU usage OS for user program: 0.008 sec –>
<!– Total cpu usage: 0.040002 sec (user + OS)–>
<!– Memory usage totaal: 548,592 bytes –>
<!– Memory usage cms: 483,888 bytes –>
<!– PHP version: 5.2.8 –>
<!– Apache version: Apache/2.0.54 (Fedora) –>

Wanneer ik kijk naar de “Whois” plugin dan is deze niet geschreven volgens het MVC-patroon. Ook bij andere plugins zie ik dat niet terug.

Snippets / snipper

De website die met de installatie neergezet wordt heeft twee snippets. Via een snippet kan je klein stukjes content in een layout of pagina includen. De twee eerder genoemde snippets bevatten de header (inclusief) menu en de footer van de layout. Eigenlijk snap ik niet waarom deze opzet is gekozen, maar misschien is het alleen om te illustreren hoe een snippet werkt. De templates (layouts) bevatten veel php-code, eigenlijk past dat ook niet zo bij het MVC-patroon. Ook lijkt Frog CMS daarmee een systeem dat je alleen kunt beheren met php-kennis. Op het forum vond ik hier nog wat over terug, hier kun je lezen, dat je de php in snippets kunt plaatsen en zo de layout vrij van php kunt houden. Op de website van Frog CMS valt overigens te lezen dat het kunnen gebruiken van php in de layouts juist een uniek voordeel is. (waar heb ik dat eerder gehoord?)
Snippets lijken mij ook geschikt om de content van een plugin te tonen. Met de geteste “Whois”-plugin werkt dit dus niet.

Overigens kun je een pagina ook opdelen in verschillende stukken. Bij de standaard installatie heeft de pagina een body en een sidebar gedeelte. De sidebar kan dan in de layout worden opgenomen d.m.v. $this->content(‘sidebar’, true); Voor mij is niet helemaal duidelijk wat dan het verschil met een snippet is. Mogelijk biedt deze constructie de mogelijk om op elke pagina iets anders in de zijbalk te plaatsen.

Server farm

Zou Frog CMS in te richten zijn als server farm? De templates vormen geen probleem omdat deze in de database staan, op die manier kan elke website gewoon zijn eigen templates hebben. Qua plugins zie ik in eerste instantie geen eenvoudige oplossing. Feitelijk zou je twee plugin directories willen hebben, een in de centrale code en een per website. Verder is de opzet van de plugins belangrijk, dan met name de views. Views lijken er in eerste instantie dus niet te zijn. Zouden die er wel zijn dan zou het gewenst zijn, als per website aparte views per plugin gebruikt zouden kunnen worden. De de plugin staat centraal terwijl de views lokaal staan (of wanneer ze daar staan de centrale views overrulen).

Code

De code lijkt wel goed in elkaar te zitten. Alleen mis ik dus MVC bij de plugins. Documentatie heb ik ook niet kunnen vinden. Op de roadmap lees ik dat er aan PHPDoc documentatie wordt gewerkt. Voor PHPDoc zijn speciale comments in de code nodig en die zie ik inderdaad met grote regelmaat terugkomen.
Op de roadmap las ik ook “Removed split between frontend and backend”. Ik vraag mij af wat dit betekent. Mogelijk het idee om de content op de site zelf te kunnen aanpassen. Vanuit performace-perspectief is een splitsing tussen frontend en backend vaak de beste optie. Althans mijn idee is dat de performance van frontend belangrijker is, dus houd je die code vrij van beheerfuncties.

Conclusie

In eerste instantie was ik erg verrast door de goede performance. Later bleek dit mede te danken aan het minimaal aantal geïnstalleerde plugins. Een grote plugin kan de performance van de gehele site sterk verslechteren. Wanneer het
multi-language probleem aangepakt zou worden volgens de manier waarop ook de genoemde qTranslate plugin van WordPress is geïmplementeerd zou ik mij nog eens verder willen verdiepen in Frog CMS.