Költözés lokálról webre

Anonymous képe

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.

Drupal verzió: 
aboros képe

egy darab kérdőjel sincs a "kérdésben".. :)
ahh, megvan:

A kérdés az, hogy visszafelé milyen problémát rejt az, hogy ha lokálra telepítjük eredetileg a rendszert.

semmilyet. próbáld ki és ha nem megy írd meg mit csináltál és mi a hibajelenség.

0
0

-
clear: both;

rendszereto képe

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.

0
0
aboros képe

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?

0
0

-
clear: both;

rendszereto képe

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?

0
0
aboros képe

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.

0
0

-
clear: both;

rendszereto képe

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.

0
0
pityu73 képe

Kezdőknek segítség!

http://nagygusztav.hu/drupal-6-alapismeretek.

Kész van az csak használni kell!

0
0
Balogh Zoltán képe

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.

0
0
rendszereto képe

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.

0
0
Balogh Zoltán képe

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.

0
0
aboros képe

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 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.. ;)

0
0

-
clear: both;

rendszereto képe

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.

0
0
szantog képe

Ezeket a táblákat nyugodtan ki lehet hagyni exportáláskor is.

0
0

----
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.

rendszereto képe

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...

0
0
Nagy Gusztáv képe

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.

0
0

Nagy Gusztáv

rendszereto képe

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

0
0
pp képe

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

0
0
silversk8r képe

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.

0
0
vacati képe

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:

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:1608428:\"MySQL server has gone away\nquery: UPDATE batch SET token = '605ad3b94e1426a7f3248329e07b5963', batch = 'a:10:{s:4:\\"sets\\";a:1:{i:0;a:11:{s:7:\\"sandbox\\";a:0:{}s:7:\\"results\\";a:0:{}s:7:\\"success\\";b:0;s:10:\\"operations\\";a:3:{i:0;a:2:{i:0;s:27:\\"_l10n_update_batch_download\\";i:1;a:1:{i:0;O:8:\\"stdClass\\":17:{s:4:\\"name\\";s:14:\\"backup_migrate\\";s:4:\\"info\\";a:10:{s:4:\\"name\\";s:18:\\"Backup and Migrate\\";s:11:\\ in C:\xampp\htdocs\...database.mysqli.inc on line 135

É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?

0
0
Balogh Zoltán képe

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.

0
0
vacati képe

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.

0
0