Een eigen CMS: Hoe en wat, en waarom juist zo?

[Duroth]

Een ontzettend breed onderwerp, met een enorme variatie aan meningen. Daar is dit topic dan ook op gebaseerd. Maar wat uiteindelijk nog belangrijker is, is uiteraard de argumentatie achter de mening. Mijn eerste poging tot een groot discussie topic.

Ik ben van plan om binnenkort aan de slag te gaan met een zelf geschreven CMS in PHP. Uiteraard zijn er tal van (gratis) oplossingen zo beschikbaar, maar dit project dient boven alles om mijn eigen 'skills' in PHP, CSS en Javascript wat te verbreden. Dus hoewel hier en daar wat knutselen best is toegestaan, richt ik me erop een bruikbaar (of beter nog, goed) product te zetten. Maar nog voor ik goed en wel begonnen ben, zit ik al met een hele belangrijke (en helaas ook hele ruime) vraag.

Waar moet men rekening mee houden, kijkende naar de architectuur van o.a. de database, de 'fysieke' bestandsindeling op de harde schijf, en last but not least, binnen de code zelf?

• Is een template engine beter dan, bijvoorbeeld, een statische html pagina met een php require() erin?
• Is het nuttig om geparste bestanden als HTML te cachen, evt. server-side, of roep je direct PHP pagina's aan en vertrouw je op evt. caching aan client side?
• Als je meertaligheid in wilt bouwen, verplicht je de beheerder dan om elke pagina in elke taal af te leveren? Hoe vang je ontbrekende talen af? Of vind je dat het mogelijk moet zijn om per taal een compleet afwijkende paginastructuur aan te houden, en zo bijna meerdere websites te onderhouden?
• Hoe zou een CMS om moeten gaan met niet-statische pagina's (zoals een fotogallerij, webshop, nieuwsberichten pagina), en eventuele koppelingen hiertussen (linken naar een fotogallerij vanuit een nieuwsbericht)? Of zou een CMS zo ver niet moeten gaan, en zich richten op statische content / nieuwsberichten?
• Hoe zal - zeer globaal - je backend eruit zien? Gooi je alles in een database? Hoe hou je rekening met toekomstige uitbreidingen (zoals een nieuwe contentmodule, b.v. een reactiesysteem voor je nieuwsberichten) in zowel je database als directory tree?

Verschillende mensen, verschillende wensen, en een perfect CMS bestaat uiteraard niet. Maar wat zijn voor jou de belangrijke punten wat een compleet CMS-pakket toch zeker wel, of juist niet, moet hebben? Denk hierbij aan een CMS gericht op wat grotere bedrijven. Snel en gebruiksvriendelijk, maar toch een veel- zo niet alleskunner.

Natuurlijk zijn de vragen hierboven klein, gericht, en makkelijk met een google search te 'beantwoorden'. Maar deze voorbeeldvragen zijn uiteraard maar een hele kleine greep uit de punten die je voorbij vliegen tijdens het werk aan zo'n groot project. Veel te veel om in de topicstart op te nemen, maar dat betekent uiteraard niet dat ik niet benieuwd ben naar jullie visie!

Nogmaals, jullie beargumenteerde mening telt Een lijstje van grote bekende CMS pakketten is zo te vinden, maar voegt in dat opzicht absoluut niks toe. Daarentegen, als een bepaald CMS pakket een aparte aanpak hanteert, of je punten prachtig demonstreert, is een linkje altijd welkom.

Edit:

Zijn er specifieke redenen waarom je zelf een CMS wil maken? Is het een leerproject of wil je het ook echt daadwerkelijk gebruiken? Er zijn nogal wat dingen die een CMS een goed CMS maken - in mijn ogen is dat (uiteraard) security, gebruiksvriendelijkheid, clean URL's, SEO, enz.

Om even te verduidelijken; Ja, het is een leerproject. Ik heb expres voor een CMS gekozen omdat de applicaties die ik tot nu toe gemaakt heb redelijk standvast van aard zijn; vaak zijn ze gericht op een enkele klant, zonder plannen om deze ooit nog eens te verkopen. In zo'n situatie is het nogal makkelijk om de gedachte 'zolang het maar werkt' aan te houden. Weinig tot geen onderhoud betekent dat het snel verleidelijk is om maar even snel wat in elkaar te zetten.

Iets bestaands als basis gebruiken helpt in dit opzicht ook niet, omdat je dan natuurlijk vastzit aan een reeds bestaande database-, directory- en codestructuur. Daarom iets volledig nieuws, een leerprojectje dus, maar wel zo opgezet dat het in theorie verkocht zou kunnen worden. Dit gaat uiteraard niet gebeuren, maar die mindset helpt wel om slordige stukjes code (inline PHP-code of zelfs SQL queries) tegen te gaan.

Het uiteindelijk doel is dan ook vooral om netjes en correct te programmeren, iets dat af en toe best een uitdaging kan zijn voor iemand met mijn achtergrond, en ik mezelf middels dit projectje aan wil leren. het is natuurlijk ook een mooie kans om wat dieper in de enorme function base van PHP te duiken, maar dat is bijzaak. Daarom probeer ik dit topic te beperken tot de architectuur achter zo'n (groot) blok code. Met het 'programmeren' zelf (lees: code tikken) heb ik geen problemen.

[ Voor 21% gewijzigd door Duroth op 25-07-2009 00:39 ]

[Alex)]

Wat ik me afvraag is waarom je een eigen CMS wilt. Er zijn inmiddels heel veel systemen in allerlei soorten, maten en platforms.

Je kunt WordPress "misbruiken" als CMS (je kunt er eigenlijk best veel mee), maar als je wil kun je ook een .NET-oplossing kiezen en Sharepoint gebruiken. Misschien is Java meer jouw ding en kies je iets van IBM maar het kan ook zijn dat je liever plain ol' HTML hebt en DreamWeaver oid gebruikt om templates mee te maken.

Zijn er specifieke redenen waarom je zelf een CMS wil maken? Is het een leerproject of wil je het ook echt daadwerkelijk gebruiken? Er zijn nogal wat dingen die een CMS een goed CMS maken - in mijn ogen is dat (uiteraard) security, gebruiksvriendelijkheid, clean URL's, SEO, enz.

Watbetreft je vragen:
Mijn voorkeur ligt bij een template engine omdat je daarmee flexibeler kunt zijn. Je legt de verantwoordelijkheid voor presentatie bij de themes, en niet gemixt met je code. Bijvoorbeeld een lijst met menu-items: je kunt dat allemaal in je back-end genereren en laten outputten maar dan zit je eraan gebonden. Als je een object (een nested array oid) terugstuurt naar je template engine, en die het laat afhandelen, kun je veel meer.

Serverside caching is zeker aan te raden wanneer je veel load trekt - door de databasequeries e.d. weg te laten heb je veel minder overhead en laden je pagina's sneller. Resources (stylesheet, images, etc) kun je op een aparte hostname zetten zodat cookies en sessiegegevens met die requests niet worden meegezonden. Ook kun je headers instellen waarmee je clients 'dwingt' om die resources langere tijd in hun cache te houden. Dit scheelt jou bandbreedte, je bezoekers scheelt het wachttijd.

Meertaligheid vind ik zelf ook een heikel punt - wat ik voorstel is dat niet-vertaalde items niet worden getoond. Wanneer dit niet gewenst is, kun je het wel in het menu tonen maar toon je op de pagina zelf een dropdown met een label - "Deze pagina is niet in uw voorkeurstaal beschikbaar. Wilt u de pagina in een andere taal bekijken?" Dit kun je (natuurlijk) ook gebruiken voor 404's.

Een CMS draait juist om dynamisch pagina's te kunnen genereren - dit bevat ook nieuws, foto's en bijvoorbeeld een forum. Door goede modules te ontwikkelen die je overal kunt inzetten (en cachen) kun je zo flexibel zijn als je wilt. Een manier waarop je dit zou kunnen bereiken is door een basistype te hebben ('page' ofzo) waarin je dan content plakt - of speciale tags gebruikt om dynamische elementen aan te roepen. Zo'n idee zegmaar:

code:

<cms:news title="Laatste nieuwsberichten" amount="10">
    <news:itemTemplate>
       <h1>{newsTitle}</h1>
       <div class="body">{newsBody}</div>
    </news:itemTemplate>
</cms:news>

Alles in je database is niet handig, in mijn ogen. Databases zijn bedoeld voor data, niet voor bijvoorbeeld programmacode en resources. Programmacode zet je in /modules/modulenaam welke je daarna dynamisch laat includen (bijvoorbeeld een iterator op /modules welke van iedere module een instance aanmaakt ofzo). Bijbehorende resources in /modules/modulenaam/resources, en de data in je database.

Dat is de meest logische scheiding, ook qua performance. Data wil je niet rechtstreeks op je filesystem (want dan zit je met problemen als file locks en performance), code wil je niet in je database omdat je code op zich databaseonafhankelijk moet kunnen functioneren: je kunt je databaselaag vervangen door een laag die op aapjes en bananen werkt en nog functioneert je systeem prima.

[Duroth]

Het is inderdaad een leerproject. Ik heb de TS wat aangepast, het is vrij moeilijk te verwoorden wat mijn 'vraag' nu precies is. Het is in PHP te makkelijk om rotte code te schrijven, die wellicht prima werkt, maar menig onderhoudsprogrammeur de haren uit het hoofd doet trekken. Hoe voorkom je zoiets?

Dit in het licht van een CMS, doorgaans een redelijk grote applicatie die gebruiksvriendelijk moet zijn voor zowel programmeurs als website beheerders. Omdat de functionaliteiten in zo'n applicatie deels van invloed zijn op de achterliggende structuur (b.v. extensibility middels modules) is het vrij moeilijk wat gerichte voorbeeldvragen te geven. Toch hoop ik dat het punt van discussie duidelijk genoeg is.

[Not Pingu]

Duroth schreef op zaterdag 25 juli 2009 @ 00:55:
Het is inderdaad een leerproject. Ik heb de TS wat aangepast, het is vrij moeilijk te verwoorden wat mijn 'vraag' nu precies is. Het is in PHP te makkelijk om rotte code te schrijven, die wellicht prima werkt, maar menig onderhoudsprogrammeur de haren uit het hoofd doet trekken. Hoe voorkom je zoiets?

Jaren ervaring opdoen of heel veel met andere CMS'en werken en kijken wat de voor- en nadelen van elke aanpak zijn? Achter dit soort dingen kom je toch alleen maar door praktjkervaring. Bij voorkeur zou je jezelf helemaal in de rol van een implementatiedeveloper moeten zetten bij een web-/reclamebureau maar dat is nou eenmaal erg lastig.

Je kunt wel eeuwig blijven soebatten over 'wat het beste is' maar vaak is er niet 1 aanpak 'de beste' en is het belangrijker dat je een keuze maakt en aan de slag gaat. Of je gemaakte keuze een goeie of slechte was, daar kom je vanzelf achter.

[MueR]

Met Not Pingu hierin. Je beste optie is gewoon een hoop CMSen downloaden. Installeer er eens gewoon een hoop ergens en ga ze gewoon doorlopen. Pik daar de elementen uit die je prettig vind werken en ga kijken hoe ze in elkaar steken. Ga niks zelf bouwen voordat je dit soort dingen voor jezelf hebt uitgewerkt. Anders ben je straks halverwege en bedenk je dat het niet zo werkt als je wilt.

[YopY]

MueR schreef op maandag 27 juli 2009 @ 16:33:
Anders ben je straks halverwege en bedenk je dat het niet zo werkt als je wilt.

Of beter nog, je werkt jaren aan je cms (zoals er zovelen doen) en je komt er ineens achter dat cms X toch veel beter en sneller en makkelijker is dan je eigen.

Doe eerst eens onderzoek naar andere CMSen zoals aangegeven. Want je kunt wel een CMS maken als leerproces, maar in de praktijk zul je het gebruiken in websites, misschien wel verkopen, en zo nóg een PHP CMS op het internet zetten - naast de duizenden anderen die ooit gestart zijn als oefenmateriaal.

[Alex]

Als CMS Product Architect kan ik hier nog wel wat op toelichten. Want gelukkig is een CMS bouwen namelijk heel makkelijk :
Begin eens met een keuze maken: page oriented of content/object oriented?
Deze keuze is heel belangrijk bij het inrichten van je structuren.
Vervolgens, wat wil je in je repository opslaan en wat niet(bijv user generated content wel of niet).
Daarna, hoe ga je de data structuren definiëren? Op welke manier ga je de opslag faciliteren(tree-based, silo-based, mix van beide). Hoe koppel je presentatie aan je items/pages/objects?

Onderwerpen als Security, Multilingual, etc, komen later bij valide OO design.

Nu je al deze keuzes hebt gemaakt heb je een conceptje. Hiermee kun je ook het onderscheid maken. Vervolgens ga dit maar een uitwerken in UML. Maar blijv je focussen op je Data Structuren en Infrastructuur, tot dit alles af is. Je weet immers al hoe je de presentatie wilt koppelen, dus bovenstaande vragen zijn slechts implementatie details...

offtopic:
Het leuke is dat men altijd roept 'even een CMSje bouwen'. Echt niet dus. Onze core engineers hebben jaren ervaring en zijn pur sang enkel met discussies als het bovenstaande bezig. Een CMSje bouw je in 4-5 jaar, niet als hobby project, is mijn ervaring tenminste

[poepkop]

Ik snap wel waarom je een eigen CMS wilt, maar mijn ervaring is dat je toch zelf even moet zoeken wat je wilt. Ik heb zelf echt een pokke hekel aan open source zooi, maar word press is wel een goede.

Maar je moet eerst eens even goed voor jezelf formuleren wat je wilt:
- flexibiliteit en snel later kunnen uitbreiden naar eigen wens (hier gaat mijn voorkeur uit)
- performance
- usabilty (met jquery en andere libraries kan je heel veel doen om dit te verbeteren)
- veiligheid

Mijn voorkeur gaat uit naar flexibiliteit, vooral omdat iedere klant andere wensen heeft en elke module net een tikje anders is. Daarnaast gaat mijn voorkeur uit naar het centraal beheren van het CMS zelf (een aanpassing en al mijn 160 klanten hebben er baat bij).
Ik zal kort uitleggen hoe dat dan bij ons in elkaar steekt:
- Het CMS 'begrijpt' de database en kan voor bijna elke tabel een user-friendly overzicht en forms genereren. Deze worden vervolgens gecached.
- Het CMS werkt vanuit een centraal domein en update websites middels FTP.
- De database gebruiken we vrij weinig, veel data wordt er wel in opgeslagen, maar uiteindelijk maakt het CMS weer xml-exports zodat we veel data gewoon client-side kunnen laten opbouwen.

Het meest lastige waar je tegenaan loopt is eigenlijk de keuzes die je maakt, als een CMS eenmaal staat en je je eigen standaard bepaald hebt kan je weinig meer aanpassen. Dus voor je aan de slag gaat om je skills te verbeteren zou ik eerst eens goed gaan nadenken, wat wil ik nu eigenlijk?

Hoe de techniek verder werkt en wat de meest goede code oplevert is eigenlijk een vraag die je spelenderwijs zelf zal ontdekken. Je zegt het goed, geen CMS is perfect. Wij hebben gekozen voor flexibiliteit en gemak (zodat ook de stagelopers makkelijk een module kunnen brouwen).

[ Voor 8% gewijzigd door poepkop op 27-07-2009 20:09 ]

[Alex]

poepkop schreef op maandag 27 juli 2009 @ 20:03:
Maar je moet eerst eens even goed voor jezelf formuleren wat je wilt:
- flexibiliteit en snel later kunnen uitbreiden naar eigen wens (hier gaat mijn voorkeur uit)
- performance
- usabilty (met jquery en andere libraries kan je heel veel doen om dit te verbeteren)
- veiligheid

Dit zijn technische requirements, architectuur boundaries, maar geen tastbare requirements voor hetgene waar het echt om draait: hoe design je de repository.
Daar start je toch echt hoor.

Mijn voorkeur gaat uit naar flexibiliteit, vooral omdat iedere klant andere wensen heeft en elke module net een tikje anders is. Daarnaast gaat mijn voorkeur uit naar het centraal beheren van het CMS zelf (een aanpassing en al mijn 160 klanten hebben er baat bij).
Ik zal kort uitleggen hoe dat dan bij ons in elkaar steekt:
- Het CMS 'begrijpt' de database en kan voor bijna elke tabel een user-friendly overzicht en forms genereren. Deze worden vervolgens gecached.

Dus jullie CMS is database dependant? Volgens mij wil je juist niet dat een CMS zich ent op een database. Jij kiest de structuur en de storage method is slechts een deployment detail. Of het nou file-based is of database based die back-end.

- De database gebruiken we vrij weinig, veel data wordt er wel in opgeslagen, maar uiteindelijk maakt het CMS weer xml-exports zodat we veel data gewoon client-side kunnen laten opbouwen.

Exports? Dus dat betekent legacy? Waarom cache je die data niet in memory? Van IO naar IO veplaatsen kost al veel tijd en maakt eea ook niet sneller lijkt me.

Het meest lastige waar je tegenaan loopt is eigenlijk de keuzes die je maakt, als een CMS eenmaal staat en je je eigen standaard bepaald hebt kan je weinig meer aanpassen. Dus voor je aan de slag gaat om je skills te verbeteren zou ik eerst eens goed gaan nadenken, wat wil ik nu eigenlijk?

Kwestie van release beleid en upgrade scripts. Maar daar heeft de topic starter geen last van, het is immers een research project.

Hoe de techniek verder werkt en wat de meest goede code oplevert is eigenlijk een vraag die je spelenderwijs zelf zal ontdekken. Je zegt het goed, geen CMS is perfect. Wij hebben gekozen voor flexibiliteit en gemak (zodat ook de stagelopers makkelijk een module kunnen brouwen).

Welke consessies heb je dan gedaan?

[Anoniem: 259662]

Duroth, gewoon beginnen met kloppen. Uiteindelijk kom je er toch achter dat ook je eigen CMS niet voor elke toepassing geschikt is.

Maar in het geval dat je serieus aan de slag wilt, zoek eens naar een MVC framework voor PHP zoals Symphony. Zulke frameworks geven je al een gedegen structuur voor je applicatie. Een bijkomend voordeel is dat het beheergedeelte van je CMS soms al automatisch gegenereerd wordt. Dit scheelt je een hoop tikwerk.

[Duroth]

Anoniem: 259662 schreef op donderdag 30 juli 2009 @ 17:11:
Duroth, gewoon beginnen met kloppen. Uiteindelijk kom je er toch achter dat ook je eigen CMS niet voor elke toepassing geschikt is.

Maar in het geval dat je serieus aan de slag wilt, zoek eens naar een MVC framework voor PHP zoals Symphony. Zulke frameworks geven je al een gedegen structuur voor je applicatie. Een bijkomend voordeel is dat het beheergedeelte van je CMS soms al automatisch gegenereerd wordt. Dit scheelt je een hoop tikwerk.

Daar gaat het me juist niet om Het belangrijkste, voor mij, is dat ik een goed beeld krijg van de 'voorbereiding'. Code kloppen is maar een heel klein deel van het werk, en net het gedeelte waar ik absoluut geen problemen mee heb.

Vooral Alex en poepkop hebben prachtige voorbeelden gegeven (tree-based, silo-based, wat de?). Het zijn misschien punten waar ik bij het programmeren genoeg mee geconfronteerd wordt, maar gewoon niet onder een noemer weet te plaatsen.

Code kloppen komt later wel, als dat er ooit van gaat komen. Ik ben zelf meer geïnteresseerd in de onderliggende architectuur en de beslissingen die je daarin maakt, dingen waar ik me niet bewust van ben als ik maar gewoon begin te tikken.

Edit: En is het beheersgedeelte niet het belangrijkste aspect? Een CMS-gebruiker kan het waarschijnlijk niet schelen *hoe* zijn content op het scherm verschijnt, zolang het maar goed gebeurt. En zolang zijn content makkelijk in te voeren is, uiteraard. Is in dat geval een automatisch gegenereerd beheer juist *niet* wat je wilt?

[ Voor 11% gewijzigd door Duroth op 30-07-2009 19:23 ]

[wasigh]

Alex legt wat mij betreft de vinger op de zere plek: hoe wil je dat je repository eruit ziet? Wat wil je dat de content kan?

In de basis bestaat een CMS uit een aantal onderdelen:

• De repository: oftewel de dataopslag: hoe sla je een pagina op? hoe sla je meerdere versies op? Waar en hoe sla je afbeeldingen op? en wat doe je met de metadata die bij afbeeldingen horen? Zijn je velden vrij instelbaar of vast? Heb je een 1 op 1 mapping met een database?
• De business regels (security, workflow, publishing, koppelingen naar andere systemen)
• Presentation engine: hoe zorg je ervoor dat je content op de juiste manier getoond wordt? Gebruik je een template engine? XSLT? Smarty? eigen fabrikaat? Hoe zorg je dat bij een URL de juiste content wordt getoond? hoe werkt caching?

De basiskeuze is wat mij betreft (en daar moet ik Alex ook weer gelijk in geven ):

Ga ik voor een pagina gebaseerd systeem of een item gebaseerd systeem?

Ietwat gechargeerd maar:
Bij een pagina gebaseerd systeem: maak je in je CMS een pagina aan en ga je daar via modules content op tonen. Heel veel vrijheid voor een redacteur maar lastig om structuur af te dwingen. Vaak is er een scheiding tussen de sitenavigatie en een soort content bak waar alle content in opgeslagen wordt.

Bij een Item/object gebaseerd systeem is een item van een bepaald type, met vooraf gedefinieerde velden en een vooraf bepaalde rendering. Maak je een nieuwsbericht aan die heeft hij een bepaald aantal velden en structuur. Vaak komen sitenavigatie en contentstructuur 1 op 1 overeen.

Natuurlik zijn er ook hybride systemen mogelijk en heeft een item gebaseerd systeem oplossingen om meer vrijheid te geven in presentatie en vice versa.

[truegrit]

Ik heb zelf eens met tridion gewerkt, waar ze een soort van overervingssysteem hebben genaamd Blueprinting. Je zou dan bijvoorbeeld een "site" kunnen maken met alle templates, en vervolgens meerdere sites met "content", die allemaal de templatesite erven en een basissite met allemaal nederlandse teksten of engelse teksten.

Waarom ik dit zeg: dit vond ik dus heel handig en leek mij ook uitermate geschikt voor hele grote bedrijven om zo zaken te scheiden van elkaar. Als ik ooit een CMS zou gaan schrijven (wat ik dus niet van plan was) zou ik dat zeker ook implementeren. Zodoende zou ik al een oplossing hebben voor een paar belangrijke zaken.

In principe ga ik dus mee met de stelling dat je gewoon een shitload aan cms'en moet proberen om uit te vinden wat je het beste vind werken

[R4gnax]

truegrit schreef op woensdag 19 augustus 2009 @ 16:30:
Ik heb zelf eens met tridion gewerkt, waar ze een soort van overervingssysteem hebben genaamd Blueprinting. Je zou dan bijvoorbeeld een "site" kunnen maken met alle templates, en vervolgens meerdere sites met "content", die allemaal de templatesite erven en een basissite met allemaal nederlandse teksten of engelse teksten.

Zoiets doet het CMS wat wij ontwikkeld hebben ook, maar dan net een tikkie anders. Het combineert vaste pagina layout templates met voor-opgezette 'open ruimtes' (asp.net user controls met voorgeschreven functionaliteit, eigenlijk), met de op items gebaseerde aanpak zoals wasigh die beschrijft.

Bij het aanmaken van een 'pagina' kan de gebruiker dan kiezen welk template er gebruikt wordt, waarna hij de serie open ruimtes in dat template kan editen in de (instelbare) beschikbare talen waarin de site getoond kan worden.

Op het moment zijn we nog bezig met wat wijzigingen m.b.t. de menu structuren en 'globale' berichten, die altijd op een pagina van een bepaald type template moeten staan. Naar aanleiding daarvan zal ik het advies meegeven om heel goed na te denken over het navigatie model: hoe koppel je content aan bepaalde pagina's, waar het concept 'pagina' een URL is waar de gebruiker naar toe navigeert.

In ons geval kwamen we er bijvoorbeeld achter dat een directe 1-op-1 mapping van opgeslagen content items (in boom vorm) naar pagina's, niet altijd zo'n goed idee is. Triviaal voorbeeld: wat als je bijvoorbeeld een side-bar en een footer hebt die beiden linken naar een pagina met contact informatie?