Több problémát is felsoroltál, amikre ennyi infó alapján nem tudok egyesével válaszolni, de úgy tűnik, mintha közös pont lenne bennük, hogy a konfiguráció megváltozott.

Ha megvan korábbról a kiexportált (vagy ahogy a $ drush cex -y parancs alapján hallani így is: „kicexelt”) konfigurációja a webhelyednek, és nincs vesztenivaló adatod a DB-ben, akkor megpróbálhatod újratelepíteni („újrahúzni”) a site-ot: $ drush site:install --existing-config.

Mielőtt csatlakoznék a Devel modul gyanúsításához a helyzet okozójaként, előtte szívesen hallanék a pontos lépéssorról, amit követtél. Ha részletesen leírod, abból lehet kiderül, hol történhetett a nem várt változás a konfigurációban.

„Tehát a Composer tölti fel a tárhelyre a telepítendő Drupal file-okat, és Drush-sal lehet ténylegesen telepíteni”

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.

„A végeredmény szempontjából van különbség a hagyományos telepítés […] vagy a Drush-sal?”

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:install parancsnak adod meg a --locale=hu paramétert, akkor ő elvárja, hogy a nyelvi fájlok már előre oda legyenek készítve a kódbázisba.

„Ezek szerint ha nem Composer-rel történik a feltöltés, akkor bizonyos függőségek hiányoznának?”

Lásd fentebb kifejtve.

„Csak mert a hagyományos módszer használata esetén sem jelzett függőség hiányt a telepítő”

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.

„Tehát egy profi fejlesztő azt csinálja, hogy amikor jelez neki a Drupal a grafikus felületen […]”

Csak nagyon ritkán használjuk a grafikus felületet, frissítések kezelésére pedig egyáltalán nem. A $ composer outdated paranccsal 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 update parancsot használjuk, azt különböző kapcsolókkal kiegészítve. Egy példa: $ composer update 'drupal/*' --with-all-dependencies csak 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.

„[…] össze is kavarodik a rendszer, vagy valahogy ki lehet javítani ezt a bakit?”

Ha a composer.json és .lock fájljaid rendben vannak, akkor bármikor nyugodt szívvel törölheted a vendor/ könyvtáradat, valamint Drupalon belül a core/, modules/contrib/ themes/contrib/ és profiles/contrib/ 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.

„CLI kényelmetlensége”

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.

„Ami ott le van írva, az egy rémálom, annyi hibalehetőséget jeleznek előre […]”

Mutatsz linket kérlek?

Frissítés 2025. 03. 25-én: a „nyugodt szívvel törölheted” mondatban helyesen csak a contrib/ alkönyvtárak tartalmát pótolja a Composer automatikusan, egy custom/ alkönyvtárét nem.