[PHP] Meerdere sites op 1 CMS, hoe?

[Sjoerd]

Een tijd geleden ben ik begonnen met het programmeren maar van een cms (incl editor en die dingen)
Ik ben ondertussen zover dat alles mooi werkt.
Echter heeft elke (test)site nu een eigen cms.

Dit heeft nadelen voor mij:
-als ik iets aan het cms verander moet ik alle sites,cms'en aanpassen
-het kost meer schijfruimte op mijn hosting
-mocht ik een update uitvoeren die erg drastisch is en er een bug in zit gaan alle sites down, en niet slechts 1tje

Voordelen:
-1 aanpassing wordt overal doorgevoerd
-overzichtelijker
-scheelt schijfruimte
-misschien veiliger?

Ik wil dus dat ik 1 cms 'engine' krijg door mijn huidige aan te passen, waarop meerdere sites kunnen draaien.
Zoals ik het zag:

1 main database met hierin een tabel
sites
id
naam
databasenaam (die verwijst naar de site specifieke database)

Ik zag dit voor me door bijvoorbeeld het volgende
www/htdocs/html/cms/site1
www/htdocs/html/cms/site2

mijn scriptje kijkt dan naar het achtervoegsel, zoekt dit op in de database en verwijst dan door naar de goede database intern, ik sla de gegevens op in een session of iets.


Of zouden jullie dit anders aanpakken?

[Slagroom]

Ik heb een CMS ontwikkeld dat naar het domein kijkt en ik heb eentje ontwikkeld dat net zoals jij naar de directory kijkt. Het laatste heeft als voordeel dat je flexibeler bent. Je kan bijvoorbeeld meerdere CMS'en op 1 domein zetten.

[Sjoerd]

Dat is inderdaad de reden dat ik zo met directory's zou werken.
Het is ook makkelijker om van www.mijnsite1.com te laten verwijzen naar www/htdocs/html/cms/site1

dan bv www/htdocs/html/cms?site=1

[Verwijderd]

Als de site's bij elkaar horen, dan is het het makkelijkst om het gewoon in 1 database te doen lijkt mij. Maar kan je vanaf alle servers wel de database openen van de server waar het cms op moet komen te draaien?

[Sjoerd]

Momenteel draaien de sites (die niet bij elkaar horen) ook gewoon opdezelfde server, genoeg ruimte, onbeperkt databases, ik wou dus momenteel nog geen extra kosten gaan maken om sites op een andere server onder te brengen.

Maar naar de toekomst toe is dit idd wel een intressante issue, ik kan mijn database alleen bereiken vanaf de server zelf.
Mocht het voorkomen dat een site toch op een andere server geplaatst moest worden om 1 of andere reden kan ik natuurlijk nog altijd mijn cms ook daar plaatsen in de toekomst. thx for thinking

[Verwijderd]

Opzich hoeft dat nog nieteens hoor, je zou ook kunnen kijken naar XML?

[Sjoerd]

Verwijderd schreef op woensdag 05 september 2007 @ 08:51:
Opzich hoeft dat nog nieteens hoor, je zou ook kunnen kijken naar XML?

Momenteel ben ik nog niet heel bekend met XML en de mogelijkheden hiervan
ik wil natuurlijk het liefst mijn cms aanpassen met zo weinig mogelijk werk.

Dan begin ik nadien weer wel met v2.0 van de grond af aan opnieuw op te bouwen met mogelijk XML.

[Padschild]

Verwijderd schreef op woensdag 05 september 2007 @ 08:51:
Opzich hoeft dat nog nieteens hoor, je zou ook kunnen kijken naar XML?

Wat stel je voor om met XML te gaan doen dan?

[Verwijderd]

Padschild schreef op woensdag 05 september 2007 @ 09:01:
[...]


Wat stel je voor om met XML te gaan doen dan?

Hip doen, zoals de rest. Oja, je moet ook Ajax gebruiken

Ontopic:
In een CMS wat ik geschreven heb gebruik ik 1 settings bestand (database etc) en een bestand wat de boel in werking zet. Als ik die twee kopieer heb ik bij wijze van al een nieuwe 'site'. Met php check ik welk domein opgevraagd wordt, en stuur de bezoeker dan door: als domeina.nl -> site-a.php, als domeinb.nl ->siteb.php.

Eventueel nog een extra template-bestand, anders ziet het er zo hetzelfde uit. De onderliggende PHP-code is voor elke site hetzelfde.

[Sjoerd]

Verwijderd schreef op woensdag 05 september 2007 @ 09:19:
[...]
Hip doen, zoals de rest. Oja, je moet ook Ajax gebruiken

Oke ik denk dat ik het dan toch maar op de manier ga doen zoals ik zelf voorstelde, mapstructuur bekijken en dan een keuze maken

[Sjoerd]

Hmm het blijkt toch lastigeren dan ik dacht om het op deze manier te doen

PHP:

$sitenaam= str_replace("/","",substr($_SERVER['PHP_SELF'],0,-10)); //-10 om index.php eruit te filteren en overbodige / eruit te halen

switch ($sitenaam){
    case "site1":
        $host = "localhost";
        $db = "";
        $user= "";
        $pass= "";
    case "site2":
        $host = "localhost";
        $db = "";
        $user= "";
        $pass= "";
    default:
        echo "Deze site bestaat niet!";
}

Probleem hiermee is echter dat ik dan nog op elke locatie van een site mijn cms moet hebben omdat het anders niet werkt (stom van me dus )

(overigens was bovenstaande code gewoon even om te testen)

[ Voor 5% gewijzigd door Sjoerd op 05-09-2007 10:42 ]

[disjfa]

Je kan ook de engine een dir lager zetten dan de documentroot. Zo kan je per site alles regelen, de document root goed instellen en in je cms inladen moet je dan alleen "../laadcms.php' zetten oid.

Dan hoef je alleen je templates en styles in je afhankelijke website zetten en kan je gewoon alles in een config.php/ini/whatever zetten in je document root

[Verwijderd]

Als je Apache (ik neem aan dat je Apache gebruikt) configuratie kunt aanpassen, kun je alle sites dezelfde DocumentRoot geven. Daarmee hoef je het CMS maar 1 keer neer te zetten. Als dat niet kan, zet je de code van het CMS op 1 centrale plek en zet je in de mappen waar sites komen een index.php die alleen maar de CMS code include.

[Sjoerd]

disjfa schreef op woensdag 05 september 2007 @ 10:46:
Je kan ook de engine een dir lager zetten dan de documentroot. Zo kan je per site alles regelen, de document root goed instellen en in je cms inladen moet je dan alleen "../laadcms.php' zetten oid.

wat is het voordeel dat je de enige een dir lager zet dan de documentroot?

verdere structuur van mijn cms:
cms/admin/ (van hieruit kan je paginas bewerken,...)
cms/templates/site1/ (hierin zit enkel een index.html en wat afbeeldingen + stylesheet
cms/index.php (zorgt voor afhandeling inhoud van de website, template,....)

[Johnny]

Heb je trouwens ook al nagedacht over rechtenbeheer? Ik neem aan dat je nu zelf de enige beheerder bent, maar als je later andere gebruikers wilt toevoegen wil je waarschijnlijk niet dat ze allemaal alle websites kunnen aanpassen.

Verder heeft een enkel cms met meerdere websites ook wat nadelen, ten eerste is je website minder draagbaar, je kan hem niet zomaar overzetten naar een andere server, tenzij je daar bij het ontwerpen van het systeem goed rekening mee houdt.

Een ander aspect is de performance, alles opslaan in een enkele database kan dingen wel behoorlijk vertragen als je per website veel (honderdduizenden rijen) data in tabellen hebt.

[Sjoerd]

Johnny schreef op woensdag 05 september 2007 @ 12:45:
Heb je trouwens ook al nagedacht over rechtenbeheer? Ik neem aan dat je nu zelf de enige beheerder bent, maar als je later andere gebruikers wilt toevoegen wil je waarschijnlijk niet dat ze allemaal alle websites kunnen aanpassen.

Verder heeft een enkel cms met meerdere websites ook wat nadelen, ten eerste is je website minder draagbaar, je kan hem niet zomaar overzetten naar een andere server, tenzij je daar bij het ontwerpen van het systeem goed rekening mee houdt.

Een ander aspect is de performance, alles opslaan in een enkele database kan dingen wel behoorlijk vertragen als je per website veel (honderdduizenden rijen) data in tabellen hebt.

Mijn cms heeft al de mogelijkheid voor meerdere gebruikers, verder is het dus zo dat elke site zijn eigen aparate database blijft behouden (mede door de aspecten die je aanhaalt)
Dit brengt meteen met zich mee dat het inloggen dus ook totaal gescheiden is van andere sites.

Het probleem is dus echt dat ik eigenlijk een goede slimme manier moet vinden om van database te kunnen "switchen".

Overdraagbaarheid is opzich niet echt een probleem aangezien ik dan gewoon het totale cms oppak en ergens op een andere server drop, incl de database voor die betreffende website.

[Verwijderd]

Als je 't goed opzet heb je 1 keer je code (een dir lager of niet, maakt niet zoveel uit), en 1 "settings" file, waarin je doet wat je hierboven beschrijft:

PHP:

$sitenaam= str_replace("/","",substr($_SERVER['PHP_SELF'],0,-10)); //-10 om index.php eruit te filteren en overbodige / eruit te halen

switch ($sitenaam){
    case "site1":
        $settings['host'] = "localhost";
        $settings['db'] = "";
        $settings['user'] = "";
        $settings['pass'] = "";
        $settings['template'] = "templ-a";
    case "site2":
        $settings['host'] = "localhost";
        $settings['db'] = "";
        $settings['user'] = "";
        $settings['pass'] = "";
        $settings['template'] = "templ-b";
    default:
        echo "Deze site bestaat niet!";
}
// en dan:

loadContent($settings);

Of iets van dergelijke strekking.

In loadContent doe je zoiets:

PHP:

require('/var/www/html/foo.php')
require('/var/www/html/bar.php')

// en alles wat je verder nodig hebt.

[Verwijderd]

disjfa schreef op woensdag 05 september 2007 @ 10:46:Je kan ook de engine een dir lager zetten dan de documentroot. Zo kan je per site alles regelen, de document root goed instellen en in je cms inladen moet je dan alleen "../laadcms.php' zetten oid
....

Dat is een super idee.
Je zou dan kunnen doen:

code:

www/htdocs/html/cms/ => hele "framework" met DataBase classes, Template classes enz.
www/htdocs/html/site1/ => eerste site, die ../laadcms.php inlaadt.
www/htdocs/html/site2/ => tweede site, die dezelfde ../laadcms.php inlaadt.

voordeel is, dat, als je iets in de DataBase classe verandert, je het alleen maar naar
www/htdocs/html/cms/ hoeft te uploaden.

Je kunt dan de site-specifieke zaken wel in www/htdocs/html/site1/ plaatsen zoals evt. speciale admin, speciale templates, stylesheets, enz. (alhoewel ik admin ook weer in het cms zou laten staan)

Alle sites zouden in 1 DataBase kunnen. Zet je gewoon SiteID erbij en zorg je dat die in de WHERE clauses van je SQL statement worden meegenomen.
Per site een DB is ook een oplossing, dus wellicht niets aan veranderen.

Willen sommige gebruikers trouwens niet in site1 en site2 kunnen inloggen?

[Sjoerd]

kan zo 1-2-3 geen situatie verzinnen waarom ze dit zouden willen, en willen ze het toch dan kan het gewoon. moeten ze alleen voor site1 en site2 apart inloggen...

nu snap ik nog niet wat het idee ervan is om het cms lager dan de root te zetten tov gewoon root/cms

[disjfa]

Sjoerd schreef op woensdag 05 september 2007 @ 15:09:
nu snap ik nog niet wat het idee ervan is om het cms lager dan de root te zetten tov gewoon root/cms

Dat is in mijn ogen een mooiere oplossing voor sfscheiding van de websites Maar het is gewoon een persoonlijke mening. Dus het andere voorbeeld wat hier gepost word kan precies hetzelfde gebruikt worden.

Het ligt net aan wat je zelf het gemakkelijkst vind

[Sjoerd]

disjfa schreef op woensdag 05 september 2007 @ 15:12:
[...]

Dat is in mijn ogen een mooiere oplossing voor sfscheiding van de websites Maar het is gewoon een persoonlijke mening. Dus het andere voorbeeld wat hier gepost word kan precies hetzelfde gebruikt worden.

Het ligt net aan wat je zelf het gemakkelijkst vind

Oke snap het, ik ga er maar is mee aan de slag denk dat het de makkelijkste manier is

[Sjoerd]

Ik kom er maar niet uit hoe ik nu netjes meegeef over welke site het gaat..
ondanks het voorbeeld van elguapo

momenteel heb ik het volgende:
cms
site1 en daarin staat:
- een index.php met "header("Location:cms/index.php");"
- een mapje admin met daarin een index.php "header("Location:cms/admin/index.php");"

nu vanzowel cms/index.php als cms/admin/index.php wordt cms/includes/config.php aangeroepen.
Nu heeft config.php natuurlijk geen idee met welke database hij een connectie tot stand moet brengen.
Dus een aantal opties: (een parameter meegeven die config.php uitleest bv. config.php?site=site1) maar dat is eigenlijk maar niks en niet mooi.

in config.php een functie maken "connect($sitenaam)" zou al beter werken probleem is echter dat dit niet lukt aangezien ik werkt met "header("Location:cms/index.php");" en dus niet vanuit index.php die functie kan oproepen aangezien index.php ook geen idee heeft waar over het gaat...


Nog iemand die kan volgen en een goede oplossing heeft?
ps. waarom werk ik met die header location, omdat ik anders alle paden van mijn cms moet gaan veranderen en dergelijke, ik wil kijken of het zo kan

[disjfa]

Heb je mijn idee gebruikt: Andere document root, andere http_host, check daarop.

Heb je elguapo en andere mensen hun idee gebruik. Ckeck http_host. Lees verschillende database connecties in.

[Sjoerd]

nadeel is wel dat het lastig is wanneer het een 2talige site moet worden, dan moet ik 2domein namen aanvragen voordat het werkt.

Verder werkt dit idee idd super

overigens er net achtergekomen dat wanneer ik mijn cms daadwerkelijk buiten mijn htdocs zet ik deze niet meer kan benaderen maar niet doen dus

[ Voor 30% gewijzigd door Sjoerd op 05-09-2007 17:29 ]

[Verwijderd]

nadeel is wel dat het lastig is wanneer het een 2talige site moet worden, dan moet ik 2domein namen aanvragen voordat het werkt.

Is dat het enige verschil tussen site1 en site2?

overigens er net achtergekomen dat wanneer ik mijn cms daadwerkelijk buiten mijn htdocs zet ik deze niet meer kan benaderen maar niet doen dus

Op welke manier kun je hem niet meer benaderen?

Kun je in site1 je config.php maken in plaats van dat je de config uit cms aanroept.
In config zeg je welke db je wilt hebben enz.

Verder roep je vanuit site1 je laadcms.php aan. (als je die hebt)
Die laadcms.php roept de overige bestanden en classes enz. aan.

dus dan krijg je:

code:

/cms
/cms/laadcms.php
/cms/classes enz.

/site1/config.php
/site1/index.php die config.php en laadcms.php aanroept
idem voor site2

[AW_Bos]

Ikzelf zit ook na te denken over een dergelijk systeem, en denk dat ik inderdaad de hele engine in een niet voor users toegankelijke map zet buiten hun FTP map, en dat de user zelf de templates kunnen beheren in de FTP.
Maar goed, dan is er het probleem dat net elke CMS gelijk is, en de een wilt er een simpel form in, en de ander een Voetbal-standensysteem en de ander weer een fotoalbum.
Dit ben ik van plan te regelen met plugins, maar hier ben ik nog niet echt over uit.

En over de databases, ik denk dat ik voor elke user een aparte database maak, want een plugin kan uiteraard weer een losse tabel gebruiken (of een aangepaste versie van de normale database).

[Verwijderd]

Dan zou het dus worden : Alle standaard zaken in de /cms
en alle aanpasbare zaken zoals configs, plugins en templates in de /site

offtopic:
iedereen is tegenwoordig zijn eigen cms aan het bouwen

[Sjoerd]

Verwijderd schreef op donderdag 06 september 2007 @ 07:23:

offtopic:
iedereen is tegenwoordig zijn eigen cms aan het bouwen

Jij bent niet meer cool

Ik heb dus alle "plugins" in 1 map gegooid en vervolgens heb ik een tabel "plugings" met alle plugins hierin, met een veld 'actief' de actieve plugings worden dan geinclude voor een gebruiker (ik kan dit makkelijk doen omdat iedere klant toch zijn eigen database heeft

[Sjoerd]

Ik dacht dat $_SERVER['HTTP_HOST']; de oplossing zou zijn, maar helaas ik maak gebruik van url forwards en wanneer ik www.site1.be forward naar mijndomein/cms ziet hij de http_host natuurlijk als mijndomein/cms dit is dus geen topei oplossing dacht echt dat het het was...

[Verwijderd]

Je gebruikt een forwarded-frame? Daar zou ik sowieso van af stappen

Je kan natuurlijk wel laten forwarden naar mijndomein/site1.php en daar iets mee doen.

[xiD]

overigens er net achtergekomen dat wanneer ik mijn cms daadwerkelijk buiten mijn htdocs zet ik deze niet meer kan benaderen maar niet doen dus

Dat niet kunnen benaderen buiten de /htdocs heeft waarschijnlijk te maken met open_basedir instellingen in Apache. Als je bij de configuratie kan zou je dat kunnen aanpassen.

Dit zorgt er namelijk voor dat je niet zomaak files kan includen buiten je wwwroot, ivm een stukje veiligheid.

zie; http://wiki.apache.org/httpd/SecuringPHP

[ Voor 18% gewijzigd door xiD op 06-09-2007 11:03 ]

[Sjoerd]

Ik ga denk ik maar even spelen met de server configuratie zodat het toch allemaal gaat werken zoals ik wil uiteindelijk bedankt voor het linkje overigens

[T-MOB]

Als het om je eigen server gaat kun je het vrij makkelijk regelen in het bestandssysteem. Je maakt ergens een mapje waar de code van je CMS staat bv. /var/cms_available/Sjoerd.V1/.
Op elke site waar je de cms code nodig hebt symlink je die map op de plaats waar je hem normaal ook zou plaatsen.

Wat je met $_SERVER probeert is me verder een raadsel. Je kun toch zorgen dat op domein X sitespecifieke configuratiebestanden worden ingeladen voordat het cms geladen wordt?

[Sjoerd]

T-MOB schreef op donderdag 06 september 2007 @ 12:17:
Als het om je eigen server gaat kun je het vrij makkelijk regelen in het bestandssysteem. Je maakt ergens een mapje waar de code van je CMS staat bv. /var/cms_available/Sjoerd.V1/.
Op elke site waar je de cms code nodig hebt symlink je die map op de plaats waar je hem normaal ook zou plaatsen.

Wat je met $_SERVER probeert is me verder een raadsel. Je kun toch zorgen dat op domein X sitespecifieke configuratiebestanden worden ingeladen voordat het cms geladen wordt?

Ik zal daar is even naar kijken ook
het idee van $_SERVER was dat het cms dus keek welke database hij moest connecten.
Wanneer het www.site1.nl was laad hij db_site1 bij site2.nl laad hij db_site2,... Dit was eigenlijk de makkelijkste manier om alles werkend te krijgen in die database zitten dan ook sitespecifieken instellingen en dergelijke.

Ik ben momenteel gewoon alle opties aan het testen en uitproberen

[T-MOB]

Sjoerd schreef op donderdag 06 september 2007 @ 12:22:
[...]

Ik zal daar is even naar kijken ook
het idee van $_SERVER was dat het cms dus keek welke database hij moest connecten.

Dat wil je toch niet hardcoded in je CMS regelen? Je moet dan namelijk voor elke site die je maakt je CMS aanpassen. Het is gebruikelijker om site-specifieke zaken in een los configuratiebestand te zetten. Per domein heb je dan een bestandje met instellingen waar je CMS code het mee kan doen. De sites zijn verder op geen enkele manier aan elkaar gerelateerd, behalve dat ze dezelfde codebase delen...

[Sjoerd]

Ik heb geen idee hoe ik dit zou moeten realiseren, zou je dit even kunnen verduidelijken met onzin code a la verkrijgdomein(), loadsettings()

Want ik zie niet hoe ik dit niet hardcoded kan doen...
Iemand gaat naar www.site1.nl en dan
(ps ik vraag dus niet voor een script request meer een algemeen idee )
alvast super bedankt allemaal

edit: begin me ondertussen af te vragen of het niet een beter idee is om een cms per klant te doen en dan een update script te schrijven zodat ik alles tegelijk kan updaten misschien nog wel makkelijker dan dit

[ Voor 23% gewijzigd door Sjoerd op 07-09-2007 11:42 ]

[WouZz]

Je kan ook een default config maken en deze overrulen door een <hostname>.config.php. (is exists).

[Verwijderd]

edit: begin me ondertussen af te vragen of het niet een beter idee is om een cms per klant te doen en dan een update script te schrijven zodat ik alles tegelijk kan updaten misschien nog wel makkelijker dan dit

Sta je onder tijdsdruk ofzo?
Het is toch beter, om het in 1 keer goed op te lossen?

Je hebt 1 dir, waar de CMS in staat met alle standaard bestanden
En per site / klant/ whatever een directory, die naar het initialisatiebestand van jouw CMS verwijst.

Als je een update hebt, dan hoef je alleen maar /CMS te updaten.

Over je andere vraag, detecteren welke site je moet hebben, moet ik even verder nadenken
(in de hoop dat iemand anders eerder met oplossing komt)
Het zou m.i. moeten lijken op een Language detectie script (op het eerste oog)

[Sjoerd]

Nee geen tijdsdruk maar kan er slecht tegen dat ik niet verder kan omdat ik niet weet hoe ik verder moet

1 cms blijft inderdaad toch wel het makkelijkste

[ Voor 20% gewijzigd door Sjoerd op 07-09-2007 12:08 ]

[disjfa]

Er zijn zat verzinselen om voor elke klant een apart cms te maken. Er zijn ook zat gevallen dat een algemeen cms handig is.Maar zover ik in de praktijk heb gezien is een cms per klant veel makkelijker is. Alleen het updaten word ingewikkeld omdat elke klant net wat andere specificaties heeft.

[r0bert]

Als in CmsKlant extends Cms lijkt me het makkelijkst....

[Verwijderd]

Dus concreet...
Iemand gaat naar http://www.site1.be en dan moet hij uitkomen op /home/site1/index.php
die zijn eigen config aanroept en de /cms inlaadt.

Iemand gaat naar http://www.site2.be en dan moet hij uitkomen op /home/site2/index.php
die zijn eigen config aanroept en de /cms inlaadt.

Dan kan dat toch met mod_rewrite?
Of met Virtual Host?
Ik zag 1 voorbeeld ff snel voorbij schieten (Virtual Host):

code:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^[^.]+.myvirtualserver.com$
RewriteRule ^(.+) %{HTTP_HOST}$1 [C]
RewriteRule ^([^.]+)\.myvirtualserver\.com(.*) /var/www/myvirtualserver/$1$2

(Corrigeer maar, als ik ernaast zit)

[Verwijderd]

Volgens wil TS dat, en daarnaast dat /home/site1/index.php dezelfde 'CMS-code' gebruikt als /home/site2/index.php.

En dat kan dus door in /home/sitex/index.php iets te zetten als include(/home/inc/myfirstcms.php)

[Sjoerd]

r0bert schreef op vrijdag 07 september 2007 @ 12:49:
Als in CmsKlant extends Cms lijkt me het makkelijkst....

Zou je dit iets verder kunnen toelichten? Ik ga nu kijken naar het hele mod_rewrite gebeuren

[Verwijderd]

Als je onvoldoende kennis van zaken hebt, zou ik je absoluut aanraden voor elke klant een eigen kopie van hetzelfde CMS te installeren. Anders ga je heel veel spijt krijgen als je voor site A iets moet bijwerken, wat voor site B niet moet.

[r0bert]

Sjoerd schreef op vrijdag 07 september 2007 @ 18:19:
[...]

Zou je dit iets verder kunnen toelichten? Ik ga nu kijken naar het hele mod_rewrite gebeuren

Mod_rewrite kun je inderdaad mee werken. Maar zoals Cheatah terecht opmerkt moet je wel goed weten wat je wel en niet gedeelt kunt maken. Daarom moet je je 'Cms extenden met CmsKlant'. Je hebt dus de basis die voor iedere klant hetzelfde is, en de klantspecifieke files. Zie het als lagen.

basislaag (alleen lokaal benaderbaar)
+-- klantlaag 1 (niet in klantlaag? > request naar basislaag)
+-- klantlaag 2 ...

Zo kun je je basiscms 'overrulen'. Denk dat dat je wel sterk maakt in opzet

[Verwijderd]

r0bert schreef op vrijdag 07 september 2007 @ 18:33:

Daarom moet je je 'Cms extenden met CmsKlant'.

Volgens mij is het eerder een kwestie van zorgend dat alles te configureren is, zodat je juist nie code hoeft te schrijven voor een specifieke klant. Ik heb nu echt wel heel wat CMS'en opgeleverd, en het merendeel was generieke code, met een klantspecifieke configuratie en een klein beetje maatwerk classes.

[BCC]

Iedereen loop gelijk programmeer technische oplossingen te vinden, maar niemand heeft het over het idee... volgens mij is het niet zo heel nuttig.

Sjoerd schreef op dinsdag 04 september 2007 @ 22:19:
Dit heeft nadelen voor mij:
-als ik iets aan het cms verander moet ik alle sites,cms'en aanpassen

Dit is meer een probleem in release beleid. Werk je met een CVS/SVN/Sourcesafe oplossing? Dan kun je met wat eenvoudig scriptjes makkelijk versies deployen.

-het kost meer schijfruimte op mijn hosting

Schijfruimte kost echt niets meer bij hosting. Daarnaast is de geuploade content bij de meeste websites een stuk meer dan die paar php-filtjes

-mocht ik een update uitvoeren die erg drastisch is en er een bug in zit gaan alle sites down, en niet slechts 1tje

Als je al je applicaties vanuit 1 systeem serveert, dan creeer je ook een single-point of failure.

Ik wil dus dat ik 1 cms 'engine' krijg door mijn huidige aan te passen, waarop meerdere sites kunnen draaien.
1 main database met hierin een tabel
sites
id
naam
databasenaam (die verwijst naar de site specifieke database)

Ik zag dit voor me door bijvoorbeeld het volgende
www/htdocs/html/cms/site1
www/htdocs/html/cms/site2

mijn scriptje kijkt dan naar het achtervoegsel, zoekt dit op in de database en verwijst dan door naar de goede database intern, ik sla de gegevens op in een session of iets.

Je moet enorm opletten of je geen security problemen gaat krijgen. Ingelogd op website 1 is ingelogd op website 2? Kun je pagina's van website1 ook op website2 bekijken?

[ Voor 4% gewijzigd door BCC op 07-09-2007 19:07 ]

[AW_Bos]

BCC schreef op vrijdag 07 september 2007 @ 19:06:
[...]
Je moet enorm opletten of je geen security problemen gaat krijgen. Ingelogd op website 1 is ingelogd op website 2? Kun je pagina's van website1 ook op website2 bekijken?

Niet als je de inlogsessies ook in de DB opslaat in de database voor site1. En ook cookies gelden maar voor 1 domein.

[ Voor 46% gewijzigd door AW_Bos op 07-09-2007 19:26 ]

[BCC]

Ariën Clay schreef op vrijdag 07 september 2007 @ 19:25:
[...]

Niet als je de inlogsessies ook in de DB opslaat in de database voor site1. En ook cookies gelden maar voor 1 domein.

Het kan allemaal wel, maar het is zeker niet triviaal. Daarnaast verlies je de mogelijkheid om verschillende klanten verschillende branches aan te bieden (zoals al genoemd) en zal de applicatie lastiger schalen. Ik zie veel meer heil in de goede code-base me lekker veel deployments.

[ Voor 27% gewijzigd door BCC op 07-09-2007 20:01 ]

[r0bert]

Cheatah
Volgens mij is het eerder een kwestie van zorgend dat alles te configureren is, zodat je juist nie code hoeft te schrijven voor een specifieke klant. Ik heb nu echt wel heel wat CMS'en opgeleverd, en het merendeel was generieke code, met een klantspecifieke configuratie en een klein beetje maatwerk classes.

Dat is weinig verschil met wat ik ook zeg? Ik zeg dat je bestaande code hebt die je kunt 'overrulen', komt volgens mij op hetzelfde neer als wat jij zegt? Anders moet je even het verschil uitleggen.

[kmf]

Ik heb kernel, init, config, templates en module-directory buiten de webroots. Deze worden gedeeld door een stuk of 6 sites.

De enige drie php-bestanden die in de webroot zijn, zijn 1 index.php bestand, 1 admin.php bestand, 1 config.php bestanden.


Index.php en admin.php includen config.php
Config.php geeft aan welke configuratie (die buiten de webroot in de config-folder staan) geladen moeten worden.
Aan de hand van de config worden de modules (waaronder CMS) geladen.

Alle sites delen dus dezelfde corebase, maar door de aparte config worden verschillende modules en templates geladen.

[BikkelZ]

Wat heeft dit CMS wat TYPO3 heeft? Buiten bragging rights?

[BCC]

BikkelZ schreef op zaterdag 08 september 2007 @ 12:10:
Wat heeft dit CMS wat TYPO3 heeft? Buiten bragging rights?

Security by obscurity