Voor een platform dien ik vanuit 1 CMS oneindig veel sites toe te kunnen voegen elk met eigen databases verdeeld over o.a. web, mail, database, content servers.

In geval van een webshop kun je een multishopmodule gebruiken, alles draait dan geloof ik vanuit individuele databases maar je hebt alle tickets en administratie in 1 paneel.

In Wordpress kun je een multi blog starten met het gebruiksgemak van 1 cms maar voor hetzelfde heb je wel 20 sites draaien. Dit gebruiksgemak ben ik naar op zoek maar dan beter georganiseerd om 1 groot log geheel te voorkomen.

Het splitsen van databases is op voorhand al bedoeld om de sites individueel zo efficiënt en snel mogelijk te laten draaien. Normaal doe je dit pas als een site zeer groot wordt maar als ik de mogelijkheid dan toch heb waarom zou ik het niet direct bij aanvang doen ?

Hoe pak je dit op de "juiste" manier aan, hoe koppel je 20 sites op een veilige manier met klantenaccounts, administratie, overzichtelijke aan 1 cms. Ik moet ook kunnen zien of men van site A of B afkomstig is.

Daar ik constant nieuwe sites aan het CMS wil koppelen zoek ik hier een handige methode voor, bijvoorbeeld een +1 voeg een nieuwe site toe functionaliteit.
Klinkt dit logisch ? (Een automatisch gegenereerd geheel wat ik dan zou kunnen skinnen). Met hetzelfde gemak als het aanpaken van een product in een webshop ? Het klinkt zo logisch maar hoe te organiseren en of dit daadwerkelijk een slimme zet is vraag ik mij af.

Wat voor mij vooral onduidelijk is hoe je meer dan 1 individuele site op aan 1 beheerpaneel kunt koppelen.
Ik heb wel scripters in mijn persoonlijke netwerk maar omdat zij dit ook nog niet eerder hebben gedaan vraag ik het hier in de hoop helderheid te krijgen.

Het zijn geen losse bedrijven en daarmee dacht ik er verstandig aan te doen dit te benaderen als het voorbeeld "multi shop" en de sites als diensten / producten te beschouwen en alles binnen 1 kanaal binnen te laten komen. Echter dient zich de situatie aan, dat als ik een site los willen verkopen dan kan dit niet. omdat alles met elkaar verweven zit.

Aangezien je alles ook los wilt hebben omdat je het eventueel ooit wilt verkopen is denk ik gewoon het handigste dat je de shops standalone opzet en deze met je hoofd CMS verbind met api's? Het opzetten van de shops kun je dan evt doen met een van de vele deployment tools die er zijn.

Ok, de gebruikelijke situatie zeg maar maar dan lees je alles uit in de hoofdcms, hier heb ik aan gedacht maar is dit niet minder veilig dan een directe implementatie ? Het is in ieder geval wel een extra stap (of wellicht een stap die de situatie juist eenvoudiger maakt) maar dat is juist wat ik probeer te doorgronden om objectief zaken tegen elkaar af te kunnen wegen. Als er geen argumenten zijn aangaande de veiligheid (wat ik niet verwacht) dan lijkt het mij zo gek nog niet om voor een a.p.i. te gaan. Dit moet je alleen wel kunnen maken.

Ik vraag me dan alleen wel af hoe bijvoorbeeld zo'n Magento / Presta multishop werkt want daar is geen a.p.i. voor nodig.

Wat de meeste zogenaamde 'multi'-blabla dingen doen is gewoon zorgen dat ze relevante onderdelen ( database connectie gegevens, paden ) in een kleine aparte module onderbrengen die op het 'hoofdcms' wordt geïnstalleerd (eventueel met een paar menu items om te switchen).
Dat is eigenlijk helemaal niet zo erg spannend.

In die module toon je bv. een keuzelijst met de cmssen die 'eronder' hangen en op basis van de keuze zet je een sessievar (pseudocode).

als keuze = 'cms 1' dan
sessievar = 'cms 1'
etc...

In al je cmssen zet dan iets zoals (pseudocode):

als sessievar met cms-keuze bestaat dan
laad connectie gegevens en paden van cms in sessievar
anders
laad eigen connectie gegevens en paden

Uiteraard zul je links en rechts iets moeten controleren (bestaat cms wel etc) maar in grote lijnen ben je er dan wel.