Commit ed4fcbee authored by Balu Ertl's avatar Balu Ertl

Issue #3090301 by Balu Ertl: [HU] Remove unnecessary prompt signs before commands

parent fe7ea1cc
......@@ -35,7 +35,7 @@ Ezeket a lépéseket csak egyszer kell elvégezni, miután létrehoztuk tároló
. Nyissunk meg egy parancssoros ablakot és navigáljunk el abba a könyvtárba, ahol a webhelyünk szoftverének forráskódja található.
. Mivel a Drupal eltérő könyvtárszerkezetekkel, több féle módon is telepíthető, verziókövetni pedig általában a gyökérkönyvtártól (angolul „docroot”) lefelé érdemes, ezért meg kell állapítanunk, hogy nekünk a gyökérkönyvtárunk hol található. Ha parancssorban egy `$ ls` parancsot kiadva látjuk a _core_, _modules_ és _themes_ könyvtárakat, akkor már meg is találtuk. Ha viszont Composer használatával telepítettünk, akkor egy szinttel mélyebben, a _web/_ alkönyvtárban találjuk ezeket, ilyenkor ez lesz a gyökérkönyvtárunk.
. Mivel a Drupal eltérő könyvtárszerkezetekkel, több féle módon is telepíthető, verziókövetni pedig általában a gyökérkönyvtártól (angolul „docroot”) lefelé érdemes, ezért meg kell állapítanunk, hogy nekünk a gyökérkönyvtárunk hol található. Ha parancssorban egy `ls` parancsot kiadva látjuk a _core_, _modules_ és _themes_ könyvtárakat, akkor már meg is találtuk. Ha viszont Composer használatával telepítettünk, akkor egy szinttel mélyebben, a _web/_ alkönyvtárban találjuk ezeket, ilyenkor ez lesz a gyökérkönyvtárunk.
. Alapértelmezés szerint a verziókövetés minden egyes alkönyvtárra, és bennük valamennyi fájlra kiterjed. Bár a verziókövetés az esetek többségében valóban hasznos, de bizonyos dolgok változásait veszélyes vagy felesleges nyilvántartani:
+
......@@ -52,21 +52,21 @@ sites/*/files
config
----
. Hozzuk létre (idegen szóval _inicializáljuk_) a tárolót a `$ git init` paranccsal. Ezzel a csak sima, átlagos könyvtárunkat máris egy Git-tárolóvá alakítottuk, amiben innentől kezdve használhatjuk a verziókövetést.
. Hozzuk létre (idegen szóval _inicializáljuk_) a tárolót a `git init` paranccsal. Ezzel a csak sima, átlagos könyvtárunkat máris egy Git-tárolóvá alakítottuk, amiben innentől kezdve használhatjuk a verziókövetést.
. Adjuk hozzá valamennyi létező fájlt és alkönyvtárat (kivéve persze a fenti _.gitignore_-ban kizártakat) a menteni kívánt állapothoz a `$ git add -A` paranccsal. Így közöljük a Git-tel, hogy a következő állapotmentéskor mikről készítsen majd pillanatfelvételt.
. Adjuk hozzá valamennyi létező fájlt és alkönyvtárat (kivéve persze a fenti _.gitignore_-ban kizártakat) a menteni kívánt állapothoz a `git add -A` paranccsal. Így közöljük a Git-tel, hogy a következő állapotmentéskor mikről készítsen majd pillanatfelvételt.
. Ha szükséges, a `$ git status` paranccsal bármikor ellenőrizhetjük, hogy jelenleg mi szerepel a menteni kívánt állapotban (angolul „staged”). Ez általában egy tucat vagy még annál is kevesebb fájlt szokott jelezni, ahogy fejlődik a webhelyünk. De most – mivel a tárolónk változástörténetének legeslegelején vagyunk – a Drupal összes fájlját és könyvtárát (ami tízezernél is több!) fel fogja sorolni, hiszen mindegyik új a Git számára.
. Ha szükséges, a `git status` paranccsal bármikor ellenőrizhetjük, hogy jelenleg mi szerepel a menteni kívánt állapotban (angolul „staged”). Ez általában egy tucat vagy még annál is kevesebb fájlt szokott jelezni, ahogy fejlődik a webhelyünk. De most – mivel a tárolónk változástörténetének legeslegelején vagyunk – a Drupal összes fájlját és könyvtárát (ami tízezernél is több!) fel fogja sorolni, hiszen mindegyik új a Git számára.
. Kezdeményezzük az állapotmentést (vagy a magyar nyelvű webfejlesztők által gyakran használt kifejezéssel élve _kommitoljuk be_) a `$ git commit -m "Ez az első kommit ebben a repóban."` paranccsal.
. Kezdeményezzük az állapotmentést (vagy a magyar nyelvű webfejlesztők által gyakran használt kifejezéssel élve _kommitoljuk be_) a `git commit -m "Ez az első kommit ebben a repóban."` paranccsal.
. Ha szeretnénk meggyőződni az állapotmentés (vagyis _kommit_) sikerességéről, akkor a `$ git log` paranccsal vessünk egy pillantást a tárolónk – immár megkezdődött – változástörténetére.
. Ha szeretnénk meggyőződni az állapotmentés (vagyis _kommit_) sikerességéről, akkor a `git log` paranccsal vessünk egy pillantást a tárolónk – immár megkezdődött – változástörténetére.
. Eddig jól haladunk, már létezik egy biztos pont webhelyünk életében, ahová bármikor visszajöhetünk a jövőben, ha úgy érezzük majd, jobb lenne visszatérni a mostani kezdetekhez. Talán már sejtjük, hogy az „időutazás” ilyesféle formája mekkora segítség tud lenni bizonyos helyzetekben. Éppen ezért a Git-tárolónk információit – ahogy minden fontosabb adatot általában – érdemes több számítógépen is elhelyezni vész esetére. Most azonban még csak egy gépen van meg: azon, ahol a fenti parancsokat az előbb kiadtuk.
. Jelezzük a helyi Git-kliensünknek, hogy hol éri el a tárolónk távoli párját a `$ git remote add origin https://gitlab.com/pelda-nev/pelda-tarolo.git` paranccsal. Természetesen a webcím helyett a saját tárolónk korábban már feljegyzett klónozási webcímét használjuk.
. Jelezzük a helyi Git-kliensünknek, hogy hol éri el a tárolónk távoli párját a `git remote add origin https://gitlab.com/pelda-nev/pelda-tarolo.git` paranccsal. Természetesen a webcím helyett a saját tárolónk korábban már feljegyzett klónozási webcímét használjuk.
. Végezetül kezdeményezzünk szinkronizálást a tároló két példánya között a `$ git push -u origin master` paranccsal.
. Végezetül kezdeményezzünk szinkronizálást a tároló két példánya között a `git push -u origin master` paranccsal.
. Ha GitLabon vagy más verziókövetési szolgáltatónál helyeztük el a távoli tárolópéldányunkat, akkor innentől látni fogjuk az imént _bekommitolt_ fájlrendszerünket annak online felületén.
......@@ -76,17 +76,17 @@ Míg az előbbi lépéssort egyetlenegyszer, a tároló létrehozásakor kell cs
. Nyissunk meg egy parancssoros ablakot és navigáljunk el abba a könyvtárba, ahol a webhelyünk szoftverének forráskódja található.
. A korábban már bemutatott `$ git status` paranccsal ellenőrizzük, hogy mely fájlok változtak és jelenleg mi szerepel a menteni kívánt állapotban (angolul „staged”). Most azonban a fentiekkel ellentétben nem a Drupal összes tízezer körüli fájlját fogjuk látni felsorolva, hanem csak azt a párat, amit nemrég mi magunk módosítottunk – hiszen a Gitnek így már van viszonyítási alapja, amihez képest a különbözőségüket kiszámíthatja.
. A korábban már bemutatott `git status` paranccsal ellenőrizzük, hogy mely fájlok változtak és jelenleg mi szerepel a menteni kívánt állapotban (angolul „staged”). Most azonban a fentiekkel ellentétben nem a Drupal összes tízezer körüli fájlját fogjuk látni felsorolva, hanem csak azt a párat, amit nemrég mi magunk módosítottunk – hiszen a Gitnek így már van viszonyítási alapja, amihez képest a különbözőségüket kiszámíthatja.
. Magunk is megtekinthetjük ezeket a változásokat: az egyszerű szöveges fájlok (tehát nem a bináris adatokat tartalmazók, például képek vagy videók) előtte-utána állapotai közötti különbségeket a `$ git diff konyvtarneve/fajlneve.txt` paranccsal listázhatjuk ki.
. Magunk is megtekinthetjük ezeket a változásokat: az egyszerű szöveges fájlok (tehát nem a bináris adatokat tartalmazók, például képek vagy videók) előtte-utána állapotai közötti különbségeket a `git diff konyvtarneve/fajlneve.txt` paranccsal listázhatjuk ki.
. Ha minden módosult fájl változásait egyetlen állapotmentésben kívánjuk eltárolni, akkor a fentebb már megismert `$ git add -A` paranccsal hozzáadjuk őket a menteni kívánt állapothoz. Ekkor a `$ git status` paranccsal ismét ellenőrizhetjük, hogy mi fog bekerülni a _kommitba_. Ha parancssoros ablakunk támogatja a színek használatát (általában igen), akkor ami a 2. lépésben még vörös színnel volt írva, az immár zöld színűvé változott.
. Ha minden módosult fájl változásait egyetlen állapotmentésben kívánjuk eltárolni, akkor a fentebb már megismert `git add -A` paranccsal hozzáadjuk őket a menteni kívánt állapothoz. Ekkor a `git status` paranccsal ismét ellenőrizhetjük, hogy mi fog bekerülni a _kommitba_. Ha parancssoros ablakunk támogatja a színek használatát (általában igen), akkor ami a 2. lépésben még vörös színnel volt írva, az immár zöld színűvé változott.
. Ha a _staged_ listáját látva meggondolnánk magunkat, és egy bizonyos fájlnak mégsem kellene ebbe a _kommitba_ bekerülnie, akkor azt a `$ git reset HEAD konyvtarneve/fajlneve.txt` módon vissza tudjuk venni a menteni kívánt állapotból. Ha ennek éppen az ellenkezőjére, azaz csak egyetlen fájl _staged_ listához való hozzáadására van szükségünk, akkor azt is megtehetjük a `$ git add konyvtarneve/fajlneve.txt` módon. (Ne felejtsük, ha azt szeretnénk, hogy ezt az adott fájlt vagy könyvtárat a Git hagyja figyelmen kívül, akkor hozzáadhatjuk az útvonalát a korábban már tárgyalt _.gitignore_ fájlhoz.)
. Ha a _staged_ listáját látva meggondolnánk magunkat, és egy bizonyos fájlnak mégsem kellene ebbe a _kommitba_ bekerülnie, akkor azt a `git reset HEAD konyvtarneve/fajlneve.txt` módon vissza tudjuk venni a menteni kívánt állapotból. Ha ennek éppen az ellenkezőjére, azaz csak egyetlen fájl _staged_ listához való hozzáadására van szükségünk, akkor azt is megtehetjük a `git add konyvtarneve/fajlneve.txt` módon. (Ne felejtsük, ha azt szeretnénk, hogy ezt az adott fájlt vagy könyvtárat a Git hagyja figyelmen kívül, akkor hozzáadhatjuk az útvonalát a korábban már tárgyalt _.gitignore_ fájlhoz.)
. Kommitoljuk be a _staged_ listára összeválogatott fájlok módosításait a `$ git commit -m "Összefoglaló a módosításokról emlékeztetőül."` paranccsal. Miután a `$ git log`-gal ellenőriztük, hogy elégedettek vagyunk az új állapotmentés tartalmával és szövegével, küldjük fel a Git-tárolónk távoli példányába is a `$ git push` utasítással.
. Kommitoljuk be a _staged_ listára összeválogatott fájlok módosításait a `git commit -m "Összefoglaló a módosításokról emlékeztetőül."` paranccsal. Miután a `git log`-gal ellenőriztük, hogy elégedettek vagyunk az új állapotmentés tartalmával és szövegével, küldjük fel a Git-tárolónk távoli példányába is a `git push` utasítással.
. Ha a Git-tárolónknak több példánya is van (például a kollégánk is ebbe dolgozik), akkor a mások által felküldött változtatásokat (amik éppen ezért még nem lehetnek meg a mi gépünkön), a `$ git pull` paranccsal bármikor lehívhatjuk a saját helyi példányunkba is.
. Ha a Git-tárolónknak több példánya is van (például a kollégánk is ebbe dolgozik), akkor a mások által felküldött változtatásokat (amik éppen ezért még nem lehetnek meg a mi gépünkön), a `git pull` paranccsal bármikor lehívhatjuk a saját helyi példányunkba is.
===== Egy teljes tároló beszerzése a helyi gépünkre
......@@ -94,7 +94,7 @@ Ahogy az előző lépéssor végén már utaltunk rá, a verziókövetés nem cs
. Nyissunk meg egy parancssoros ablakot és navigáljunk el abba a könyvtárba, amin belül szeretnénk, hogy a helyi tárolópéldányunk létrejöjjön.
. A Git `clone` parancsának meghívásakor átadhatunk neki két értéket: a távoli tárolópéldány klónozási webcímét és egy tetszőleges könyvtárnevet (ha még nem létezik, automatikusan létrehozza), amin belülre kezdje el letölteni a fájlokat. Például `$ git clone https://gitlab.com/pelda-nev/pelda-tarolo.git masik-webhely-konyvtara`.
. A Git `clone` parancsának meghívásakor átadhatunk neki két értéket: a távoli tárolópéldány klónozási webcímét és egy tetszőleges könyvtárnevet (ha még nem létezik, automatikusan létrehozza), amin belülre kezdje el letölteni a fájlokat. Például `git clone https://gitlab.com/pelda-nev/pelda-tarolo.git masik-webhely-konyvtara`.
===== A webhely konfigurációjának kezelése a Git-tárolónkban
......
......@@ -78,15 +78,15 @@ image:images/extend-maintenance-mode-disabled.png["Webhely rendes üzemmódban m
. Parancssoros ablakban futtassuk az alábbi utasításokat, amelyek először engedélyezik a karbantartási módot, majd rögtön utána kiürítik a gyorsítótárat:
+
----
$ drush state:set system.maintenance_mode 1 --input-format=integer
$ drush cache:rebuild
drush state:set system.maintenance_mode 1 --input-format=integer
drush cache:rebuild
----
. A letiltás nagyon hasonló az előzőekhez, azzal a különbséggel, hogy a karbantartási mód értékét nullára állítjuk:
+
----
$ drush state:set system.maintenance_mode 0 --input-format=integer
$ drush cache:rebuild
drush state:set system.maintenance_mode 0 --input-format=integer
drush cache:rebuild
----
. Bármelyik parancsot is futtatjuk, javasolt ellenőrizni a megváltozott működést úgy, hogy a webhelyünket egy másik böngészőben (amiben nem vagyunk bejelentkezve) megnyitjuk.
......
......@@ -88,7 +88,7 @@ image:images/extend-manual-install-directories.png["Javasolt könyvtárszerkezet
. Csomagoljuk ki a _.tar.gz_ (vagy más) tömörített állományt, ami így egy alkönyvtárat hoz létre a fájllal azonos szinten. Ha a távoli kiszolgálónk Linuxon fut, és van parancssori hozzáférésünk, akkor egyszerűen futtathatjuk az alábbi parancsot, természetesen a fájlnevet lecserélve:
+
----
$ tar -xzf admin_toolbar-8.x-1.17.tar.gz
tar -xzf admin_toolbar-8.x-1.17.tar.gz
----
Ha nem Linuxon fut a kiszolgáló, vagy nem használhatjuk a parancssort, akkor a tárhelyszolgáltatónk valószínűleg kínál valamilyen grafikus felületet a kicsomagolás elvégzésére.
......
......@@ -81,7 +81,7 @@ image:images/extend-module-install-admin-toolbar-do.png["Modultelepítési oldal
. Miután a <<extend-manual-install>> vagy <<install-composer>> szakaszok egyikének lépéseit követve a letöltéssel megvagyunk, utána a következő Drush parancs lefuttatásával engedélyezzük (angolul „enable”, de véletlen egybeesésként magyarul is illik, így könnyű megjegyezni). A parancs paramétereként minden esetben meg kell adnunk a modul gépi nevét:
+
----
$ drush pm:enable admin_toolbar
drush pm:enable admin_toolbar
----
. Ezután már csak kövessük a parancssorban megjelenő utasításokat.
......
......@@ -82,8 +82,8 @@ image:images/extend-theme-install-appearance-page.png["Uninstalled themes on App
. Miután a <<extend-manual-install>> vagy <<install-composer>> szakaszok egyikének lépéseit követve a letöltéssel megvagyunk, utána a következő Drush parancsok lefuttatásával először engedélyezzük (angolul „enable”, de véletlen egybeesésként magyarul is ugyanígy kezdődik, így könnyű megjegyezni), majd pedig beállítjuk alapértelmezettként. A parancsok paramétereként minden esetben meg kell adnunk a smink gépi nevét:
+
----
$ drush theme:enable mayo
$ drush config:set system.theme default mayo
drush theme:enable mayo
drush config:set system.theme default mayo
----
. Ezután már csak kövessük a parancssorban megjelenő utasításokat.
......
......@@ -53,7 +53,7 @@ Ha még nem töltöttük le az alaprendszer forráskódját, és szeretnénk él
. Adjuk ki az alábbi parancsot, melyben a +webhelyem+ részt helyettesítsük be a létrehozni kívánt könyvtárunk nevével:
+
----
$ composer create-project drupal-composer/drupal-project:8.x-dev webhelyem --no-interaction
composer create-project drupal-composer/drupal-project:8.x-dev webhelyem --no-interaction
----
Sikeres lefutást követően létrejön a +webhelyem+ argumentumként megadott könyvtár, benne pedig egy _/web_ alkönyvtárban a Drupal alaprendszer legfrissebb kiadásának forráskódja. Emellett olyan hasznos fejlesztői eszközöket is kapunk, mint a _Drush_ és a _Drupal Console_.
......@@ -62,9 +62,9 @@ Sikeres lefutást követően létrejön a +webhelyem+ argumentumként megadott k
Bárkivel előfordulhat, hogy miután már feltelepítette a Drupalt a Drupal.org-ról letöltött _zip_ vagy _tar.gz_ fájlból (tehát Composer használata nélkül), később meggondolja magát és mégis szeretne élni inkább az automatikus függőségkezelés lehetőségével. Szerencsére ez sem lehetetlen: ha már telepítettük a Composert a gépünkre, de az még nem kezeli a Drupal kódbázisát, akkor az alábbi két lépéssel megtehetjük.
. Webhelyünk gyökérkönyvtárában adjuk ki a `$ composer global require grasmash/composerize-drupal` parancsot, mely letölti és a gépünkön általánosan elérhetővé teszi Matthew Grasmick átalakítóprogramját a Composerhez.
. Webhelyünk gyökérkönyvtárában adjuk ki a `composer global require grasmash/composerize-drupal` parancsot, mely letölti és a gépünkön általánosan elérhetővé teszi Matthew Grasmick átalakítóprogramját a Composerhez.
. Ha ez sikeresen települt, utána meghívhatjuk a Composeren keresztül a `$ composer composerize-drupal --composer-root=. --drupal-root=.` paranccsal.
. Ha ez sikeresen települt, utána meghívhatjuk a Composeren keresztül a `composer composerize-drupal --composer-root=. --drupal-root=.` paranccsal.
Így futtatva feltérképezi a Drupalunk könyvtárszerkezetét és összegyűjti belőle azokat az információkat, amikre majd a Composer-nek szüksége lesz. Ha webhelyünkhöz már töltöttünk le közösségi modulokat vagy sminkeket, és azokat az ajánlásoknak megfelelően a _modules/contrib_, _themes/contrib_, vagy _profiles/contrib_ nevű alkönyvtárakba tettük, akkor ez a program azokat is fel fogja fedezni és hozzáadja őket a Composer listájához. Ha viszont nem tettük őket ilyen alkönyvtárakba, akkor jobban járunk, ha letöröljük őket és a következő részben leírtakat követve újra beszerezzük őket, de immár a Composer segítségével.
......@@ -77,7 +77,7 @@ Külső függőségei azonban nemcsak az alaprendszernek lehetnek, hanem tulajdo
. Ha megvan a neve, akkor azt a következő parancsban a példaként használt „geofield” helyére behelyettesítve és egy parancssoros ablakban lefuttatva a Composer letölti a modult minden további szükséges függőségével együtt:
+
----
$ composer require drupal/geofield
composer require drupal/geofield
----
===== Korábban már Composerrel letöltött közösségi projektek frissítése
......@@ -89,20 +89,20 @@ Miután az előző részeknél leírtak szerint már használunk Composert a web
. Második lépésként meg kell határoznunk, hogy az adott szoftverelem melyik verzióját szeretnénk letöltetni a Composerrel. Egyszerű dolgunk van, ha a legfrissebb verziót kérjük:
+
----
$ composer update drupal/geofield --with-dependencies
composer update drupal/geofield --with-dependencies
----
. Ha valamilyen oknál fogva egy adott verzióra van szükségünk, akkor jó, ha tudjuk, hogy a kötőjeles verziószámok esetén a főverzió számát sosem kell külön megadnunk, hiszen az magától értetődő. Ha tehát azt látjuk a modul projektoldalán, hogy +8.x-1.7+ (amiben a kötőjel előtti szám webhelyünk Drupal-főverzióját jelöli), akkor a Composernek elég már csak az +1.7+ verziószámot megadnunk. Mindez azonban nem érvényes a Drupal 8 alaprendszerre, mert az a régies kéttagú verziószámok (például „Drupal 7.59”) helyett már a korszerű _szemantikus verziószámozás_ elvét követve háromtagú jelölést használ. Mivel pedig a +core+ magasabb szintű, mint a kiegészítők, ezért kötőjel sem szerepel benne. Ezt tehát továbbra is ugyanúgy ki kell írnunk a Composer-parancsokban: például +drupal/core:8.6.3+.
+
----
$ composer require drupal/geofield:1.7
composer require drupal/geofield:1.7
----
+
. Ha minden információ rendelkezésre áll, akkor a parancssoros ablakban webhelyünk gyökérkönyvtárában állva adjuk ki a fentiekhez hasonló parancsunkat, melyben a +geofield+ mintát értelemszerűen a frissíteni kívánt projekt nevére cseréltük.
==== Az ismeretek elmélyítése
A Composer használatát kézenfekvő módon annak beépített súgójából ismerhetjük meg. Például a fentebb már említett `$ create-project` utasításról a `$ composer help create-project` paranccsal olvashatunk bővebben.
A Composer használatát kézenfekvő módon annak beépített súgójából ismerhetjük meg. Például a fentebb már említett `create-project` utasításról a `composer help create-project` paranccsal olvashatunk bővebben.
//==== Kapcsolódó témák
......
......@@ -33,13 +33,13 @@ Lemásoljuk a meglévő webhelyünket, hogy legyen belőle egy másik példányu
* Ha az előbb említett grafikus felület nem elérhető számunkra, de van parancssori hozzáférésünk, akkor küldhetjük az utasítást közvetlenül a MySQL kiszolgálónak is (természetesen behelyettesítve a webhelyünk adatbázisának nevét, felhasználóját és annak jelszavát):
+
----
$ mysqldump -u USERNAME -p 'PASSWORD' DATABASENAME > BACKUPFILE.sql
mysqldump -u USERNAME -p 'PASSWORD' DATABASENAME > BACKUPFILE.sql
----
* Ha inkább Drusht használnánk, akkor ezt a parancsot futtassuk:
+
----
$ drush sql:dump --result-file=BACKUPFILE.sql
drush sql:dump --result-file=BACKUPFILE.sql
----
* Használhatjuk a https://www.drupal.org/project/backup_migrate[Backup and Migrate] nevű közösségi modult is. A modulok webhelyünkre való feltelepítéséről a <<extend-module-install>> részben volt szó.
......@@ -72,13 +72,13 @@ $settings['trusted_host_patterns']
* Ha viszont parancssoron keresztül exportáltuk fentebb, akkor az alábbi utasítást használhatjuk a MySQL kiszolgáló felé (a paramétereket ismét behelyettesítve persze):
+
----
$ mysql -u USERNAME -p PASSWORD DATABASE_NAME < BACKUPFILE.sql
mysql -u USERNAME -p PASSWORD DATABASE_NAME < BACKUPFILE.sql
----
+
* Drushsal is lehet importálni, mégpedig így:
+
----
$ drush sql:query --file=BACKUPFILE.sql
drush sql:query --file=BACKUPFILE.sql
----
. Ahogy fentebb már tapasztaltuk, két példány – bár ugyanannak az egy webhelynek a másolatai – eltérő beállításokat használhat a szétválasztott működésük érdekében. Az előbb átírt adatbáziskapcsolatokon kívül azonban számos további beállításuk különbözhet, amit ugyanúgy a _settings.php_ fájljaikban tárolnak. Lehetőség van azonban felülírást megvalósítani közöttük a `$config` változó segítségével. Például az éles webhely neve továbbra is maradjon „Bárkifalva Termelői Piac”, de a fejlesztési példányon ez inkább figyelmeztessen azzal, hogy átírjuk „DEV! – Bárkifalva Termelői Piac” címre. Ezt úgy érhetjük el, hogy mindkettő adatbázisában továbbra is meghagyjuk az éles szövegváltozatot, de a fejlesztési példány _settings.php_ fájljában elhelyezzük az alábbi kiegészítő sort:
......
......@@ -44,7 +44,7 @@ image:images/extend-module-install-download.png["Egy közösségi projekt letöl
. Itt tömörítsük ki a _tar.gz_ (vagy _zip_) fájlt, ami egy új könyvtárat fog létrehozni. Ha nincs parancssori hozzáférésünk, vagy a tárhely nem Linux operációs rendszeren fut, akkor a szolgáltató vezérlőpultjának fájlkezelője általában biztosít kicsomagolási lehetőséget. Ha viszont van parancssori hozzáférésünk a távoli szerverhez (és az Linuxon fut), akkor a következő parancs kiadásával csomagolhatjuk ki a tömörített fájlt:
+
----
$ tar -xzf drupal-8.3.2.tar.gz
tar -xzf drupal-8.3.2.tar.gz
----
. Ha a kitömörítési folyamat magától nem törölte volna a tömörített fájlt, akkor töröljük le mi magunk a szerverről.
......@@ -56,13 +56,13 @@ $ tar -xzf drupal-8.3.2.tar.gz
Ha már helyére került Drupal szoftver kódbázisa, akkor akár azonnal be is indíthatjuk próbaképpen a parancssorban a gyökérkönyvtárban állva az alábbi utasítás kiadásával:
----
$ php core/scripts/drupal quick-start standard
php core/scripts/drupal quick-start standard
----
Egy folyamatjelző lefutását követően perceken belül visszajelzést kapunk. Sőt, szervertől függően akár a böngészőnkben azonnal meg is nyílhat ez az ideiglenes bemutató célú webhely. Ahogy a <<install-decide>> résznél írtuk, ez pusztán csak egy demó, még _nem_ a végleges webhelyünk – amint bezárjuk a parancssort, nyom nélkül megszűnik. Mégis motiváló lehet azonnal látni előrehaladáunkat, ezért hasznos lehet bővebben is olvasnunk e funkcióról a súgóját megnyitva (angol nyelven):
----
$ php core/scripts/drupal quick-start --help
php core/scripts/drupal quick-start --help
----
// ==== Related concepts
......
......@@ -42,7 +42,7 @@ A <<install-run>> szakasz bemutatja az interaktív webes telepítő végigkattin
Ha a vizuális felületnél jobban szeretjük a parancssoros hozzáférést, akkor az alábbi Drush parancs közel ugyanezt végzi el. Gépeljük a következő utasításokat a parancssorba, ahol `example` annak a könyvtárnak a neve, ahova az alaprendszert letöltöttük, valamint a `DB_NAME`, `DB_USER` és `DB_PASS` az adatbázis hitelesítő adatai:
----
$ drush site:install standard --db-url='mysql://DB_USER:DB_PASS@localhost/DB_NAME' --site-name=example
drush site:install standard --db-url='mysql://DB_USER:DB_PASS@localhost/DB_NAME' --site-name=example
----
//==== Kapcsolódó témák
......
......@@ -34,7 +34,7 @@ A Kézikönyv során a következő fogalmazási és szerkesztési gyakorlatot k
* Minden olyan szöveget, amelyet egy parancssori ablakba kell begépelnünk, +egyenszélességű+ betűvel jelöltünk:
+
----
$ drush cache:rebuild
drush cache:rebuild
----
* Bár egyesek ritkán mappáknak szeretik hívni a fájlok tárolóit, a Kézikönyvben azonban az elterjedt szóhasználatnak megfelelően könyvtáraknak nevezzük őket.
......
......@@ -44,7 +44,7 @@ $settings['update_free_access'] = TRUE;
. Csomagoljuk ki a _tar.gz_ vagy _zip_ fájlt a távoli szerver egy ideiglenes könyvtárába, aminek kívül kell esnie a webhely telepítési könyvtárán (másképpen „docroot”). Valószínűleg a tárhelyszolgáltató által biztosított adminfelületnek van a kicsomagolásra szolgáló funkciója. Ha van parancssori hozzáférésünk a távoli (Linuxon futó) szerverhez, akkor használhatjuk az alábbi parancsot is:
+
----
$ tar -xzf drupal-8.3.2.tar.gz
tar -xzf drupal-8.3.2.tar.gz
----
. Most a webhelyünk eredeti telepítési könyvtárában töröljük ki a _core_ és _vendor_ könyvtárakat, valamint minden fájlt, ami nem alkönyvtárban van (beleértve a _.htaccess_, _composer.json_ és _autoload.php_ fájlokat is). Csak azokat hagyjuk meg, amelyekben valami módosítást végeztünk.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment