[CMS] lokaal of op server van klant?

[RickyHeijnen]

Ik wil voor de websites die ik voor mijn klanten maak een CMS ontwikkelen. Nu zit ik met een soort dilemma. Nu zijn er twee mogelijkheden. Ik ontwikkel zelf een CMS voor al mijn klanten en die draait op mijn host (domein.nl/cms). De tweede mogelijkheid is om voor elke klant een eigen CMS te ontwikkelen en die op zijn server te laten draaien.

Bij mogelijkheid 1 (eigen host) weet ik niet precies hoe ik het moet doen met mysql databases. Moet ik voor elke klant een eigen database maken? En dan in het script met 2 databases verbinding maken (eigen db en die van de klant)?

Mogelijkheid 2 is het meest onhandig, als ik een nieuwe module maak, moet ik die bij alle klanten uploaden... En klanten kunnen zelf bij de bestanden van het CMS, dus dat is niet echt zo veilig.

Kan iemand mij een beetje de goede richting in sturen? Wat zijn jullie ervaringen hiermee?

Alvast bedankt!

[Rac-On]

nadeel van cms op jouw server is dat alle klanten afhankelijk zijn van de beschikbaarheid van jouw server, de vraag is of je dat wil. Als het om een beetje serieuse klanten gaat, zit je dan namelijk al aan 2 webservers, 2 databaseservers en een goede professionele hostern.

Je probleem met de modules zie ik niet zo. Een klant is toch niet verplicht om al je modules te gebruiken? Alstie er 1 nodig denkt te hebben, kan je hem uploaden en betaald de klant daarvoor (tenzij er sprake is van gratis updates/support oid). Dat de klanten er zelf bij kunnen is idd het geval. Hier zal je afspraken over moeten maken (indien files gewijzgd: geen support oid)

[Verwijderd]

tip: schrijf geen eigen CMS, waarom werk doen wat allang door 100'en mensen voor je gedaan is met heel veel uren:

Typo3 CMS.
Gratis en opensource, php/mysql, perfect! ongekende mogelijkheden!

[mabarto]

Of natuurlijk CMS reseller worden. Kun je gewoon marge verdienen, zonder daadwerkelijk veel arbeidsuren kwijt te zijn.

[Bluestorm]

Bedenk in iedergeval dat als je alle sites op één centraal CMS laat draaien, dat als je wat belangrijks veranderd, dat je moet zorgen dat al die sites allemaal blijven werken. (En dat soort structurele veranderingen zullen bijna gegarandeerd komen, bijvoorbeeld voor features die je van te voren niet zag aankomen) Terwijl als ze allemaal een eigen versie draaien kun je de sites die goed werken gewoon lekker met rust laten totdat het nodig is.

[RickyHeijnen]

Ik wil eigenlijk alle klanten dezelfde standaard modules geven. Gastenboek, fotoboek, formulieren, statistieken etc. Het werkt voor iedereen hetzelfde, alleen de websites maken het allemaal tot andere output, andere layout/stijl etc..

Maar ik zie heel vaak dat webdesign bedrijven een eigen cms hebben op hun eigen server, en ik vroeg me af hoe ze dat dan doen... Want dat zou qua administratie voor mij ook de makkelijkste oplossing zijn. Mijn hostingprovider heeft zijn mysql-server open staan voor verbindingen van buitenaf, dus dat is het probleem niet...

En met bestaande systemen werken is voor mij geen oplossingen, dat wordt voor mij een probleem als ik op maat gemaakte modules moet schrijven en ik werk al met een eigen administratiesysteem, dat wil ik erin verwerken.

[b19a]

Verwijderd schreef op maandag 05 september 2005 @ 13:04:
Typo3 CMS.
Gratis en opensource, php/mysql, perfect! ongekende mogelijkheden!

offtopic:
Sorry hoor, maar een CMS die anno 2005 nog sites maakt met tabellen (zie typo3.com) is in mijn ogen niet professioneel bezig. In het jaar 2005 zou ik graag een oplossing willen zien die werkt met XML, XSLT, Semantische code en duidelijke URL's.

zoetericky schreef op maandag 05 september 2005 @ 13:00:
Mogelijkheid 2 is het meest onhandig, als ik een nieuwe module maak, moet ik die bij alle klanten uploaden... En klanten kunnen zelf bij de bestanden van het CMS, dus dat is niet echt zo veilig.

Je hoeft jezelf niet te verplichten nieuwe modules aan bestaande klanten beschikbaar te stellen. Eventueel kun je een plugin-omgeving bouwen zodat updaten van een plugin/module makkelijker te realiseren is. Je zou de bestanden van je CMS kunnen beschermen met Zend Encryption (vanuitgaande dat je PHP gebruikt).

Mogelijkheid 2 lijkt mij beter, je klanten zijn dan in ieder geval niet van jouw hosting afhankelijk en je geeft klanten wat meer vrijheid.

[disjfa]

zoetericky schreef op maandag 05 september 2005 @ 13:30:
En met bestaande systemen werken is voor mij geen oplossingen, dat wordt voor mij een probleem als ik op maat gemaakte modules moet schrijven en ik werk al met een eigen administratiesysteem, dat wil ik erin verwerken.

Oh? Sinds wanneer kan je bij een bestaand cms geen eigen modules maken? Ik zou als ik jou was een keer naar het grote mambo topic zoeken

BoukeHaarsma schreef op maandag 05 september 2005 @ 13:31:
[...]

offtopic:
Sorry hoor, maar een CMS die anno 2005 nog sites maakt met tabellen (zie typo3.com) is in mijn ogen niet professioneel bezig. In het jaar 2005 zou ik graag een oplossing willen zien die werkt met XML, XSLT, Semantische code en duidelijke URL's.

Xml/xsl.... Wat is daar het doel van in een website En waarom mag een cms nu weer geen tabellen gebruiken? Dat is voor een normale html leek handig want dan hoeft hij zicht niet te verdiepen in html. En wat zijn de gebruikers van standaard cms voor een deel Juist de onwetende.

[ Voor 42% gewijzigd door disjfa op 05-09-2005 13:33 ]

[Bosmonster]

Ook al doe je het op je eigen server, dan nog zul je je modules moeten scheiden waar de klant voor betaalt. Je kunt ook niet ineens je klant met allemaal extra modules opzadelen, waar die niet op gevraagd en voor betaald heeft.

Ander punt is bijvoorbeeld uploads. Afbeeldingen en andere documenten wil je op de server van de klant hebben, dus zul je alsnog een soort upload module bij iedere klant neer moeten zetten wat het er allemaal niet eenvoudiger op maakt.

Als je al kiest om lokaal je CMS te draaien, dan zou ik daar alleen voor kiezen als je ook zelf een eigen server hebt (dus geen shared hosting pakketje) en de klanten verplicht kan stellen hosting ook bij jou af te nemen (is ook extra inkomsten).

[Hans1990]

Ik zou persoonlijk kiezen om 1 CMS te schrijven en dat op je eigen host te laten draaien. En dan een soort van database driver maakt die de databases enzo regelt (iets van dat als je een tabel in de klant db aanmaakt word die gebruikt, anders gewoon die van de 'standard' database). Hoe je dat oplost weet ik niet Voordeel hier van is ook dat je meer controle over je klanten site's hebt.

Tuurlijk is het wel riskant dat als jouw server down ligt de websites van al je klanten down liggen. Voor dit probleem zou je eventueel een extra server erbij zetten...

[b19a]

disjfa schreef op maandag 05 september 2005 @ 13:31:
Xml/xsl.... Wat is daar het doel van in een website En waarom mag een cms nu weer geen tabellen gebruiken? Dat is voor een normale html leek handig want dan hoeft hij zicht niet te verdiepen in html. En wat zijn de gebruikers van standaard cms voor een deel Juist de onwetende.

offtopic:
XML voor structurering van je data op de back-end. Een CMS dient gewoon nette semantische code te genereren die vervolgens door een CSS bestandje wordt opgemaakt. Dat de html leek geen html moet gaan kloppen is wel duidelijk, daar heeft hij geen verstand voor. Laat hem lekker de content beheren en laat je CMS de rest doen!

[We Are Borg]

www.zend.com Encoden die hap Desnoods met een jaarlijkste activatie om er meer controlle over te houden. Zo doet react dat volgens mij ook, weet het niet zeker (zend i.i.g. wel)

[disjfa]

BoukeHaarsma schreef op Monday 05 September 2005 @ 13:39:
[...]

offtopic:
XML voor structurering van je data op de back-end. Een CMS dient gewoon nette semantische code te genereren die vervolgens door een CSS bestandje wordt opgemaakt. Dat de html leek geen html moet gaan kloppen is wel duidelijk, daar heeft hij geen verstand voor. Laat hem lekker de content beheren en laat je CMS de rest doen!

Xml heeft totaal niets met semantische html te maken hoor

[b19a]

disjfa schreef op Monday 05 September 2005 @ 13:40:
[...]

Xml heeft totaal niets met semantische html te maken hoor

Dat hoor je mij ook niet zeggen. Ik zet het dan wel in 1 alinea neer, maar wat ik bedoel is dit:

Een CMS anno 2005:
1) Slaat content netjes op (liefst in XML)
2) Transformeert de content naar semantische code (evt met XSL(T))

[RickyHeijnen]

Bosmonster schreef op maandag 05 september 2005 @ 13:34:
Ook al doe je het op je eigen server, dan nog zul je je modules moeten scheiden waar de klant voor betaalt. Je kunt ook niet ineens je klant met allemaal extra modules opzadelen, waar die niet op gevraagd en voor betaald heeft.

Dat lijkt me niet het probleem, je geeft netjes in de database aan welk moduleID beschikbaar is voor welke klantID en hoppa. Of denk ik nu veel te simpel

Bosmonster schreef op maandag 05 september 2005 @ 13:34:
Ander punt is bijvoorbeeld uploads. Afbeeldingen en andere documenten wil je op de server van de klant hebben, dus zul je alsnog een soort upload module bij iedere klant neer moeten zetten wat het er allemaal niet eenvoudiger op maakt.

Alle klanten hebben FTP, wat is het probleem met uploaden over FTP... het enige probleem wat zich zou kunnen voordoen is wachtwoorden van FTP verbindingen ergens opgeslagen moeten worden, maar ook dit lijkt me redelijk goed te beveiligen.

Bosmonster schreef op maandag 05 september 2005 @ 13:34:
Als je al kiest om lokaal je CMS te draaien, dan zou ik daar alleen voor kiezen als je ook zelf een eigen server hebt (dus geen shared hosting pakketje) en de klanten verplicht kan stellen hosting ook bij jou af te nemen (is ook extra inkomsten).

Dat is ook een van de redenen dat ik hiernaar vraag. Ik zit eraan te denken om ook hosting aan te bieden en mijn klanten dan daar ook te plaatsen, maar een server huren is niet goedkoop, vandaar dat ik eerst alles goed wil uitzoeken.

[Bluestorm]

Een CMS anno 2005:
2) Transformeert de content naar semantische code (evt met XSL(T))

Ieder normaal CMS laat de gebruiker vrij in hoe de uiteindelijk output er uit ziet. Als een CMS mij oplegd wat voor HTML of whatever er uit komt is 't in iedergeval weinig flexibel. Als ik tabellen wil gebruiken voor m'n opmaak moet dat kunnen. Misschien wil ik wel een of ander vaag ander zelf verzonnen tekst based formaat outputten, leuk CMS als het me dan dwingt om semantisch correcte HTML te gebruiken.

Maar goed, maak gewoon voor je zelf een duidelijk overzicht van de voor en nadelen zou ik zeggen. Een installatie heeft natuurlijk duidelijk voordelen in onderhoud en compatible houden met verschillende PHP versies etc. Maar het kan best gebeuren dat je klanten krijgt die zelf de hosting in de hand willen houden, dat moet dan nog wel mogelijk zijn. Wat natuurlijk niet wil zeggen dat je de eerste optie niet standaard zou aan kunnen bieden als eerste keus.

[ Voor 23% gewijzigd door Bluestorm op 05-09-2005 13:58 ]

[Verwijderd]

BoukeHaarsma schreef op maandag 05 september 2005 @ 13:31:
[...]

offtopic:
Sorry hoor, maar een CMS die anno 2005 nog sites maakt met tabellen (zie typo3.com) is in mijn ogen niet professioneel bezig. In het jaar 2005 zou ik graag een oplossing willen zien die werkt met XML, XSLT, Semantische code en duidelijke URL's.

.

sorry tegen jou, maar ik weet niet of jij wel eens een echte typo3 site hebt gezien (1 door mij gemaakt bv!) en daar is toch echt geen tabelletje te bespeuren en alles netjes met css en divs enzo gepositioneerd.

chew on that

[RickyHeijnen]

Waarom zou je alles in div positioneren als het in tabellen makkelijker kan? Met die divs heb ik altijd problemen met verschillende browsers en nog erger met verschillende resoluties...

[Not Pingu]

BoukeHaarsma schreef op maandag 05 september 2005 @ 13:43:
[...]

Dat hoor je mij ook niet zeggen. Ik zet het dan wel in 1 alinea neer, maar wat ik bedoel is dit:

Een CMS anno 2005:
1) Slaat content netjes op (liefst in XML)
2) Transformeert de content naar semantische code (evt met XSL(T))

Waarom nou die XML-geilheid overal? Is een database niet goed genoeg meer ofzo? Ik vind de manier waarop je stelt dat je CMS niet professioneel is als het geen XML/XSLT gebruikt, nogal ondoordacht.


@TS: Ik zou gewoon 1 redistribueerbaar CMS pakket schrijven (dat heb je als het goed is al) en dat bij klanten op hun eigen server installeren. Als je het op je eigen server doet, moet je je afvragen of de beveiliging wel goed is en er niet situaties ontstaan waarbij klanten in elkaars data kunnen kijken, en of je server de load van meerdere websites aankan. Want als je server plat gaat / langzaam wordt door teveel verkeer, zijn meteen een X aantal klanten pissed.

Het steeds moeten updaten met nieuwe functionaliteit lijkt me niet terzake doende. Alleen bugfixes en kritische updates moet je overal doorvoeren (en hoe lang duurt dat nou), voor de rest krijgt de klant waarvoor hij in eerste instantie betaalt. Als jij specifiek voor 1 klant een module ontwikkelt, dan heeft die ene klant daar recht op maar de rest niet. Die ene klant betaalt ervoor.

[Verwijderd]

BoukeHaarsma schreef op Monday 05 September 2005 @ 13:31:

offtopic:
Sorry hoor, maar een CMS die anno 2005 nog sites maakt met tabellen (zie typo3.com) is in mijn ogen niet professioneel bezig. In het jaar 2005 zou ik graag een oplossing willen zien die werkt met XML, XSLT, Semantische code en duidelijke URL's.

offtopic:
inderdaad en geen php en mysql, als we dan toch professioneel willen doen