A webről saját gépre, pl. XAMPP webszerverre történő költöztetés minden probléma nélkül való, ahogy ezt a http://drupal.hu/forum/k%C3%B6lt%C3%B6ztet%C3%A9s téma végén ecseteltük és kipróbáltuk.
A kérdés az, hogy visszafelé milyen problémát rejt az, hogy ha lokálra telepítjük eredetileg a rendszert. Akkor pl. a file rendszer útvonalainál backslash karakterek vannak slash-ek helyett.
Elég-e ezt a két mappát átírni ennek megfelelően, vagy ha pl. nem nyilvános rendszert használtunk és már töltöttünk fel file-okat, akkor azok működni fognak-e a költözés során, vagy mindent újból fel kell tölteni.
Most a lokálon dolgozom a webről letöltött drupal rendszerrel. Dolgozom rajta egy ideig, építgetem, majd felteszem a webre és meglátom, mi lesz és leírom majd.
Akinek van már ilyen tapasztalata, az ne tartsa magában :-)
Amit már most gyanús: mivel Windowson nincsenek olyan file és mappa jogosultságok (777, stb) mint Unixon, valószínűleg ezeket is be kell majd állítani. Az viszont elég nehéz lenne, ha ezt egyenként kellene megtenni, ráadásul úgy, hogy nem is tudom melyik mappának, file-nak mi a javasolt jogosultsági szintje, kivéve azt a néhányat, ami szem előtt van (settings.php, stb.)
Rákeresek majd egy listára a drupal.org-on, hátha le van írva valahol a jogosultsági elvrendszer, de ha meg is találom, akkor is kellene egy automatizmus, hogy az 508 filet és 93 mappát egyszerre be lehessen aszerint állítani.
mi a kérdés?!
egy darab kérdőjel sincs a "kérdésben".. :)
ahh, megvan:
semmilyet. próbáld ki és ha nem megy írd meg mit csináltál és mi a hibajelenség.
-
clear: both;
Eddig
Eddig annyi probléma lett csak, hogy a filerendszernél a perjeleket meg kellett változtatni. A Privát mód tesztelése nagyobb feladat, de nyomom hamarosan.
az van,
hogy egy költözés után a filerendszer beállításokat ellenőrizni kell és az új hostnak megfelelő beállításokat kell eszközölni. ennyi. de ez magától értetődő szerintem. ha más az adatbázis elérés azt is változtatni kell, ha más mondjuk a memcache beállítások, azt is változtatni kell.... stb...
új környezetbe helyezed a gyereket, úgyhogy értelem szerűen minden környezeti változót ellenőrizni kell és a szükséges értékre állítani. bármi meglepő vagy szokatlan van ebben?
-
clear: both;
memcache
A memcache-re nem gondoltam, mivel semmi dolgom nem volt még annak állításával. Nem is értem mire gondolsz. Talán arra, hogy mennyi a PHP-ban az engedélyezett memória limit?
Ha erre, akkor az van, amit kapok a tárhelyen, azon mit állítanék?
tárhelye válogatja
bizonyos osztott tárhelyek (a jobbak) is engedik, hogy egyes környezeti változókat (pl php memory_limit) te állíthass egy saját php.ini -ben vagy settings.php -ban ini_set -el. (bár nem tudom mért kéne ezt másra állítanod itt vagy ott)
a memcache más történet, de mondjuk ha van, akkor lehetséges, hogy a localodban más ipn/porton figyelnek az instancek, mint az élesben. ahogy van még pár egyéb dolog is, amik egy összetettebb rendszerben, esetleg dedikált vas esetén eltérnek a localod meg az éles között, de ez a speciális eset.
általában én úgy szoktam, hogy próbálom a local környezetet a lehető leginkább az élesnek megfelelőre szabni.
-
clear: both;
Te úgy szoktad
Jó neked, én kezdő lévén annyit tehetek, hogy felteszem a XAMPP-ot és csinálom a honlapot, bízva a lehető legjobb beállításokban, mivel az ezzel kapcsolatos ismereteim még nem teszik lehetővé, hogy bármit is felülbíráljak.
Mivel szerintem jó út, hogy saját gépen csináljunk egy kész rendszert és utána töltsük fel, ez a téma szerintem fontos és érdekes, remélem sokan csatlakoznak tapasztalataikkal, hogy a végén összesíteni lehessen egy általános eljárás menetet, ami a kezdők számára is megfelelő segítséget nyújt ezen feladat véghezviteléhez.
Kezdőknek segítség!
Kezdőknek segítség!
http://nagygusztav.hu/drupal-6-alapismeretek.
Kész van az csak használni kell!
A kérdésedre azért nem lehet
A kérdésedre azért nem lehet átfogó választ adni, mert bárhonnan költözöl bárhova, mindig utána kell húzni a rendszert. Nem csak localhostról van szó, hanem A tárhelyről B tárhelyre költözés is számos meglepetést tartalmazhat. Aboros is írt egy párat, de lehet gond az uploadprogress-től kezdve az APC-n át mindennel. Tehát úgy költözünk, hogy felteszzük a fájlokat és az adatbázist, a settings.php-t, fájlrendszert utánnahúzzuk, és megtekintjük a honlapot (költözésnél alap, hogy Garland smink, cleen url ki, session, cache törlés). Aztán mézzük az állapot jelentés oldalt, az ott lévő sárgákat és pirosakat elhárítjuk (vagy esetleg innen is tovább költözünk). Ezt követően nézzük az adatbázisnaplót (mert a hibaüzeneteket ugye nem írjuk ki a weblapra), és ha semmi extra dolog nincs, akkor sikeresen átköltöztünk.
cleen url ki, session
Ezt a kettőt nem tudom mi: cleen url ki, session.
A többi világos.
Erre a kettőre pedig rákerestem, hogy ne kérdezzem amit megtalálhatok a fórumban:
APC (Alternative Php Cache) és
Upload Progress.
Az előbbit nem tudom hol lehet törölni, az utóbbi pedig, ha jól néztem utána az a progress bar, ami mutatja a feltöltések mértékét, tehát arra célzol, hogy azzal lehet gond. Szerencsére ilyesmit nem használok.
A lényeg tehát az, hogy ha a piros és sárga figyelmeztetéseket már el tudjuk kerülni és a logban sem látunk semmi bajt, akkor rendben van minden.
Az utóbbi (log) esetében viszont lehet olyan eset is, hogy 1 évig nincs baj, aztán mégis, mert éppen 1 évig nem csináltuk azt a művelet, ami a hibát előidézhette volna.
Ha így nézzük, akkor viszont sosem lehetünk biztosak egy költözés sikerességében.
Az APC rossz példa volt, mert
Az APC rossz példa volt, mert az vagy van, vagy nincs, állítani nem sokat kell rajta. Az upload progress feltöltési folyamatjelző, filefield és társai hiányolhatják. A rövid webcímeket költözéskor célszerű kikapcsolni, a session táblát - aktuális munkamenetek - meg hót felesleges költözéskor magaddal vinned, tehát kizúz.
Ha gond van valamivel, az hamar kiderül az adatbázis naplóból, ha a hibákra szűröd. Én még nem láttam olyat, hogy csak 1 év múlva látogatok el a honlapom rejtett zugába, mert akkor ellátogat helyettem a cron, a Google, vagy akár egy másik user.
ezért nem életképes egy ilyen téma
az esetek 95% -ában elmondhatjuk, hogy ha minden zöld, akkor valószínűleg minden működik.
ha valami piros, szinte szuperbiztos, hogy valami nem működik.
viszont általános szemléletbeli kérdés, hogy:
a valószínűleg gyakran nem elégséges. minden további viszont már munkamódszer kérdése. ha valamit A helyről B helyre költöztetek, akkor vagyok biztos, ha kipróbálok mindent. néha még akkor se :)
valószínűleg, ha olyan gond van, amire nem derülne fény a status reportból, akkor már el se jutsz a status reportig.
amúgy meg nézed az error logot szorgalmasan, ha hibát látsz, rávetődsz.
vagy nem, hozzáállás kérdése. :)
szóval azért nem életképes, mert hol a konkrét probléma amit meg kell oldani?
mi a hibajelenség? mi a környezet? mi a hibaüzenet?
elbeszélgethetjük itt bitek csrilliárdjait, sose lesz vége. a megoldásra vagyok kiéhezve nem a locsi-fecsi.. ;)
-
clear: both;
Van akinek életképes
Az irány mindegy (lokál > web, vagy fordítva), az eseménynaplót figyelve rengeteg hibaüzenet jött. Sajnos menüből nem lehet a korábbi eseménynaplókat törölni, kerestem a fórumokon, hol lehet manuálisan teljesen tisztítani, de nem találtam, aztán sikerült más témából kikövetkeztetnem (rajtam kívül még vannak kezdők, akikben ez a kérdés biztos felmerült), hogy hol van az az adatbázisban.
A lényeg: a legtöbb hibaüzenet abból adódott, hogy bizonyos ideiglenes fileok még a rendszerben voltak, ezért töröltem az alábbi táblákat (nem eldobtam, hanem töröltem):
- cache (az összes ilyen névvel kezdődőt)
- watchdog
- sessions
Így lenullázódott az eseménynapló (ez fontos, hogy ne legyen egy csomó olyan hibabejegyzés benne, aminek a kiváltó okát már orvosoltuk - szűrés ide, vagy oda) és újabb hibaüzenetek sem jönnek már az ideiglenes file-ok törlésének köszönhetően.
Ezeket a táblákat nyugodtan
Ezeket a táblákat nyugodtan ki lehet hagyni exportáláskor is.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
Jó ötlet
Kösz, ez tetszik és így az adatbázis is kisebb lesz.
Majd ha tudok programozni php-ban (és esetleg nincs ilyen modul), akkor csinálok egy olyat, ami a költözéskor automatikusan megcsinálja, amit meg lehet csinálni.
Egyébként lehetne egy gomb az eseménynapló ablakában, amivel ki lehetne törölni a bejegyzéseket a phpmyadmin felkeresése nélkül...
Van ilyen modul. Én a Backup
Van ilyen modul. Én a Backup and migrate modul alapbeállításával (+ ZIP tömörítés) szoktam mentést csinálni, és azt importálni.
Nagy Gusztáv
Az jó
Akkor már csak azt kell majd beprogramoznom, hogy az eseménynaplónál legyen egy törlés gomb, akár szűrve is...
SFVUV
nem kell ahhoz költözni!
Elég, ha Te updateled a Drupalodat, vagy valamelyik modult. Lehet, szolgáltató állít át valamit alattad, és lehet nem állít át semmit, de egyszer csak megjelenik egy olyan hiba amire gondolni se tudtál volna. (mint ahogyan most mi sem.)
Tipikusan bizonyos html bemenetet eleve a webszerver fog visszautasítani és a php-ig sőt a Drupalig el se jut majd. Ez védi azokat a fogalom nélkülieket akik úgyse visznek be htmlt, tehát ha rosszul állítottak be valamit akkor gonosz emberkék se tudnak bevinni a fogalomnélküli oldalán. Szóval minden tök jó és kerek amíg egyszer csak valaki nem akar html-t bevinni. (html értsd: speciális szabályok amik tipikus támadások szoktak lenni, tehát nem a kacsacsőrnél akad ki a rendszer, hanem összetettebb adathalmaznál)
Szóval itt még teszten se jön ki és mi innen távolról meg nem mondjuk az ottani rendszergazdád milyen spec beállításokat és szabályokat tett be a rendszerébe, hogy maximálisan kiszolgálja az igényeidet.
Ne felejtsd:
A weboldalad olyan mint egy telek. Ha nem gondozod felveti a gaz és a szomszédok odahordják a szemetet.
Szóval egy fél év múlva már csak mosolyogni fogsz azon, hogy az addigi melódhoz képest milyen viccesen egyszerű és kis dolog volt ez a költözés.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
a legtutibb ugyanazon a
a legtutibb ugyanazon a szerveren dolgozni ahol majd a végtermék futni fog. pl egy fejlesztői subdomain vagy alkönyvtár ha más nincs.
Backup and Migrate hibaüzenet a modul bekapcsolásakor
Kipróbáltam a Backup modult, és ha jól látom annyit csinál, mint amit eddig én manuálisan: kitörli a cache, session és watchdog táblák tartalmát és elmenti az adatbázist, majd visszaállítja, ha akarom.
Ha viszont új helyre költözöm, akkor így is úgy is át kell majd állítani a settings.php-ban azt a pár adatot, ami az adatbázisra vonatkozik. Nemde?
Viszont amikor először bekapcsoltam ezt a modult, akkor egy egész oldalas szöveges hibaüzenetféle jelent meg, mint amikor elveszti egy weboldal a formázását és úgy jelenik meg egy szöveg.
Csináltam egy Backspacet, ismét a modul bekapcsolására kattintottam, mentés és már nem volt hibaüzenet.
Tehát a semmitől megjavult. Ezt XAMPP-os saját gépen próbáltam. (Drupal 6.20)
Hogy lehet, hogy hibát jelez, aztán meg nem, ha közben semmi sem változott a rendszerben?
Az egyik hibasort beidézem:
És van olyan kiegészítő - mert ennek lenne igazán értelme - hogy a weboldal teljes tartalmát is lementse, időközönként, vagy arra marad a cPaneles megoldás?
Webes környezetben elég
Webes környezetben elég érdekes az a megfogalmazás, hogy a semmitől megjavult. Inkább úgy mondanám, el sem romlott. Biztos Neked is jöttek már be hírportálok css nélkül, vagy dobtak egy 500 Internal Server Error-t. Aztán F5, és lőn, látszólag megjavítottunk egy komplett hírportált távolról, a semmi segítségével.
A hibasorra rákeresve ("Warning: MySQL server has gone away query: INSERT INTO watchdog") kb. 5 másodperc alatt fellelhető, hogy ez miért van, és mi lehet a gond.
A kiegészítő pedig úgy lelhető fel könnyen, hogy elolvassuk a Backup and Migrate modul projektoldalát, amin szerepel valami Backup and Migrate Files nevezetű kiegészítő modul.
De nem weben, írtam, hogy
De nem weben, írtam, hogy saját gépen, XAMPP-pal történt.
Egyébként tényleg volt már olyan, amit írtál, mindig meg is ijedek :-)
Lefordíttattam a googleval a hibaüzenet szöveges részét, de nem mondott semmit, mivel semmi közöm még a programozáshoz. Ezért is kérdeztem meg.
Tehát a környezet nem változott, sőt, visszaállítottam hagyományos módon az adatbázist és újból eljátszottam a modul bekapcsolását és megint elsőre ezeket dobta ki, ami a fetn vázolt megoldással elmúlt.
Ami a modul leírását illeti: nem igazán tudom hogy a drupal.org letöltési részénél lévő infóra gondolsz, vagy a modullal adott leírásra?
Mert időnként egy-egy modulnál egyik sem túl informatív. És mivel már úgy is kérdeztem most, gondoltam nem lesz belőle "baj", ha egy igen/nem válaszért még hozzáfűzöm ezt a kérdést, hátha van egy javaslat kitapasztalt modulból.