„[…] nem tökéletes telepítést engedett?”

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

„[…] a Webes felületen lévő Bővítés felület sz-rt sem ér?”

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.

„Akkor el kell venni […]”

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.

„a parancsorra akarja vinni a felhasználókat”

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.

„csak 4 ezren használják, szemben a Rules 116 ezrével”

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

„Ui: A Drupal.hu meghalt, hogy szinte halott a fórum?”

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.

„[…] 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.

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

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.