Tartalom

Bevezető

Korábban már írtam a Color backport modulról egy másik leírásban ahol arról volt szó, hogy a Drupal alaprendszerében lévő Color modult elavulttá nyilvánították, és felkerült helyette egy külső fejlesztésű Color backport modul. Ez utóbbi modul korábban (az 1.0.2 verzió előtt) még "color-color" gépi néven futott, amit most ebben az 1.0.2-es verziójú frissítésben módosítottak "color" gépnévre. Ezzel nincs is semmi gond, csak mivel most így kétféle gépnevű modulunk van, így az egyik (a régi) feleslegessé válik, amit a frissítés után célszerű eltávolítanunk, hogy ne maradjanak plusz dolgok a Drupal oldalunk fájlrendszerében.

Ebben a rövid leírásban tehát átnézzük ennek a modulnak a webes, illetve a Composer csomagkezelővel történő frissítését és lecserélését. A feladat nagyon egyszerű, de mivel kicsit eltér egy szokványos modulfrissítéstől, ezért érdemes átfutni a műveletet.

A modul könyvtárstruktúra ellenőrzése

Csak a precízség kedvéért, mielőtt nekiállnánk a Color backport modul frissítésének, vessünk egy pillantást a moduljaink könyvtárstruktúrájára:

Itt rászűrtem a grep paranccsal a "color" szót tartalmazó modulokra, hogy áttekinthetőbb legyen az egész. A colorbox kezdetű könyvtáraknak itt most nincs jelentősége -  ezek más modulokat tartalmaznak -, hanem itt láthatunk még egy "color-color" nevű könyvtárat is, ez tartalmazza a régi Color backport modulunkat. Erre majd még visszatérünk, addig jöjjön a modul frissítése.

A Color backport modul frissítése

A modult kétféleképpen is frissíthetjük, de mindkét esetben célszerű eltávolítani a feleslegessé vált modul változatot.

Első körben győződjünk meg az admin felületen a modul frissíthetőségéről. Ezt megtehetjük az Admin - Jelentések - Elérhető frissítések menüpontban:

vagy pedig a Bővítés főmenü Frissítés fülére kattintunk:

Innen folytatva haladhatunk is tovább a webes frissítéssel.

Frissítés a Drupal webes admin felületén

Ha nem rendelkezünk parancssori hozzáféréssel tárhelyünkhöz, vagy egyszerűen csak nem szeretjük a parancssort, akkor frissítsük a webes admin felületen keresztül a modult.

Frissítés lépései

Hajtsuk végre a modul frissítésének szokásos lépéseit:

Itt nincsenek adatbázis frissítések, tehát egyszerűen továbbléphetünk az adminisztrációs oldalakra, ahonnan ellenőrizhetjük ismét a moduljaink állapotát:

Renben van minden modul.

A modul könyvtárstruktúra ismételt ellenőrzése

A frissítés után ellenőrizzük újra a modul könyvtárat:

Itt láthatjuk, hogy létrejött egy új könyvtár, nevezetesen "color" néven.

Tehát ahogy a bevezetőben már említettem, a modul jelenlegi frissítése egy gépi névváltozást is tartalmaz, amiből kifolyólag marad egy felesleges könyvtárunk, amiben a régi modul változata van.

Feleslegessé vált könyvtár törlése

Ezt a könyvtárat töröljük. Ha rendelkezünk SSH hozzáféréssel, akkor az alábbi paranccsal:

rm -rf color-color

Ezután frissítsük a Drupal cache rendszerét. Én a Drush-al teszem ezt meg:

drush cr

Modul ellenőrzése

Végül ellenőrizzük a modult a jelentések oldalon:

Itt a lista alján láthatjuk, hogy a Color backport modul rendben van, az 1.0.2 változat működik a rendszerben.

Frissítés Composer segítségével

A körülmények ugyanazok, mint a webes frissítéskor, most frissítsük a Color backport modult a Composer PHP csomagkezelő segítségével. Ez a rész azoknak ajánlott, akik rendelkeznek parancssori hozzáféréssel, és a composer paranccsal frissítik a Drupal moduljaikat.

A kiindulópont tehát ugyanaz, ellenőrizzük a modul könyvtárat a modules/contrib/ útvonalon, és benne a "color" kezdetű modulokat:

ls -alh modules/contrib | grep "color"

A friss Color backport modul telepítése

Telepítsük a friss modul változatot az alábbi paranccsal:

composer require 'drupal/color:^1.0'

./composer.json has been updated
Running composer update drupal/color
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking drupal/color (1.0.2)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing drupal/color (1.0.2): Extracting archive
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Package symfony/debug is abandoned, you should avoid using it. Use symfony/error-handler instead.
Package webmozart/path-util is abandoned, you should avoid using it. Use symfony/filesystem instead.
Generating autoload files
Hardening vendor directory with .htaccess and web.config files.
47 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Cleaning installed packages.

Sikeres telepítés esetén ilyen kimenetet kapunk.

Ezután ránézhetünk újra a könyvtárra:

ls -alh modules/contrib | grep "color"

Illetve a csomagok verzióit is megnézhetjük:

composer show "drupal/color*"

Hasonlóan a webes telepítéshez, itt is jelen van a két modul változat.

A régi Color backport modul eltávolítása

Távolítsuk el a régi modult az alábbi paranccsal:

composer remove drupal/color-color

Itt láthatjuk, hogy a Composer el is távolította a régi, 1.0.1-es modulváltozatot.

Normál esetben most jönne az adatbázis frissítése, de ennél a modulnál már ismerjük a webes részről, hogy nem frissült benne semmi adatbázissal kapcsolatos rész.

Ezután már csak a cache-t kell frissíteni:

drush cr

Modul ellenőrzése

Ránézhetünk parancssorból is az új állapotra:

ls -alh modules/contrib | grep "color"
composer show "drupal/color*"

Itt már csak a "color" nevű modul található, aminek 1.0.2 a verziója.

Illetve megnézhetjük még az adminban is:

"Color backport 1.0.2".

A modul Composer-el történő lecserélése is biztonságos, mivel ugyanazokat az adatbázis beállításokat használják, így megmarad minden beállítás.

Szerveroldali gyorsítótár ürítése

Sok szerverkonfiguráción még szükség lehet egy szerveroldali gyorsítótár ürítésére is. Ez ebben az esetben a PHP opcache gyorsítótárat jelenti. Amennyiben tehát engedélyezve van ez a PHP bővítmény, ebben az esetben hibába ütközhetünk, amennyiben nem ürítjük ezt.

A hibaüzenet

Ha nem töröljük ezt a gyorsítótárat, akkor a weboldal nem töltődik be, és a rendszerben az alábbihoz hasonló hibaüzenet jön létre:

[proxy_fcgi:error] [pid 31684:tid 140552005740288] [client 80.95.83.251:61910] AH01071: Got error 'PHP message: TypeError: Argument 1 passed to Drupal\\Core\\Render\\Renderer::doTrustedCallback() must be callable, array given, called in
/var/www/clients/client1/web7/web/core/lib/Drupal/Core/Render/Renderer.php on line 772 in
/var/www/clients/client1/web7/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php on line 51 #0
/var/www/clients/client1/web7/web/core/lib/Drupal/Core/Render/Renderer.php(772): Drupal\\Core\\Render\\Renderer->doTrustedCallback()\n#1
/var/www/clients/client1/web7/web/core/lib/Drupal/Core/Render/Renderer.php(363): Drupal\\Core\\Render\\Renderer->doCallback()\n#2
/var/www/clients/client1/web7/web/core/lib/Drupal/Core/Render/Renderer.php(435): Drupal\\Core\\Render\\Renderer->doRender()\n#3
/var/www/clients/client1/web7/web/core/lib/Drupal/Core/Render/Renderer.php(201): Drupal\\Core\\Render\\Renderer->doRender()\n#4
/var/www/clients/client1/web7/web/core/lib/Drupal/Core/Template/TwigExtension.php(479): Drupal\\Core\\Render\\Renderer->render()\n#5
/var/www/clients/client1/web7/web/site...', ...

Ez azért fordulhat elő, mert a Drupal sok egyéb mellett a modulok útvonalait is eltároltatja a PHP opcache gyorsítótárban. És mivel lecseréltünk egy modult ami innentől másik könyvtárnévvel érhető el, ezért ez problémát okoz az alaprendszerben.

A hiba elhárítása - PHP opcache ürítése

A hibát úgy orvosolhatjuk, ha újraindítjuk a PHP rendszert. Ez kétféle módon tehetjük meg, attól függően, hogy hogyan épül fel a szerverünk:

A PHP Apache modulként fut

Régebbi szerverkonfigurációkon még előfordulhatnak ilyen összeállítások, amikor a PHP Apache modulként fut. Ez már nagyon elavult módja a PHP futtatásának, de még sok ilyen van. Ha így működik a szerverünk, akkor indítsuk újra az Apache-ot az alábbi paranccsal root-ként:

systemctl restart apache2

A PHP-t a PHP-FPM kezeli

A korszerűbb szerverkonfigurációkban a PHP-t a PHP-FPM kezeli. Ebben az esetben a PHP verziójától függően futtassuk az alábbi parancsot, például a 7.4-es PHP esetén:

systemctl restart php7.4-fpm

A PHP újraindításával elkezdődik a PHP opcache újraépítése, amibe így már a lecserélt modul új útvonala fog eltárolódni.

Ha nem rendelkezünk a tárhelyen/szerveren root jogosultságokkal, akkor kérjük meg a rendszergazdát, hogy szükségünk lenne egy PHP opcache törlésre.

Konklúzió

Ezen a példán keresztül látható, hogy bármelyik módszerrel frissíthetjük vagy eltávolíthatjuk Drupal moduljainkat. Azonban érdemes észben tartani, hogy azt a módszert válasszuk egy adott modul frissítésére vagy eltávolítására, amelyikkel telepítettük azt. Így tehát ha egy modult a webes részen telepítettünk, akkor ott is frissítsük tovább, vagy az eltávolítást ilyenkor végezhetjük a modul könyvtárának törlésével, ha pedig a Composer-el telepítettük, akkor pedig azzal frissítsük, vagy szükség esetén távolítsuk el.

Továbbá, ha olyan modullal kapcsolatos műveletet hajtunk végre, ahol megváltozik a modul elérési útvonala a fájlstruktúrában (másik könyvtárba kerül vagy megváltozik a neve), akkor ebben az esetben gondoskodjunk a szerver oldali (PHP opcache) gyorsítótár ürítéséről is.