CMS: de beslissing
Eindelijk heb ik eens echt wat systemen kunnen uittesten en ik ben tot een beslissing gekomen.
SilverStripe
SilverStripe heb ik lang links laten liggen. De admin-interface was traag bij het testen op OpenSourceCMS en de namaak XP-achtige styling past niet echt in mijn kraam. Het installeren verliep vlot en na een tijdje viel de interface mee. Blijkbaar wordt het maken van custom types goed ondersteund door het onderliggende Sapphire framework.
Dat de rich-text-editor (TinyMCE) valid HTML uitspuwde was een aangename verrassing, maar bij het maken van de templates staken nieuwe bezwaren de kop op. Bij het genereren van het menu verwijst de link naar de homepage steevast naar /home in plaats van / en… de beperkte mogelijkheden van de template tags laten je niet toe om hier een workaround voor te voorzien.
MODx
MODx heeft op het eerste zicht een zeer leuke interface, maar jammer genoeg zijn er 2 clicks nodig om inhoud aan te passen want je moet eerst voorbij een overzicht van bewerkingen. Daarnaast moeten templates in de database worden gestopt. Hoewel je met snippets een PHP-script kan includen - met de echte logica - blijft het een omweg. De syntax van de beschikbare template tags doet me trouwens de wenkbrauwen fronsen.
ExpressionEngine
Sorry Bart, maar ExpressionEngine blijft voor mij voornamelijk een blogging engine van de categorie TextPattern en WordPress. Je kan er andere websites mee bouwen, maar dat kan je ook met die andere tools.
De winnaar: Drupal
Ja, het is toch Drupal geworden. Drupal laat me toe om gewoonweg PHP te gebruiken in templates. Dat het geen onderscheid maakt tussen “admin” en “bezoeker” valt grotendeels op te lossen met de role_theme_switcher module die Bart Claeys aanhaalde, maar ook deze faalt om pagina’s op URLs zoals node/add weer te geven met het admin theme. In Drupal 6 lijkt de scheiding tussen admin en user themes iets strikter te zijn en mits de tips voor 4.6 nog werken kan ik dit eenvoudig aanpassen in de huidige 5.7 branch. Update: bij een tweede poging lijkt de module wel correct te werken, maar de volgorde waarin je themes kiest binnen de standaard Drupal settings en binnen de module is erg belangrijk.
Ik heb me verzoend met de architectuur van het framework en moet toegeven dat het logischer is dan het lijkt om bepaalde modules niet standaard te voorzien. Alleen blijf ik erbij dat er wat kort en bondige (en vooral up-to-date) documentatie moet komen om mensen duidelijk te maken dat er wel wat in zit. Als je sneller via Google informatie kan vinden op een site dan via de site zelf is er sprake van een gebrek aan gebruiksvriendelijkheid.
Dit artikel werd opgenomen in ontwikkeling, software.
No hard feelings Kevin! Ik ben zelf ook wat aan het testdraaien met Drupal. Ik zie er zeker enkele goeie zaken aan. Wat me op dit moment (ben nog geen kenner) stoor is de overload aan indrukken als ik inlog als admin, een beetje te chaotisch voor een neuroot als ik. Ook het door jou aangehaalde gebrek aan duidelijke scheiding tussen front- en backend vind ik wat vreemd, maar dat is waarschijnlijk een kwestie van gewoonte.
Veel succes ermee alleszins!
De onduidelijke scheiding tussen front- en backend is ergens wel logisch. Want wat is een back-end? Als je een site hebt met gewone users (die bv. zelf hun profiel kunnen aanpassen) met admins en superadmins heb je dus 3 soorten back-ends. Maar sommige van deze gebruikers zijn én gewone users maar tegelijk ook admins. Welke theme schotel je die dan voor? Bij het ontwerpen van een theme moet je dus wat extra werk verrichten om deze uit te breiden naar een back-end theme.
Die scheiding is inderdaad logisch als je in achting neemt dat het niet alleen een CMS is, waar er de typische verdeling onder admin en bezoeker bestaat, maar ook een framework waarop sites zoals CreativeSkills kunnen worden gebouwd. Ik gebruik voor dat laatste type sites meestal zelfgeschreven code (binnen een open source framework), maar verkies voor sites van klanten een duidelijke logische scheiding: “Dit is wat de bezoeker ziet en hier kan je dingen aanpassen en toevoegen, maar de bezoeker ziet dit onderdeel niet.”
De reden waarom ik al die andere frameworks heb bekeken - hoewel ze minder aanhangers hebben - is net dat die scheiding ingebakken zit, zodat je een admin interface hebt met duidelijke beheersecties voor pagina’s, blog, forum en andere modules. Bij Drupal zit dit default allemaal weggestopt. Het grootste voordeel van Drupal is ook het grootste nadeel om mensen te overtuigen: de flexibiliteit.
Maar ik ben overtuigd dat ik er kan van maken wat ik wil :)