[php] centraal CMS

[rewind.]

Ik zit op het moment een beetje na te denken over een centraal CMS voor meerdere sites.

Wat zijn de eisen:

• 1 centrale plek voor het cms zelf (onderhoudbaarheid)
• 1 centrale plek voor klantgegevens met modules etc.
• MySQL op domein van de klant (pagina's, menu's, gebruikers, etc..)
• Voorkant op domein van de klant
• Geuploade documenten van de klant op domein van de klant

Op het internet heb ik een beetje zitten kijken en kwam ik niet veel verder dan het allow_url_include wat teveel beveiligingsissues met zich mee brengt.

Hoe kan ik dit op een veilige manier oplossen?

[Kettrick]

De mogelijkheden hiervan zijn redelijk afhankelijk van je hosting omgeving.
Op een eigen server kan je de shared code ergens neerzetten, en alles sites dat laten includen.

Dergelijke trucs zijn op een shared omgeving vaak onmogelijk.

Je kan ook zelf een SVN repos bijhouden, en de shared code uploaden naar de sites.
Op deze manier heb je iets meer controle over welke site een update krijgt.
Als je je CMS update en er valt ergens iets om is dat lastig te vinden als je 50 sites hebt.

[ Voor 35% gewijzigd door Kettrick op 20-02-2008 16:25 ]

[AW_Bos]

Hoezo MySQL op het domein van de klant? Je hebt de CMS zelf centraal staan, en de database is een belangrijk onderdeel daarvan.
Daarvoor moet je dus per domein van de klant de database gaan upgraden, als jij een upgrade doet aan je CMS met nieuwe opties enzo waarbij je MySQL structuur moet worden vernieuwd.

Ikzelf zou ook MySQL centraal houden, en de CMS, en templates en configfiles voor de klant bereikbaar houden op evt hun FTP (of een FTP acocuntje die jij aanmaakt).

[Kettrick]

Ik denk dat je voordat de discussie verder gaat eerst duidelijk moet maken wat je bedoeld met

MySQL op domein van de klant

Dit kan op 10K verschillende manieren opgevat worden

offtopic:
Of ik snap het niet, dat kan natuurlijk ook

[sanzut]

Misschien is er voor het CMS data nodig die uit de systemen van de klant moet worden gehaald?

[Webgnome]

sanzut schreef op woensdag 20 februari 2008 @ 23:16:
Misschien is er voor het CMS data nodig die uit de systemen van de klant moet worden gehaald?

Maar dat heeft dan toch niks met het CMS op zichzelf te maken (aka de structuur). Datn is het puur een module die gegevens van DB1 uitleest en combineerd met de CMSDB / Modules. Wat er bedoelt wordt is waarschijnlijk dat het CMS + backend gewoon draait op de klant zijn systeem.

[ Voor 11% gewijzigd door Webgnome op 21-02-2008 08:07 ]

[rewind.]

Alle sites zullen op dezelfde server gaan draaien. voor de overzichtelijkheid wil ik wel voor iedere klant een eigen database hebben, als nadeel heb je dan dat je voor iedere wijziging alle databases bij langs moet.

[Webgnome]

Stoney187 schreef op donderdag 21 februari 2008 @ 08:27:
Alle sites zullen op dezelfde server gaan draaien. voor de overzichtelijkheid wil ik wel voor iedere klant een eigen database hebben, als nadeel heb je dan dat je voor iedere wijziging alle databases bij langs moet.

ALS het om een database wijziging gaat idd. Dat lijkt me echter niet zo'n heel groot probleem aangezien je een main prog zou kunnen draaien die alle sites bijhoud en eventueel updates doorpushed..

[Kettrick]

Hoeveel sites gaat het ongeveer om?, wij hebben ooit ook eens over iets dergelijks nagedacht en hebben uiteindelijk toch elke site een eigen snapshot gegeven. Dit is voor 10 .. 50 sites prima te doen. Als je het over 1000 sites hebt is het een ander verhaal.

[unclero]

Stoney187 schreef op woensdag 20 februari 2008 @ 16:22:
Ik zit op het moment een beetje na te denken over een centraal CMS voor meerdere sites.

Wat zijn de eisen:

• 1 centrale plek voor het cms zelf (onderhoudbaarheid)
• 1 centrale plek voor klantgegevens met modules etc.
• MySQL op domein van de klant (pagina's, menu's, gebruikers, etc..)
• Voorkant op domein van de klant
• Geuploade documenten van de klant op domein van de klant

Op het internet heb ik een beetje zitten kijken en kwam ik niet veel verder dan het allow_url_include wat teveel beveiligingsissues met zich mee brengt.

Hoe kan ik dit op een veilige manier oplossen?

Grappig, ik ben momenteel met hetzelfde aan het werk (in me vrije tijd) .
Waar ik dan onderscheid in maak is bij de centrale modules dat alleen de logica centraal word opgeslagen, maar dat de 'controls' wel in de klantmap komen.

[unclero]

Stoney187 schreef op donderdag 21 februari 2008 @ 08:27:
Alle sites zullen op dezelfde server gaan draaien. voor de overzichtelijkheid wil ik wel voor iedere klant een eigen database hebben, als nadeel heb je dan dat je voor iedere wijziging alle databases bij langs moet.

Gewoon niet wijzigen danwel alles backwards compatible houden. Is eenvoudiger dan het klinkt .
Ikzelf heb een centrale database voor site/klant-gerelateerde meuk, en verder heeft dan iedere site/klant ook een database waar alleen de eigen rommel (van de in gebruik zijnde modules, en sitecontent) in opgeslagen wordt .

[Kettrick]

unclero schreef op donderdag 21 februari 2008 @ 09:21:
[...]


Gewoon niet wijzigen danwel alles backwards compatible houden. Is eenvoudiger dan het klinkt .
Ikzelf heb een centrale database voor site/klant-gerelateerde meuk, en verder heeft dan iedere site/klant ook een database waar alleen de eigen rommel (van de in gebruik zijnde modules, en sitecontent) in opgeslagen wordt .

Nog afgezien van je eigen skillz heb ik behoorlijk wat ellende gehad met bijvoorbeeld adoDB en smarty, beide zijn intussen aardig af maar hebben in het verleden best vaak kleine aanpassingen doorgevoerd in de API. Als je dat update op 1000 sites is de kans dat er één omvalt best groot..

[unclero]

RoeLz schreef op donderdag 21 februari 2008 @ 09:33:
Nog afgezien van je eigen skillz heb ik behoorlijk wat ellende gehad met bijvoorbeeld adoDB en smarty, beide zijn intussen aardig af maar hebben in het verleden best vaak kleine aanpassingen doorgevoerd in de API. Als je dat update op 1000 sites is de kans dat er één omvalt best groot..

Klopt, maar wat ik ook bedoelde daarmee is gewoon door het eenvoudig te houden.
Je zou de boel zo moeten ontwerpen dat als je iets aan gaat passen, je in de logica aanpast, en niet in de data. Ook moet je zorgen dat je zoveel mogelijk data centraal weet te houden.

[steffex]

Grappig, ongeveer jaar geleden een systeem gebouwd voor mijn werk dat ongeveer hetzelfde doet

Draaien nu zo'n 150+ klanten op. Ben wel bereid wat advies te geven PM of mail maar!

[unclero]

stef-o schreef op donderdag 21 februari 2008 @ 12:32:
Grappig, ongeveer jaar geleden een systeem gebouwd voor mijn werk dat ongeveer hetzelfde doet

Draaien nu zo'n 150+ klanten op. Ben wel bereid wat advies te geven PM of mail maar!

Yuh, ik heb zoiets jaren geleden ook gebouwd voor mijn werk, in Purrel alleen.

En nu ik weer twee werkgevers verder ben wil ik zo'n systeem in PHP hebben .
Ook heb ik bij andere werkgevers veel nieuwe dingen gezien die ik er ook graag in wil hebben .