Üdv!
Napok óta azon dolgozom, hogy feljebb lépjek és megismerjem a Composer, Drush használatát, hogy honlap építőből honlap fejlesztővé váljak mielőbb.
Néztem a drupal.org leírásait, a Google-ban kerestem, stb, de egyszerűen nem tiszta a dolog.
Most akkor a Composer-rel kell telepíteni a Drupal 10-et, vagy sem? Mert azzal csak az adott server mappába kerültek a telepítésre váró állományok, de onnantól kezdve a hagyományos, böngészőből indítható megoldás van csak, ráadásul mivel egy /web mappába kerülnek ezek a file-ok, a server tartomány beállításainál a public_html mappa helyett a public_html/web mappát kell beállítanom (nem tudom ez-e a jó megoldás, de működik).
Én azonban szeretném parancssorból telepíteni és van ahol azt írják, hogy Drush-sal lehet, de hogy hogyan, azt már nem.
Szóval akkor most a Composer, vagy a Drush telepíti magát a Drupal-t és mikor lehet megadni az adatbázis infókat, mert ugye anélkül nem fut le a telepítés.
Az is gond, hogy miután telepítettem a Composer-t, ha cPanleben keresem hol van, akkor nem úgy van mint Windows-ban, hogy meg tudom nézni milyen alkalmazások vannak telepítve, itt ott találtam Composer nevű file-okat, de nincs egy összefoglaló kép az egészről. Ennyire más a Linux, mint a Windows?
És akkor ott van az, hogy globálisan, vagy lokálisan települt-e, stb.
Nem kérem, hogy valaki itt leírja a válaszokat, csak annyit, hogy (lehetőleg magyar nyelvű) részletes leírást linkeljen nekem, ahol minden kérdésre választ tudok kapni.
Érteni akarom, amit csinálok, nem csak leírások alapján elvégezni.
Megoldás (?)
Ha jól értem, akkor nem a Composer, hanem a Drush telepíti a Drupalt, a Composer csak letölti a szükséges file-okat. Az tévesztett meg (joggal), hogy miután a Composerrel végrehajtottuk az alábbi parancsot
composer create-project drupal/recommended-project:10.3.5 "folder"és lefutott, azt írta ki a futás végén, hogy
tehát az "install" szót használja, ami telepítést szokott jelenteni.
de Composer-rel nem lehet telepíteni a Drupal-t, hanem előbb a Drush-t kell telepíteni a Composer-rel
composer require --dev drush/drushés majd a Drush segítségével lehet parancssorból telepíteni a Drupalt
drush site:installami valójában csak teljes könyvtár útvonal megadással működik:
./vendor/bin/drush site:installÉs lám, itt is az "install" szót használják, szóval ez, mint fent írtam eléggé megtévesztő...
Drupal és modul frissítéshez vagy csak Drush, vagy Böngésző
Üdv!
Valahol azt olvastam, hogy nem szabad keverni a frissítési módozatokat, azaz vagy csak Drush-sal, vagy a szokásos, Drupal grafikus felületéről elérhető megoldást (Állapotjelentés, modulfrissítés) kell használni, mert ha hol így, hol úgy, akkor a Drush nem fogja tudni követni a nem a Drush-ból indított frissítéseket.
Ez így van?
Ha így van, le lehet valahogy tiltani a grafikus felületről indítható frissítéseket, nehogy megszokásból az is használva legyen?
Gratu és üdv a klubban!
A Drush, ezzel a paranccsal:
$ drush site:install. Használhatod a parancs--helpkapcsolóját a leírásának elolvasásához vagy online itt találod. (Ezen az oldalon ne felejtsd el kiválasztani a Drush-od verzióját, előfordulhatnak eltérések a verziói között.)Vagy még futtatás előtt beleírod a
settings(.local).phpfájlodba (ekkor keress rá a$databasesváltozóra, hogy megtaláld a leírást benne, hogyan lehet), vagy pedig magának a Drush-parancsnak adod át őket bemenetként (erről pedig az előbbi--helpkapcsolóval olvashatsz).Ezt nem értem pontosan, mire gondolhatsz, de a Composer alfája és omegája a két fájlja a projekted gyökerében: a
composer.jsonés acomposer.lock. Ezek (szinte) minden információt tartalmaznak, amiből képet kaphatunk a projektünk összetételéről.Feltételezem, itt a Composer-re gondolhatsz. A projekted gyökerében állva egy
$ whereis composerparanccsal kilistázhatod az ilyen nevű futtatható binárisokat, amik fellelhetőek az oprendszered (Linux vagy macOS – Windowst nem tudom)$PATHváltozójában felsorolt könyvtárak valamelyikében. Nekem például egy ilyen eredményt ad:composer: /usr/local/bin/composer /var/www/html/vendor/bin/composer
Nálam ebből az első a globális, a második a projekt függőségeinek könyvtárába (
vendor/mappa) telepített, tehát a lokális. Ezeknek eltérő lehet a verziója és a beállításaik, ezért sokan ha tutira akarnak menni, szeretik fixen kiírni a projekt saját Composer-példányának az útvonalát, nehogy azon haljon el a szkript, hogy tévedésből a globális példányt keresi, ami viszont ritkán szokott telepítve lenni a szervereken.A
drupal/core-recommendedprojektsablon többek között igényel egy drupal/core-project-message nevű Composer-bővítményt is. Ez a kis kiegészítő annyit csinál, hogy kiolvassa a „szülő” projektsablon composer.json fájljából az ott megadott üzenetet és megformázva visszaszajkózza a telepítési folyamat egy bizonyos pontján a parancssorba. A hátteréről ebben a 2019-es ticketben olvashatsz, ez a kettő pedig még nyitott, de szintén ehhez kapcsolódik. Ha gondolod, az utóbbi alá odakommentelheted az észrevételed az „install” szó helytelen használatáról. Ha szeretnéd, szívesen segítek megfogalmazni.Így van, ahogy írod, annyi pontosítással, hogy itt nem a Drush-ról van szó, hanem a Composer-ről, hiszen a nyilvántartást a telepített komponensekről és azok verzióiról (és még sok másról) a Composer vezet, nem a Drush.
A kódbázis grafikus felületen keresztül való piszkálását szándékosan szorítjuk már háttérbe, már a 10.4-es alaprendszerből kikerült ez a régi örökség, a mögöttes érvekről is ugyanitt lehet olvasni. A letiltás ötlete jogos, ám életszerűtlen, hiszen általában 1–2 adminisztrátor végzi a webhely frissítését, ők pedig azért csak meg tudnak állapodni maguk között a mikéntjéről.
"Gratu és üdv a klubban!" válaszokra reagálások
Tehát a Composer tölti fel a tárhelyre a telepítendő Drupal file-okat, és Drush-sal lehet ténylegesen telepíteni.
Amikor telepítettem a Composer-t, nem rémlik, hogy a parancsban volt arra utaló rész, hogy globális, vagy lokális lesz-e a telepítés.
Erre van egy parancs, vagy attól függ, hogy a tárhely gyökerében állok-e a parancs kiadásakor, vagy pl. a public_html mappában?
.
Nagyjából igen, de nem csak Drupal fájlokat, hanem a sok más (a Drupal közösségtől teljesen független) fejlesztő munkájának eredményét, mint pl. a Symfony, a Behat, a Guzzle, stb., hogy csak pár ismertebbet említsünk. Ha belenézel a
vendor/könyvtáradba, abban minden egyes almappa neve egy ugyanolyan (de legalábbis hasonló) szoftverközösséget takar, mint a Drupalé. És látod, hogy rengeteg alkönyvtára van. A külső függőségek fogalmát ezért nagyon fontos megérteni, mert minden nyíltforráskódú szoftver támaszkodik többtucat vagy sokszáz másikra. Tehát a Composer kábé kisebb résznyi Drupal cuccot pakol és nagyobb részben másoktól érkező kódot. Ezért inkább úgy fogalmazunk, hogy „előkészíti a kódbázist”. De az adatbázishoz nem nyúl.Az adatbázisban a táblák létrehozása jelenti ugyanis a Drupal telepítését (most nagyon leegyszerűsítve) és ezt valóban – ahogy írod – már a Drush végzi.
Csak minimális. Egy példa jut eszembe: angoltól eltérő nyelven való telepítéskor a webes telepítő képes futásidőben beszerezni a fordítási fájlokat, viszont ha a
$ drush site:installparancsnak adod meg a--locale=huparamétert, akkor ő elvárja, hogy a nyelvi fájlok már előre oda legyenek készítve a kódbázisba.Lásd fentebb kifejtve.
Ennek pusztán az az oka, hogy a letölthető tar.gz és zip állományok már eleve tartalmaznak egy
vendor/könyvtárat, amibe viszont csak azok a csomagok és abban a verzióban vannak előre belepakolva, amire magának az alaprendszernek a futásához szüksége van. Onnantól kezdve, hogy utána hozzá szeretnél adni egy közösségi modult, ami tegyük fel ugyanazt a csomagot igényli külső függőségként, de egy másik verzióban (ez mindennapos eset), onnantól megáll a kézi tudományod: a vendor/keszitoneve/csomagneve névtér-struktúra miatt nem telepítheted fel mindkettőt párhuzamosan. Tehát (többek között) ezért (is) hasznos a Composer, mivel ilyenkor automatikusan megtalálja a közös nevezőt a két igény között.Csak nagyon ritkán használjuk a grafikus felületet, frissítések kezelésére pedig egyáltalán nem. A
$ composer outdatedparanccsal bármikor le tudod kérdezni, hogy miből van újabb verzió, amit fel tudsz telepíteni (mert hát ugye nem biztos, hogy mindig a legújabbat tudod mindenből telepíteni). Ha a rendszerednek csak a Drupallal kapcsolatos összetevőire vagy kíváncsi, akkor$ composer outdated 'drupal/*'.Ezután sokszor a
$ composer updateparancsot használjuk, azt különböző kapcsolókkal kiegészítve. Egy példa:$ composer update 'drupal/*' --with-all-dependenciescsak a Drupallal kapcsolatos összetevők és azoknak a függőségeinek a lehetséges legújabb verziójára való frissítést végzi.Ha a
composer.jsonés.lockfájljaid rendben vannak, akkor bármikor nyugodt szívvel törölheted avendor/könyvtáradat, valamint Drupalon belül acore/,modules/themes/ésprofiles/könyvtáraidat, mert egy $ composer install parancs újra létre fogja őket hozni, de már csak olyan cuccokat belepakolva, amik szerepelnek a Composer nyilvántartásában. Ma már egyre ritkábban futni bele olyan sminkbe vagy modulba a Drupal.org-on, aminek még nincs saját composer.json fájlja, de ha mégis ilyet szeretnél telepíteni, akkor arról mindenképp nyiss egy ticketet, jelöld meg „novice” címkével.Elhiszem, hogy most most még szokatlan, de ez nem lesz mindig így. Ahogy a kreatívügynökségek grafikusai sem a Windows-zal együtt szállított Paint-tel készítik a reklámokat, úgy neked sem szükséges az oprendszereddel együtt szállított gyári terminálprogramot használnod. Próbálj ki minél többet, találd meg a számodra legszimpatikusabbat, ne sajnáld az időt a testreszabásával elbíbelődni, a lényeg, hogy kényelmesen és megbízhatóan tudj benne dolgozni.
Mutatsz linket kérlek?
CLI kényelmetlensége
PuTTY elterjedt és a tárhelyszolgáltató is azt ajánlja, szóval...
https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-8-or-...
Nos igen, így listába
Nos igen, így listába összegyűjtve valóban sok lépésnek, ezáltal hosszúnak tűnik a folyamat. Én most délután húztam fel az egyik helyi környezetemet D10-ről D11-re és járt némi új tanulsággal (saját hülyeségemből okoztam, teszem hozzá :)
De nézzük a jobbik oldalát, legalább van egy jól összeszedett dokumentáció a folyamatról :)
Üdv!
Üdv!
Az eddigi Composer-es feltöltések sikeresek voltak, most azonban nem, viszont ha ugyanezt a webes felületről telepítettem, akkor sikeres lett.
Mi itt a probléma?
composer require 'drupal/tr_rulez:^2.0'Your requirements could not be resolved to an installable set of packages.Installation failed, reverting ./composer.json and ./composer.lock to their original content.Rules helyett ECA?
Ezt megkérdezheted magától a Composertől is, hogy szerinte miért nem jó egy csomag adott verziója a projektedhez :)
$ composer why-not drupal/tr_rulez 2.0A válasza azonban nem mindig segít jobban megérteni, ilyenkor megpróbálhatod az általa az üzenet végén javasolt
--with-all-dependencieskapcsolóval:$ composer require 'drupal/tr_rulez:^2.0' -W(ez a rövidítése)A
tr_rulezkódjából ugyanis az látszik, hogy legalább 4.0-s (vagy újabb) kiadás szükséges számára arulescsomagból.Egyébként javaslom, kezdj el lassan ismerkedni az ECA modulcsaláddal, mert egyelőre annak tűnik ígéretesebbnek a jövője.
Eleve 4-es Rules van fent,
Eleve 4-es Rules van fent, mivel az van 10-eshez.
A kérdésem igazából arra irányult - mivel láttam a Composer válaszát magam is, nem venném el itt mások idejét olyannal, amire találok választ máshol - hogy miért sikeres a telepítés a webes felületről, tehát az megoldotta ezt a problémát, vagy figyelmen kívül hagyta, tehát nem tökéletes telepítést engedett? Mert nem volt hibaüzenet és most sincs a Jelentések részen.
Természetesen a Composer-es megoldásokat fogom használni a kényelmes és adott webes lehetőségek helyett... (no comment), csak az azért érdekelne, hogy most akkor a Webes felületen lévő Bővítés felület sz-rt sem ér, mert nem jelzi a hibát ezek szerint és nem teszi fel a függőségeket? De ha így van, akkor minek a Bővítés felület? Akkor el kell venni és meg kell mondani, hogy gyerekek, aki Drupal-t akar használni, az használja a parancssort, mert ez így olyan, hogy ott van, de ne használd...
És vajon, ha az a cél, hogy a Drupal közelebb kerüljön a WP népszerűségéhez, akkor jó irány-e, hogy a parancsorra akarja vinni a felhasználókat alap dolgokban is, ha hibátlan megoldást akarnak, mert technikailag nyilván megoldható lenne, hogy a webes felület is egy Composer parancsot futtasson le (igen, ahhoz parancssoros hozzáférés kell, de nem root, és mivel https-es (SSL) a Drupal honlap is jó esetben, a biztonsági része nem különbözik a terminálos SSL-es hozzáférés biztonságától). Elvileg.
Ui. Elkezdtem már korábban ismerkedni az ajánlott Rules alternatívával (de még csak 4 ezren használják, szemben a Rules 116 ezrével), de amikor megláttam, hogy a Rules-ból megjelent végleges verzió 10-esre is, megörültem, aztán láttam, hogy ott elfelejtettek szólni a modul oldalán, hogy pl. nincs benne a Scheduler, stb.
Ui: A Drupal.hu meghalt, hogy szinte halott a fórum?
.
Nagy valószínűséggel igen. Biztosan azért nem lehet kijelenteni általánosságban, mert előfordulhat olyan eset, amikor a feltelepített smink vagy modul olyan egyszerű felépítésű, hogy nem igényel külső függőségeket (vagy a fejlesztője belemásolta a külső függőséget a modul kódjába, ami a forkolásnak egy nagyon-nagyon rossz gyakorlata, de sajnos nem példa nélküli).
Még egyszer: lehet, hogy valakinek bizonyos esetekben még éppen nem okoz gondot és el tud vele ketyegni probléma nélkül. De tény, hogy már nem garantál olyan megbízható működést, mint annó a Composer előtti (D6/7) időkben.
Nagyon jól látod, rátapintottál a lényegre. Pontosan ezt tesszük immár évek óta: készítünk fel mindent és mindenkit az automatizált függőségkezelésre való átállásra. Ez azonban egy lassú folyamat mert számos szervezetnél rengeteg ember összehangolt munkája, széleskörű kommunikáció és a Drupal․org működésében is fejlesztések szükségesek hozzá. Mostanság érkezünk el ennek az átállási folyamatnak az egyik utolsó, talán leglátványosabb lépéséhez, amikor „elvesszük” (ahogy fogalmazol) az emberektől ezt a menüpontot: fentebb linkeltem is change record-ot.
Már ez is évek óta folyamatban van: a félautomatizált frissítési mechanizmusról már itt is hírt adtunk a Drupal․hu-n, bővebben pedig itt olvashatsz róla vagy feliratkozhatsz a kezdeményezéssel kapcsolatos friss fejleményekre.
Drupal bővítmények megítélésekor nem az egyetlen szempont a telepítések száma. Figyelembe kell venni a karbantartói aktivitást, az issue queue-ban feltorlódott ügyek mennyiségét, súlyosságát, vagy a felépítésének a korszerűségét, forráskódjának minőségét, mennyire könnyű bővíteni. Természetesen garancia nincs rá, hogy így sem nyúl mellé az ember, de érdemes minél több modult feltelepíteni, kipróbálni, aztán letörölni, ha esetleg mégsem válik be, mert egy széleskörű tájékozottsággal sok idő megspórolható.
Minden jel arra utal. Négyen-öten járogatunk már csak ide. Legutolsó infóim alapján állítólag Slack-en nagyobb az élet, nem tudom.
vagy a fejlesztője
Egy végleges verziójú modul esetén előfordulhat ilyen? Tehát a Drupal.org-ról letölthető, biztonságosnak, ellenőrzöttnek mutatott modul esetében lehet olyan, ahol nem a Drupal elvárásainak megfelelően kialakított modul kerül közlésre? Ha igen, akkor minek a zöld háttérszín, a pajzs, azaz az ellenőrzöttség, megfelelőség jelölése a modulok oldalán?
Talán tavaly, amikor itt szó volt arról, hogy ez a fórum már nem megy, meg a Drupal.hu, akkor felmentem a Slack-ra, de nem igazán sikerült átlátnom azt a felületet és amit ott írtam, arra azóta sem érkezett válasz, aztán, ha jól rémlik te írtál itt úgy fél éve, hogy ismét beindul ez a fórum, de úgy tűnik mégse. Lehet, mindenki megtanult angolul és a Drupal.org fórumain beszélget. Vagy, annyira lecsökkent a Drupal népszerűsége, hogy ez a magyar fórumon ennyire látszik.
Próbáltam a WP-t, de egyrészt azt olvastam róla, hogy pl. csoportkezelésre, jogosultságkezelésre, sok felhasználós honlapra nem igazán jó és a felülete is idegen, bár sok szempontból kényelmesebb (pl. modul keresés a honlapról elérhető, nem kell mint itt a Drupal.org-ra rámenni), de valamiért - ez lehet tévedés - olyan érzésem van, mintha a WP gagyi lenne a Drupal.hoz képest. Sajnos a Drupal viszont a nagyképű programozók terepe, úgy látom itt sok régi hozzászóló esetében.
„[…] előfordulhat ilyen?”
Sajnos ma már igen, nem árt óvatosnak lenni, és mint írtam korábban, sok más szempontot is mérlegelni. Sokszor kollégákkal egyeztetünk magunk között egy-egy döntés előtt ki-mit ismer vagy ajánl egy adott feladatra, de a DUG-eseményeken is rendszeresek a modulbemutatók, amikor különböző kontrib modulokat beszélünk ki.
De ez nem volt mindig így, ha jól emléxem, körülbelül valamikor 2015 tavaszán szűnt meg a kötelező peer-review-zási követelmény, azóta bárki bármikor közzétehet stabil kiadását a bővítményének.
És igen, némi angol nyelvtudással (nem kell perfektül beszélés, elég ha csak az ingyenes DeepL + Grammarly párossal felturbózod magad) sokkal mélyebben be lehet vonódni az amúgy egyébként elég pezsgő nemzetközi Drupal-pörgésbe.
Megnéztem a hivatkozott
Megnéztem a hivatkozott témákat amiket küldtél itt és meglepő - nem akarom magam fényezni, tényleg - hogy alig egy hete használom a D10 és Composer párost és máris felvetődött bennem, hogy ugyan miért nem eleve ezt a módszert használja a webes frissítési felület. Gondolom már sok éve felmerült ez, csak még nem valósult meg, nem gondolom, hogy csak most jutott eszébe másoknak.
Amit a modulok megbízhatóságáról írsz az viszont megdöbbentett, tehát akkor semmi értelme a megbízható modul jelölésnek.
Azt gondoltam, hogy a folyamat vagy úgy megy, hogy valaki beküld egy modult és egy csapat végignézi a kódot, majd utána kerül oda a zöld szín és a pajzs, vagy hogy annyira megszabott a modulok fejlesztésének mikéntje, hogy eleve van egy keretrendszer, ami nem is engedi, hogy problémák legyen, vagy egy program átvizsgálja a kódot.
Ezek után nehéz azt gondolnom, hogy a Drupal a legprofibb CMS és már azt is értem, miért van annyi utólag kiderült biztonsági rés a világ összes webes és egyéb alkalmazásában...
Remélem nem a mesterséges intelligenciának nevezett szarságra fogják rábízni ezeket a feladatokat, mert abban még annyira sem lehet bízni, mint az emberekben.
UI. Van egy elképzelésem, hogyan lehetne felvirágoztatni a Drupal.hu oldalt, vagy akár egy másikat csinálni, úgy, hogy az anyagilag is megérje. Ha érdekel, valamikor megírom és akár összehozhatnánk...
Úgy érzem, nekem kissé
Úgy érzem, nekem kissé végletesnek tűnik a „vagy tutizicheratombiztos, vagy gagyi az egész” megközelítés. A kettő között rengeteg köztes fokozata van a skálának és ezen a skálán a Drupal összességében, mint ökoszisztéma valóban előkelő helyet vívott ki magának az évtizedek alatt, joggal.
Először is külön kell nézni a Core és a Contrib kettősségét. Előbbit valóban vasmarokkal fogják közre és árgus szemekkel figyelik – részben átvitt értelemben, de tény, hogy automatizált eszközökkel és rengeteg élőemberi munkaóra-ráfordítással ügyelnek a biztonságára (lásd: Katedrális és bazár elmélet – érteni fogod, a Drupal Core melyik a kettő közül).
Utóbbival – amiről itt most ebben a fórumtémában szó van – valóban más a helyzet. Bár a best practices (pl. egy modul architekturális felépítése), a coding standard (a forráskód „kinézete”), a grafikus felhasználói felületen követendő megszokások, a megjelenő szövegek, üzenetek megfogalmazási stílusa, a tesztlefedettség elvárt mértéke, és ezeken kívül még számos más szempont nyilvánosan közzétett szabályokban rögzített, amelyek hosszú évek alatt alig változtak, jól beégtek már mindenki rutinjába. Így egy gyakorlott fejlesztő a tapasztalatából adódóan jó eséllyel meg tudja tippelni egy véletlenszerűen a szeme elé kerülő Drupal-modulról annak érettségét, minőségét, megbízhatóságát, esetleg hosszú távon való fenntarthatóságát, stb. Az informatikában általánosságban ezt szokás „code smell”-nek is nevezni, amit magyarra talán „mennyire bűzlik a kód”-ként lenne lefordítható.
És akkor még nem is említettem a Drupal Security Team-et, akik viszont valóban aktívan vizsgálják az arra önként jelentkező modulok friss kiadásait. Az egyik általam is karbantartott modul kapcsán nemrég nekem is volt szerencsém részt vennem egy foltozási folyamatban, így belátnom a kulisszáik mögé. Engem is meglepett az a profi összehangoltság, ahogy a biztonsági kiadás közzétételét előkészítik és órára-percre pontosan szinkronizáltan levezénylik, hogy ki-mikor-mit csinál majd a kiadás napján – pedig „csak” 13/25-ös súlyosságú rés volt.
Összefoglalva: nem kell sem túlbecsülni, sem félni a modulok projektoldalán látottaktól, GitLab-on ma már nagyon kényelmes belekattintgatni kicsit a forrásába, vagy letölteni (Composer-rel már te is kezded érezni, milyen egyszerű tud is ez lenni), egy helyi Drupal-példányon feltelepíteni (Drush-sal szintén pár másodperc), kattintgatni kicsit, próbálgatni, játszani vele. Ha eddig nem hasalt el vagy dőlt össze a modul (vannak ugyanis olyanok), akkor utána rá lehet keresni (pl. vagy a magyar, vagy a nemzetközi Drupal Slack-en), mások miket írnak róla, megkérdezni ismerősöket, vagy bejelentkezni egy DUG videóközvetítésére és körbekérdezni a többieket, ismerik-e, próbálták-e már, tudják-e javasolni, vagy alternatívát helyette, ilyesmi.
Composer: király
Éveken keresztül a hagyományos módon frissítettem a Drupal-t és a modulokat, a Drupal frissítése körülményes és hibalehetőséggel teli kézi módszerrel (file-ok törlése, újak feltöltése, közben figyelni nehogy olyat is töröljünk, ami kell, vagy maradjon, ami nem kell, vannak egyedi file-ok, amiket volt, hogy frissíteni kellett, pl. a settings.php stb), ráadásul ez FTP-n keresztül hosszadalmas volt a sok file miatt, fél óra is akár, most meg 1 perc sincs, csak ennyi:
És egyszerre minden frissítve van.
Igaz a htaccess file-t mindig felülírja, de az a legkevesebb...