Gondoltam megosztom minden érdeklődővel tapasztalataimat a témában!
Eleve egy olyan CMS rendszert kerestem ami képes arra, hogy egy telepítéssel és több adatbázissal futtatható legyen több portál egy tárterületen, úgy, hogy ha az egyik oldalon regisztrálta magát valaki akkor ez a regisztráció érvényes legyen minden eddigi és jövőbeli részlegre (nevezzük így egy drupal egy konfigurációját saját tartalmával).
Szóval miután sikerült telepítenem a drupal-t a gyökérkönyvtárba, valamint az adatbázisba feltöltenem a database.mysql file-t, elérkezett a többi oldalnak a felvitele.
Ehez az alábbi lépéseket kellet elvégezni:
(végigmegyünk egy új oldal telepítésén, hogy egyszerű legyen a dolog)
Szeretnék egy www.domain.hu/alfa oldalt feltelepíteni aminek legyen:
- saját sminkje
- saját tartalma (adatbázis táblák)
- saját beálításai
Hogy ezt elérjed, kell egy új cím ugyebár. Ezt egy szimbólikus link segítségével kaphatod meg.
Gyökér URL: www.domain.hu
Új URL: www.domain.hu/alfa
Arról, hogy hogyan csinálhattsz ilyet UNIX alatt itt olvasshatsz bővebben.
Ha nincs UNIX shell hozzáférésed a szolgáltatódnál olvassd el ezt!
Ezek után szükséged lesz egy új configurációs állományra, ami leírja az új oldalat által használt:
- adatbázist
- adatbázis prefixumot
- bázis URL-t
- valamint a megosztott adatbázistáblák nevét
Másold le és nevezzd át az /includes/conf.php -t. Vigyázat! Az új név legyen: www.domain.hu.alfa.php.
Az elnevezés miértjéről itt olvasshatsz bővebben.
Ebbe az új config fileba írd át/add hozzá az alábbi sorokat
$db_prefix = array( "default" => "alfa", "users" => "", "sessions" => "", "role" => "", "authmap" => "" "sequences" => "" );
default = a nem megosztani kívánt táblák prefixuma
a többi a megosztani kívánt táblák prefixuma. Azaz ha az első durpal-t prefixum nélkül telepítettuk fel a mysql szerverre, akkor itt is NULL-t kell megadni a közös táblák prefixumára.
$base_url = "http://www.endomainem.hu/alfa";
Ezek után ha a www.domain.hu/alfa oldalra ellátogatsz akkor már működnie kell az új oldladnak. Egyből be kell tudond lépni az oldalra az első telepítésnél használt admin felhasználónévvel/jelszóval, mivel a users táblát megosztva használod.
Ezek után mehet a testreszabás, smik kiválasztás stb.
Mindenkinek sok szerencsét.
Hozzászólások
ötlet
Helló,
remek kis cikk, igazán hasznos téma, főleg akkor, ha pl. az ember portált fejlesztget megrendelőknek. Két dolgot tennék hozzá. Elsőként azt, hogy a drupal oldalán vázolt linuxos/unixos megoldás zavarosnak tűnik egy kicsit. Én mint Linux felhasználó, nem értem.. :) Erről majd még írok.
A másik pedig az, hogy nem tartom célszerűnek, hogy ha klónozunk egy drupalt, akkor a nem megosztott táblák újra létrejönnek egy új prefixummal. Tegyük fel, hogy száz megrendelőnek kell ezt megcsinálni, mennyi tábla lesz az adatbázisban?!
Nem lehetne egy "prefix" mezőt létrehozni a táblákban és akármennyi drupal portált kiszolgálhatna egy adatbázis (ezt már a fejlesztőknek lehetne javasolni.)
Táblákban?
Nem teljesen értem, hogy mire javasold a prefix mezőket a táblákban... Akkor meg sok oszlopa lenne egy táblának, ha jól értem. Táblákból csinálni többet még sokkal jobb, mint az adatmodeltt (oszlopokat) változtatni. Különben sokkal gyorsabban is kezelhető...
+1oszlop és sok sor.
Csak +1 oszlop lenne, a prefix, amiben sokféle érték szerepelhetne. ha pl. az egyik klón neve "yourdomain.com/joe" akkor a prefix : "joe". A drupal meg tudni fogja, hogy a táblákból csak azokat a sorokat kérdezze le az előbbi domainhez, melyben a prefix "joe".
Persze ehhez módosítani kell a lekérdezéseket :(
Teljesítmény
Egyrészt valóban módosítani kell a lekérdezéseket (drasztikusabban, mint ahogy most a táblanév helyettesítő teszi). Másrészt pedig nem győzöm ismételni, hogy a teljesítmény jelentősen romlana. Gondolj bele, hogy egy egyszerű SELECTnél az egyik webhelyen az összes telepített webhely adatait át kellene fésülni. Egy-két kisebb webhelyre biztos nem gondolod feltűnőnek a különbséget, de hamar jelentőssé válik. Olyan agyonhasznált tábláknál különösen, mint a statisztikák vagy a session.
jó rájt
Igen, ebben a teljesítmény dologban teljesen igazad van, erre nem gondoltam. Engem riaszt a túl sok tábla egy adatbázisban, ezért akadékoskodtam :)
Semmi okod rá
Semmi okod a sok tábla egy adatbázisban félelemre, sokkal jobb, ha külön táblákban (MySQL esetén fájlokban) vannak ezek az adatok. Az ideális persze (legalábbis szerintem), ha külön adatbázisokban foglalnak helyet.
-boogie-
-boogie-
Külön adatbázis
Ez sem gond, a tábla prefix erre is használható. Ha pont van a tábla prefixben, akkor az ugye a pont előtt az adatbázis nevét adja meg, utána meg a tábla prefixet az adatbázison belül. Ha nem kell táblaprefix az adatbázisban, akkor pontra kell végződtetni a karaktersorozatot. Nincs ebben semmi mágia, csak azt kell tudni, hogy a "{táblanév}" az SQL parancsokban kicseréldődik "prefixtáblanév"-re (idézőjel nélkül persze), és akkor ami a prefix, pontosan azt használja az SQL parancs. Például: "jozsi_táblanév" vagy "jozsi.táblanév" nem midegy, mert első esetben azonos adatbázisban tábla prefix, másodikban másik adabázisban, de nem prefixelt tábla.
Mindez a hókuszpókusz csak akkor kell, ha nem teszed minden táblád új adatbázisba, hanem több adatbázis között akarsz táblákat megosztani. Ha minden tábla új adatbázisba kerül, akkor simán a kapcsolati paramétereknél megváltoztatod az adatbázis nevét és kész.
Külön adatbázis
PostgreSQL használata esetén nem lehet kihasználni valahogy a sémák alapján végezhető csoportosítást?
lehet táblát megosztani
Mindegy, hogy milyen adatbázis motort használsz, a tábla megosztást a Drupal megoldja ugyanúgy (ha jól értem ez a kérdés).
... pont van a tábla prefixben ...
Nem az adatbázis motort miatt hoztam fel a PostgreSQL-t, hanem mert ezt olvastam az előző hozzászólásban:
"Ha pont van a tábla prefixben, akkor az ugye a pont előtt az adatbázis nevét adja meg, utána meg a tábla prefixet az adatbázison belül."
És mivel a PostgreSQL ismeri a séma fogalmát, ezért - szerintem - "a pont után" nem feltétlenül a tábla prefix van...
séma vagy nem, mindegy
Szerintem érdemes kipróbálni, ha már ennyire érdekel a kérdés. Én ugyan nem próbáltam, de mások használják ezt ilyen rendszerben, és működik.
Ráadásul..
Hozzátenném a Linuxos kifogásaimat is.. :)
Szerintem a http://drupal.org/node/275 címen írt "multiple directories" megvalósítása rossz. Pl. a http://yourdomain.com/~joe/ megvalósításához annyi kellene mindössze, hogy becsekkolunk a drupalunk főkönyvtárába és kiadjuk a köv. parancsokat:
$ ln -s . ~joe (~joe fake directoriba linkeli a drupal főkönyvtár tartalmát)
$mv joe/includes/conf.php joe/includes/yourdomain.com.~joe.php (átnevezi a conf.php-t)
és ezek után, ha tényleg azt szeretnénk, hogy a joe felhasználó módosíthassa a config állományát, akkor nem lágylinkkel kell azt a home könyvtárába linkelni, hanem keménylinkkel!
ln joe/includes/yourdomain.com.~joe.php /home/joe
Javítsatok ki, ha nincs igazam.
??
Mi mást mond az utasítás, nem ezt? Jó lenne, ha nem csak azt mondanád, hogy hibás, és aztán mondanál valamit, hanem azt mondanád, hogy miért hibás?
kákán a hurok
Egyrészt -szerintem- a leírt információ kevés ill. nem értem, hogy amikor a linkelésről beszél az elején, akkor miért az ls parancsot írja, másrészt a logikája szerint a joe/includes fake könyvtárban nemcsak a módosított nevű, hanem az eredeti conf.php másolata is ott csücsülne.
Harmadrészt, ha tényleg azt akarjuk, hogy a joe saját könyvtárában levő config állomány másolatot módosítani tudja, akkor semmiképpen sem lágylinkkel készítünk másolatot a fájlról.
Ezek mind apróságnak tűnnek, de a Linux alatt nincsenek apróságok :oD
megvalósítás vs. megfogalmazás
Szerintem csak nem tudott fogalmazni a szerző. Azt akarta lényegében mondani, amit te csináltál, csak nem tudta leírni :) A conf.php különben a te esetedben sem marad meg, pedig illik, mert ha valami olyan nevet kap a Drupal, amit nem tud feloldani, akkor a conf.php-t használja. Szóval emiatt hibás a példa, de éppen erre nem mutattál rá, csak az apróságokra (amikben viszont igazad lehet :).
Egyedi változók
Még egy fontos gyöngyszer, hogy a variables táblában tárol változók, mint a webhely neve, stb webhelyenként módosíthatóak konfigurációs állományból is, habár ez eddig nem volt szépen ledokumentálva – de működik. Az alábbi kódot küldte be nemrég egy bizonyos torne nevű felhasználó a Drupal.org-on erre a célra, melyet a conf.php-be kell helyezni:
#
# Variable overrides:
#
# To override specific entries in the VARIABLE table for this site,
# set them here. This is most useful when used in a configuration file
# for a vhost or directory, rather than the default conf.php. Any
# variable from the table can be given a new value.
$conf = array(
'site_name' => 'Overridden site name',
'theme_default' => 'alttheme',
'anonymous' => 'Other Anonymous Guy'
);
?>