„[…] ha adott modulokat lehetne pénzzel támogatni”

Ami az anyagi támogatást/motivációt illeti, többféle módját is keresik és/vagy már használják is páran. Amíg a Drupal Association nem dolgoz ki központilag biztosított funkciót a Drupal.org-on, addig a jelenlegi körkép valóban kissé vegyes:

Páran (pl. a Webform és LDAP modulok, a FarmOS Drupal-disztribúció vagy a Simplytest.me tesztfelület) az Open Collective platformot használják.

Vannak (pl. Pekker Bálint vagy Dmitry Porokhnya), akik a gyorsabb, egyszerűbb adakozást elősegítő Buy Me a Coffee-n regisztrálták magukat.

Akad példa arra is, hogy valaki a Composer csomagkezelő által biztosított csatornán keresztül kommunikálja, hogyan lehet őt támogatni az ügy érdekében:

„A profik, tehát akik kenik-vágják a PHP-t, és tudnak Drupal modult írni, azok, ha nem használják a Rules-t, hogyan oldják meg?”

Bár nem mondanám magam profinak, de annyit tudok hozzátenni a témához, hogy ahogy DJ is említette, a D8-cal annak idején meglépett szemléletváltás egyben az objektumorientált programozási elvek fokozatos meghonosítását is jelentette. Ez lefordítva annyit tesz, hogy míg korábban a D7-ig bezárólag minden HTTP-kérés kiszolgálása egyetlen nagy „olvasztótégelyben” (ez a globális névtér a PHP-ban) futott le (és a Drupal a saját hurok-rendszerét is azért volt kénytelen kifejleszteni, mert az akkori PHP-verziók még nem kínáltak kész megoldást a modulokkal való bővíthetőségre), addig a D8 alapjainak a Symfony keretrendszerre való átépítésével ez a hatalmas hook-univerzum egy sokkal tisztábban, átláthatóbban és biztonságosabban fenntartható irányra áll át folyamatosan az évek alatt (ezek az egyéni névterek PHP-ban). Látjuk, hogy minden más korszerű PHP-alapú CMS is ugyanebbe az irányba megy, sőt, nemzetközi sztenderddé is emeltek sok közös jó gyakorlatot (ezek a PSR-szabványok). De a kérdésedre válaszolva: ebben a korszerűbb, Symfony-alapú világban már eseményeket „sütnek el” (az angol „event firing” vagy „event dispatching” kifejezések szabad fordításban), más modulok pedig ezekre az eseményekre iratkoznak fel (subscribe-olnak), így kapsz értesítést a saját kis modulodban arról, ha például egy node-ot elment a felhasználó. Nyilván amit leírtam, az egy végtelenül szubjektív és talán nem is minden részletében kifogástalan leírása a helyzetnek, de nagy vonalakban talán segít megérteni, hogy miért van leáldozóban a hook-ok napja és mi váltja fel őket helyette.

Magát a Rules modult nekem sosem kellett használnom, de azt folyamatosan érzékeltem, hogy mindig is népszerű, gyakran említett modul volt itt a Drupal.hu-n. Azoknak, akik alternatívát keresnek helyette (és nem lehetőség számukra kódot írni), jó szívvel ajánlom a hasonló célú, de teljesen más alapokra épülő ECA modulrendszert, amivel viszont túlnyomórészt pozitív tapasztalatom volt ügyfélprojekteken. (Amúgy pedig maga a Rules a saját projektoldalán is ajánlja maga helyett.)

„És hol lehet megtanulni, hogy hogyan lehet modult írni Drupalhoz?”

Sajnos magyar nyelvű tananyagról nem tudok, de szerencsére vannak nagyon jó fordítóprogramok a Google Translate-en túl: a DeepL messze értelmesebben fogalmaz magyarul, valamint a magánszféra-tudatosak népszerű Brave böngészője gyárilag beépített fordítót is tartalmaz, ami csak a helyi gépeden fut offline, nem küld semmilyen adatot távoli szerverre pontosítás május 3-án: küld, csak nem tárol semmit tartósan.

Ha viszont a nyelvi nehézségek áthidalva, akkor érdemes a Drupalize.me-vel akár csak egy ingyenes próbaidőszakot kipróbálni. Ennél összeszedettebb, naprakészebb és érthetően elmagyarázott Drupal fejlesztői tananyagról jelenleg nem tudok a piacon. Akár teljesen kezdő PHP-szintről is el lehet kezdeni vele D10-es modulokat írni. Ízelítőül a témakörök listája.

Itt nem lenne rossz, ha végfelhasználói szemszögből írnád le, hogy mit is kellene csinálni.

Nekem a 'nem szerkeszthető mezőbe js kód csinál valamit' erősen villogtatja a bad pattern lámpát, szóval itt jó eséllyel vissza kellene térni az alapolhoz, hogy
1. Mid van (js kód, etc)?
2. Mit kell tudni a szerkesztőknek?
3. Ebből mi fog megjelenni a végfelhasználóknak.