Meerdere sites met dezelfde php-code

[Shakespeare2000]

Ik zit met wat vraagjes. Ik heb een concept ontwikkeld wat ik hoop te kunnen verhuren aan meerdere mensen. Het is de bedoeling dat de hosting en domeinnaamregistratie daarbij inbegrepen is (hosting indien nodig). Dit lijkt me het makkelijkste omdat alles dan op dezelfde server staat.

De code van alle sites is exact gelijk, de unieke eigenschappen per site worden in een database opgeslagen. Wel bied ik twee versies aan, de ene is wat uitgebreider dan de ander, dit wordt geregeld via een rechtensysteem welke ik ga beheren.

Wat ik me nu dus afvraag is het volgende: is het mogelijk om de code op één plek neer te zetten en deze te laten gebruiken door meerdere sites? Of moet ik de code telkens kopiëren als er een nieuwe site bij komt?

En maak ik één database met de tabellen van alle klanten (met een prefix of zo), of maak ik per klant een database aan? Ik had het idee dat er sowieso één globale database moet zijn voor de rechten (de losse sites moeten hier bij kunnen om de rechten uit te lezen, dacht ik zo).

Ik ben erg benieuwd naar jullie antwoorden. En waarschuw me alsjeblieft als ik ergens een (grote) denkfout gemaakt heb in mijn opzet, adviezen worden zeer gewaardeerd!

Ow ja, wat ik vergeten ben: het zou leuk zijn, maar niet perse noodzakelijk, als de domeinen ook benaderbaar zijn via een subdomein van mijn domein (dus ander-domein.nl verwijst naar ander-domein.mijn-domein.nl, of andersom, maar wel zo dat er in de adresbalk het ingetypte domein blijft staan). Ik neem aan dat dat wel mogelijk is, toch?

p.s. mocht ik dit in een verkeerd (sub)forum posten, bij voorbaat mijn excuses.

[vne]

Je kan een symlink maken in de klant zijn public_html naar de map waarin al je PHP scripts zitten. Dit moet je dan wel manueel doen elke keer je een klant toevoegt, ofwel default template files van directadmin wisselen (echter nog niet getest of die ook probleemloos een symlink kan overnemen!).
Let wel goed op wat betreft de beveiliging. Als klanten op een of andere manier toegang hebben tot de public_html map, dan kunnen ze ook de inhoud van jouw files te weten komen. Met name het wachtwoord van je database connectie wil je niet zomaar laten rondslingeren niet?
Wat wij hier zelf aan gedaan hebben: we nemen 2 servers: 1 voor de hosting en 1 voor de mails. De klant krijgt enkel toegang tot de mailserver.
Mocht je niet over een 2e server beschikken, dan zou je eventueel je klant geen toegang kunnen geven tot directadmin, maar zelf een controlepaneel maken opdat de klanten toch nog hun eigen emails kunnen beheren. Dit moet je dan programmeren adhv de directadmin API.

Edit: Ik realiseer me net dat je nog niets vermeld had over je huidige infrastructuur. Je hebt hiervoor alleszins een eigen (virtuele) server nodig...

[Mark17]

Heeft elke klant een volwaardig controlpanel nodig met eigen login? En dan met name om bijv. email accounts of FTP accounts te beheren? Zo niet dan zou je het simpel kunnen houden bij een VPS of shared hosting account. Let op dat de domeinnaam limiet niet te laag is en je dataverkeer wat lastiger kunt meten.

In mij voorbeeld ga ik uit van 1 shared hosting account met de mogelijkheid 20 domeinnamen toe te voegen met DirectAdmin als controlpanel.

De websites kunnen 1 database gebruiken met een verschillende prefix (tip kijk bij PHP eens naar $_SERVER["SERVER_NAME"]). Een verschillende database is ook vrij makkelijk te realiseren in dit geval (mocht dat wenselijk zijn). Je zet dan de bestanden wel per keer online (of je werkt met symlinks) en verder kan alles telkens hetzelfde zijn. Zelfs met domainpointers is het zelfde te doen (maar dan geen losse email, dus email over andere server is het makkelijkste). Uiteraard kun je ook een hoster zoeken die mee wil werken aan dit concept en de configs handmatig iets aan wil passen voor jouw (of je een dedicated ip wil geven) zodat je enkel nog domeinnamen aan DirectAdmin toe hoeft te voegen als die eigen email adressen moeten hebben.

Met een VPS zonder controlpanel kan bovestaande ook heel makkelijk, de email laat je dan via een andere VPS of hosting pakket lopen (heb je het idee wat vne nu gebruikt)

Belangrijkste dingen om rekening mee te houden:
- Databases rechtstreeks benaderen van buiten af werkt niet altijd.
- Zoek een goede hoster en leg voor de tijd uit wat er gewenst is en kijk of ze mee willen werken om het makkelijk te maken voor jouw.
- Zodra je de hosting ook via hosters laat lopen waar jij het niet af neemt of verder weinig contact mee hebt kan het verstandig zijn de PHP bestanden te encoderen en dan is het handig om de database van die klant daar neer te zetten. Ten minste als je het commercieel aan wil bieden, anders is het encoderen niet nodig.
- Zoals vne al aangeeft moet je voorkomen dat je klanten het wachtwoord van de database kunnen zien en het kan zelfs verstandig zijn om te voorkomen dat de klanten de bestanden kunnen bekijken (zodat ze geen dingen aanpassen).

[systemdeveloper]

Het is ideaal om dit via een webservices af te handelen. Geen gezeur met dubbele (en encryptie of locatie van) code en databases. Performance is ook geen probleem als je het toch allemaal op de zelfde server(s) draait.

[RBeun]

Ow ja, wat ik vergeten ben: het zou leuk zijn, maar niet perse noodzakelijk, als de domeinen ook benaderbaar zijn via een subdomein van mijn domein (dus ander-domein.nl verwijst naar ander-domein.mijn-domein.nl, of andersom, maar wel zo dat er in de adresbalk het ingetypte domein blijft staan). Ik neem aan dat dat wel mogelijk is, toch?

Dit is mogelijk binnen PHP en een kleine aanpassing in je httpd config. Geen obstakel dus voor je. Je kan me altijd pmen voor stukje code, dan zoek ik het even voor je op.

[Triloxigen]

Ik zou voor iedere website een andere database nemen voor de performance en zodat ze minder afhankelijk van elkaar zijn. Bij een eventuele fout in de code kan ook dit problemen schelen.

Daarnaast bestanden delen via een symlink, zodat je wel bijvoorbeeld een directory voor alle bestanden in een eigen directory/hostingpakket kan zetten.

[Shakespeare2000]

Qua infrastructuur is er nu nog niets, heb alleen wel een idee waar ik de (voorlopig waarschijnlijk shared) hosting af ga nemen. Het is in ieder geval de bedoeling dat ik voor de klanten de hosting ga regelen (dus niet dat ik met meerdere hosters te maken heb). Zo hebben ze ook geen toegang tot FTP / broncode / databases, toch?

Het concept is ontwikkeld en draait nu gewoon lokaal. De klanten hoeven geen toegang te hebben tot een control panel, maar wat je voorstelt (controlepaneel danwel server puur voor de mail) klinkt erg interessant! Leuk voor later... maar het is nu (nog) niet van belang.

Van webservices heb ik (nog) niet al te veel kaas gegeten. Ik denk dat dit voor mijn concept ook een beetje overdreven is.

Ik zal binnenkort nog eens rondneuzen naar een goede hostingpartij die eens met me mee willen denken en wellicht ook nog wat ideeën kunnen leveren.

Ik heb ondertussen wat gezocht naar symlinks, dit lijkt me wel een goed idee, en ik denk dat ik ook voor meerdere databases ga (al is het al om het overzicht niet te verliezen met veel (dezelfde) tabellen in één database).

Wat betreft de symlinks en de plaatsing van de code heb ik nu het volgende idee. Op mijn hosting komt de code te staan. Zou ik dan per klant een symlink in mijn root kunnen maken naar de code en een subdomein van mijn eigen domein naar die symlink kunnen laten verwijzen? Als ik daarna nog het domein van de klant kan laten verwijzen naar dat subdomein (of rechtstreeks naar de symlink), is het helemaal naar m'n zin (denk ik). Of heb ik het nu verkeerd begrepen?

[Wynand]

Heb je zo'n gigantische berg aan php code dat het niet mogelijk is voor elke gebruiker dit apart neer te zetten, of maak ik nu de domme opmerking?

[Shakespeare2000]

Het is geen gigantische berg (paar MB, +/- 200 bestanden, wellicht nog wat in te dikken). Maar ik heb geen zin om een aanpassing om wat voor reden (bugfix, verbetering, uitbreiding) dan ook, op meerdere plaatsen door te moeten voeren.

[Wynand]

Dan vervang je die bestanden gewoon terug allemaal? Even terug uploaden is snel gebeurt... 200 php filetjes is echt niets hoor..

[The-BosS]

Heb je zo'n gigantische berg aan php code dat het niet mogelijk is voor elke gebruiker dit apart neer te zetten, of maak ik nu de domme opmerking?

Gaat niet enkel om de hoeveelheid aan php code maar om het aantal deployments dat je doet. Stel dat je dit 100 keer installeerd dan moet je dit ook telkens 100 keer updaten en onderhouden. Je kan het beetje vergelijken met installeer ik per project een framework en backend of zet ik dit ergens shared op de server of doe ik het via symlinks.

@TS: Je moet je project eens vergelijken met cms systemen die op zelfde manier werken, zo zijn er die ook apparte db per "klant" gebruiken en een apparte map (die via ftp enkel voor die klant toegankelijk is) per klant gebruiken voor images, docs, etc. Maar wel allemaal mooi dezelfde backend en framework gebruiken via dezelfde administratie. Of zo heb je ook systemen die vanuit de backend administratie bestanden genereren en deze dan via ftp uploaden naar persoonlijke accounts van de klant. Dan heb je ook een centrale backend maar een persoonlijk frontend per user.

[Shakespeare2000]

The-BosS, je begrijpt het helemaal! Mijn concept bestaat inderdaad uit een backend en frontend, waarbij de achterliggende code voor alle klanten uiteraard hetzelfde is. En voor (wat zou dat mooi zijn) 100 klanten, wil ik inderdaad het updaten niet 100 keer doen.

Ik zal 's kijken of ik deze week tijd kan vrijmaken om eens wat online op een (linux) servertje te gaan testen met symlinks, meerdere databases en klant-eigen data-mapjes.

[vne]

Let eveneens op met het uploaden van bestanden. Kwaadwillende klanten laden dan geen images op maar PHP bestanden. Ik moet er vast geen tekeningetje bij maken. Ik zou het uploaden van bestanden ook via een php-scriptje laten lopen zodat je controle hebt over elk bestand dat op je server komt.

[Shakespeare2000]

Let eveneens op met het uploaden van bestanden. Kwaadwillende klanten laden dan geen images op maar PHP bestanden. Ik moet er vast geen tekeningetje bij maken. Ik zou het uploaden van bestanden ook via een php-scriptje laten lopen zodat je controle hebt over elk bestand dat op je server komt.

Dat lijkt me toch aardig af te vangen door mimetypes te checken en de images te resizen tijdens de upload... Of waan ik me veiliger dan ik daadwerkelijk ben?

[vne]

Dat lijkt me toch aardig af te vangen door mimetypes te checken en de images te resizen tijdens de upload... Of waan ik me veiliger dan ik daadwerkelijk ben?

ik doelde er vooral op je klanten geen FTP toegang te geven...