Drupal 10+, Composer, Drush

druid képe

Üdv!

Napok óta azon dolgozom, hogy feljebb lépjek és megismerjem a Composer, Drush használatát, hogy honlap építőből honlap fejlesztővé váljak mielőbb.

Néztem a drupal.org leírásait, a Google-ban kerestem, stb, de egyszerűen nem tiszta a dolog.

Most akkor a Composer-rel kell telepíteni a Drupal 10-et, vagy sem? Mert azzal csak az adott server mappába kerültek a telepítésre váró állományok, de onnantól kezdve a hagyományos, böngészőből indítható megoldás van csak, ráadásul mivel egy /web mappába kerülnek ezek a file-ok, a server tartomány beállításainál a public_html mappa helyett a public_html/web mappát kell beállítanom (nem tudom ez-e a jó megoldás, de működik).

Én azonban szeretném parancssorból telepíteni és van ahol azt írják, hogy Drush-sal lehet, de hogy hogyan, azt már nem.

Szóval akkor most a Composer, vagy a Drush telepíti magát a Drupal-t és mikor lehet megadni az adatbázis infókat, mert ugye anélkül nem fut le a telepítés.

Az is gond, hogy miután telepítettem a Composer-t, ha cPanleben keresem hol van, akkor nem úgy van mint Windows-ban, hogy meg tudom nézni milyen alkalmazások vannak telepítve, itt ott találtam Composer nevű file-okat, de nincs egy összefoglaló kép az egészről. Ennyire más a Linux, mint a Windows?

És akkor ott van az, hogy globálisan, vagy lokálisan települt-e, stb.

Nem kérem, hogy valaki itt leírja a válaszokat, csak annyit, hogy (lehetőleg magyar nyelvű) részletes leírást linkeljen nekem, ahol minden kérdésre választ tudok kapni.

Érteni akarom, amit csinálok, nem csak leírások alapján elvégezni.

Drupal verzió: 
druid képe

Ha jól értem, akkor nem a Composer, hanem a Drush telepíti a Drupalt, a Composer csak letölti a szükséges file-okat. Az tévesztett meg (joggal), hogy miután a Composerrel végrehajtottuk az alábbi parancsot

composer create-project drupal/recommended-project:10.3.5 "folder"

és lefutott, azt írta ki a futás végén, hogy

Congratulations, you’ve installed the Drupal codebase from the drupal/recommended-project template!

tehát az "install" szót használja, ami telepítést szokott jelenteni.

de Composer-rel nem lehet telepíteni a Drupal-t, hanem előbb a Drush-t kell telepíteni a Composer-rel

composer require --dev drush/drush

és majd a Drush segítségével lehet parancssorból telepíteni a Drupalt

drush site:install

ami valójában csak teljes könyvtár útvonal megadással működik:

./vendor/bin/drush site:install

És lám, itt is az "install" szót használják, szóval ez, mint fent írtam eléggé megtévesztő...

1
0
druid képe

Üdv!

Valahol azt olvastam, hogy nem szabad keverni a frissítési módozatokat, azaz vagy csak Drush-sal, vagy a szokásos, Drupal grafikus felületéről elérhető megoldást (Állapotjelentés, modulfrissítés) kell használni, mert ha hol így, hol úgy, akkor a Drush nem fogja tudni követni a nem a Drush-ból indított frissítéseket.

Ez így van?

Ha így van, le lehet valahogy tiltani a grafikus felületről indítható frissítéseket, nehogy megszokásból az is használva legyen?

0
0
Balu Ertl képe

„Szóval akkor most a Composer, vagy a Drush telepíti magát a Drupal-t?”

A Drush, ezzel a paranccsal: $ drush site:install. Használhatod a parancs --help kapcsolóját a leírásának elolvasásához vagy online itt találod. (Ezen az oldalon ne felejtsd el kiválasztani a Drush-od verzióját, előfordulhatnak eltérések a verziói között.)

„[…] mikor lehet megadni az adatbázis infókat, mert ugye anélkül nem fut le a telepítés”

Vagy még futtatás előtt beleírod a settings(.local).php fájlodba (ekkor keress rá a $databases változóra, hogy megtaláld a leírást benne, hogyan lehet), vagy pedig magának a Drush-parancsnak adod át őket bemenetként (erről pedig az előbbi --help kapcsolóval olvashatsz).

„[…] de nincs egy összefoglaló kép az egészről.”

Ezt nem értem pontosan, mire gondolhatsz, de a Composer alfája és omegája a két fájlja a projekted gyökerében: a composer.json és a composer.lock. Ezek (szinte) minden információt tartalmaznak, amiből képet kaphatunk a projektünk összetételéről.

„És akkor ott van az, hogy globálisan, vagy lokálisan települt-e?”

Feltételezem, itt a Composer-re gondolhatsz. A projekted gyökerében állva egy $ whereis composer paranccsal kilistázhatod az ilyen nevű futtatható binárisokat, amik fellelhetőek az oprendszered (Linux vagy macOS – Windowst nem tudom) $PATH változójában felsorolt könyvtárak valamelyikében. Nekem például egy ilyen eredményt ad:
composer: /usr/local/bin/composer /var/www/html/vendor/bin/composer

Nálam ebből az első a globális, a második a projekt függőségeinek könyvtárába (vendor/ mappa) telepített, tehát a lokális. Ezeknek eltérő lehet a verziója és a beállításaik, ezért sokan ha tutira akarnak menni, szeretik fixen kiírni a projekt saját Composer-példányának az útvonalát, nehogy azon haljon el a szkript, hogy tévedésből a globális példányt keresi, ami viszont ritkán szokott telepítve lenni a szervereken.

„tehát az "install" szót használja, ami telepítést szokott jelenteni”

A drupal/core-recommended projektsablon többek között igényel egy drupal/core-project-message nevű Composer-bővítményt is. Ez a kis kiegészítő annyit csinál, hogy kiolvassa a „szülő” projektsablon composer.json fájljából az ott megadott üzenetet és megformázva visszaszajkózza a telepítési folyamat egy bizonyos pontján a parancssorba. A hátteréről ebben a 2019-es ticketben olvashatsz, ez a kettő pedig még nyitott, de szintén ehhez kapcsolódik. Ha gondolod, az utóbbi alá odakommentelheted az észrevételed az „install” szó helytelen használatáról. Ha szeretnéd, szívesen segítek megfogalmazni.

„[…] mert ha hol így, hol úgy, akkor a Drush nem fogja tudni követni a nem a Drush-ból indított frissítéseket”

Így van, ahogy írod, annyi pontosítással, hogy itt nem a Drush-ról van szó, hanem a Composer-ről, hiszen a nyilvántartást a telepített komponensekről és azok verzióiról (és még sok másról) a Composer vezet, nem a Drush.

„le lehet valahogy tiltani a grafikus felületről indítható frissítéseket?”

A kódbázis grafikus felületen keresztül való piszkálását szándékosan szorítjuk már háttérbe, már a 10.4-es alaprendszerből kikerült ez a régi örökség, a mögöttes érvekről is ugyanitt lehet olvasni. A letiltás ötlete jogos, ám életszerűtlen, hiszen általában 1–2 adminisztrátor végzi a webhely frissítését, ők pedig azért csak meg tudnak állapodni maguk között a mikéntjéről.

1
0
druid képe

Szóval akkor most a Composer, vagy a Drush telepíti magát a Drupal-t?

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

  • A végeredmény szempontjából van különbség a között, hogy a hagyományos, azaz a böngészőből elérhető interaktív felületen telepítjük a Drupal-t, vagy a Drush-sal?
  • A Composer más szerkezetben és több file-t, mappát tesz fel, mintha a Drupal core zip-jét tölteném fel FTP-vel. Ezek szerint ha nem Composer-rel történik a feltöltés, akkor bizonyos függőségek hiányoznának? Csak mert a hagyományos módszer használata esetén sem jelzett függőség hiányt a telepítő.

És akkor ott van az, hogy globálisan, vagy lokálisan települt-e?

Amikor telepítettem a Composer-t, nem rémlik, hogy a parancsban volt arra utaló rész, hogy globális, vagy lokális lesz-e a telepítés.

Erre van egy parancs, vagy attól függ, hogy a tárhely gyökerében állok-e a parancs kiadásakor, vagy pl. a public_html mappában?

[…] mert ha hol így, hol úgy, akkor a Drush nem fogja tudni követni a nem a Drush-ból indított frissítéseket

le lehet valahogy tiltani a grafikus felületről indítható frissítéseket?

  • Tehát egy profi fejlesztő azt csinálja, hogy amikor jelez neki a Drupal a grafikus felületen, hogy valamihez frissítés érkezett (core, module, theme), akkor nem azt csinálja, hogy ott egy kattintással (kényelmes) bejelöli és lefuttatja a frissítéseket, hanem belép a server-re és a parancssoros részen elkezdi egyenként bepötyögni a parancsot, megkeresi az adott module, stb, nevét, azt is utána írja, közben lehet, hogy elírja a nevet, stb, lefuttatja, majd az összes többivel egyenként? Mert ez egyrészt nem tűnik sem kényelmesebbnek, sem gyorsabbnak, sőt, tele van hibázási lehetőséggel.
  • És mi van, ha véletlenül, megszokásból egy modult, vagy témát, stb. a grafikus felületről frissítünk, akkor a Composer azt a modult már nem fogja tudni frissíteni később, sőt, rossz bejegyzések miatt még össze is kavarodik a rendszer, vagy valahogy ki lehet javítani ezt a bakit?
  • PuTTY-val szoktam a szerverhez csatlakozni, van amiben tetszik a parancssoros munka, izgalmas, sokszor gyorsabb a parancs végrehajtása, de elég kényelmetlen pl. navigálni ott, copy/paste nehézkes, ha lenne parancskiegészítője, mint pl. a Notepad++ esetében, amikor valamilyen kódot írunk, hogy felajánlja a lehetőségeket, akkor még jó is lenne, de így...
  • Néztem meddig lesz érvényes a Drupal 10-es (most térek át 7-esről), hát, az is csak pár év. Aztán néztem hogyan lehet majd áttérni 11-re. Ami ott le van írva, az egy rémálom, annyi hibalehetőséget jeleznek előre, és annyi mindent kell majd előre beállítani, megváltoztatni, nem gondoltam, hogy ezek a fő verzióváltások még a 10-ről 11-re sem lesznek egy Composer paranccsal megoldhatók. Így nem csoda, hogy a Wordpress felhasználóinak a száma, ha jól tudom 70% fölötti, a Drupal meg még a 10%-ot sem éri el...
0
0
Balu Ertl képe

„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/ themes/ és profiles/ 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?

1
0
druid képe

CLI kényelmetlensége

PuTTY elterjedt és a tárhelyszolgáltató is azt ajánlja, szóval...

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

https://www.drupal.org/docs/upgrading-drupal/upgrading-from-drupal-8-or-...

0
0
Balu Ertl képe

Nos igen, így listába összegyűjtve valóban sok lépésnek, ezáltal hosszúnak tűnik a folyamat. Én most délután húztam fel az egyik helyi környezetemet D10-ről D11-re és járt némi új tanulsággal (saját hülyeségemből okoztam, teszem hozzá :)

De nézzük a jobbik oldalát, legalább van egy jól összeszedett dokumentáció a folyamatról :)

0
0
druid képe

Üdv!

Az eddigi Composer-es feltöltések sikeresek voltak, most azonban nem, viszont ha ugyanezt a webes felületről telepítettem, akkor sikeres lett.

Mi itt a probléma?

composer require 'drupal/tr_rulez:^2.0'

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Root composer.json requires drupal/tr_rulez ^2.0 -> satisfiable by drupal/tr_rulez[2.0.0].
- drupal/tr_rulez 2.0.0 requires drupal/rules 4.0.x-dev -> found drupal/rules[dev-4.0.x, 4.0.x-dev (alias of dev-4.0.x)] but it does not match your minimum-stability.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

0
0
Balu Ertl képe

„Mi itt a probléma?”

Ezt megkérdezheted magától a Composertől is, hogy szerinte miért nem jó egy csomag adott verziója a projektedhez :)

$ composer why-not drupal/tr_rulez 2.0

A válasza azonban nem mindig segít jobban megérteni, ilyenkor megpróbálhatod az általa az üzenet végén javasolt --with-all-dependencies kapcsolóval:

$ composer require 'drupal/tr_rulez:^2.0' -W (ez a rövidítése)

A tr_rulez kódjából ugyanis az látszik, hogy legalább 4.0-s (vagy újabb) kiadás szükséges számára a rules csomagból.

Egyébként javaslom, kezdj el lassan ismerkedni az ECA modulcsaláddal, mert egyelőre annak tűnik ígéretesebbnek a jövője.

1
0
druid képe

Eleve 4-es Rules van fent, mivel az van 10-eshez.

A kérdésem igazából arra irányult - mivel láttam a Composer válaszát magam is, nem venném el itt mások idejét olyannal, amire találok választ máshol - hogy miért sikeres a telepítés a webes felületről, tehát az megoldotta ezt a problémát, vagy figyelmen kívül hagyta, tehát nem tökéletes telepítést engedett? Mert nem volt hibaüzenet és most sincs a Jelentések részen.

Természetesen a Composer-es megoldásokat fogom használni a kényelmes és adott webes lehetőségek helyett... (no comment), csak az azért érdekelne, hogy most akkor a Webes felületen lévő Bővítés felület sz-rt sem ér, mert nem jelzi a hibát ezek szerint és nem teszi fel a függőségeket? De ha így van, akkor minek a Bővítés felület? Akkor el kell venni és meg kell mondani, hogy gyerekek, aki Drupal-t akar használni, az használja a parancssort, mert ez így olyan, hogy ott van, de ne használd...

És vajon, ha az a cél, hogy a Drupal közelebb kerüljön a WP népszerűségéhez, akkor jó irány-e, hogy a parancsorra akarja vinni a felhasználókat alap dolgokban is, ha hibátlan megoldást akarnak, mert technikailag nyilván megoldható lenne, hogy a webes felület is egy Composer parancsot futtasson le (igen, ahhoz parancssoros hozzáférés kell, de nem root, és mivel https-es (SSL) a Drupal honlap is jó esetben, a biztonsági része nem különbözik a terminálos SSL-es hozzáférés biztonságától). Elvileg.

Ui. Elkezdtem már korábban ismerkedni az ajánlott Rules alternatívával (de még csak 4 ezren használják, szemben a Rules 116 ezrével), de amikor megláttam, hogy a Rules-ból megjelent végleges verzió 10-esre is, megörültem, aztán láttam, hogy ott elfelejtettek szólni a modul oldalán, hogy pl. nincs benne a Scheduler, stb.

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

0
0
Balu Ertl képe

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

1
0
druid képe

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

Egy végleges verziójú modul esetén előfordulhat ilyen? Tehát a Drupal.org-ról letölthető, biztonságosnak, ellenőrzöttnek mutatott modul esetében lehet olyan, ahol nem a Drupal elvárásainak megfelelően kialakított modul kerül közlésre? Ha igen, akkor minek a zöld háttérszín, a pajzs, azaz az ellenőrzöttség, megfelelőség jelölése a modulok oldalán?

állítólag Slack-en nagyobb az élet, nem tudom

Talán tavaly, amikor itt szó volt arról, hogy ez a fórum már nem megy, meg a Drupal.hu, akkor felmentem a Slack-ra, de nem igazán sikerült átlátnom azt a felületet és amit ott írtam, arra azóta sem érkezett válasz, aztán, ha jól rémlik te írtál itt úgy fél éve, hogy ismét beindul ez a fórum, de úgy tűnik mégse. Lehet, mindenki megtanult angolul és a Drupal.org fórumain beszélget. Vagy, annyira lecsökkent a Drupal népszerűsége, hogy ez a magyar fórumon ennyire látszik.
Próbáltam a WP-t, de egyrészt azt olvastam róla, hogy pl. csoportkezelésre, jogosultságkezelésre, sok felhasználós honlapra nem igazán jó és a felülete is idegen, bár sok szempontból kényelmesebb (pl. modul keresés a honlapról elérhető, nem kell mint itt a Drupal.org-ra rámenni), de valamiért - ez lehet tévedés - olyan érzésem van, mintha a WP gagyi lenne a Drupal.hoz képest. Sajnos a Drupal viszont a nagyképű programozók terepe, úgy látom itt sok régi hozzászóló esetében.

0
0
Balu Ertl képe

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

0
0
druid képe

Megnéztem a hivatkozott témákat amiket küldtél itt és meglepő - nem akarom magam fényezni, tényleg - hogy alig egy hete használom a D10 és Composer párost és máris felvetődött bennem, hogy ugyan miért nem eleve ezt a módszert használja a webes frissítési felület. Gondolom már sok éve felmerült ez, csak még nem valósult meg, nem gondolom, hogy csak most jutott eszébe másoknak.

Amit a modulok megbízhatóságáról írsz az viszont megdöbbentett, tehát akkor semmi értelme a megbízható modul jelölésnek.
Azt gondoltam, hogy a folyamat vagy úgy megy, hogy valaki beküld egy modult és egy csapat végignézi a kódot, majd utána kerül oda a zöld szín és a pajzs, vagy hogy annyira megszabott a modulok fejlesztésének mikéntje, hogy eleve van egy keretrendszer, ami nem is engedi, hogy problémák legyen, vagy egy program átvizsgálja a kódot.

Ezek után nehéz azt gondolnom, hogy a Drupal a legprofibb CMS és már azt is értem, miért van annyi utólag kiderült biztonsági rés a világ összes webes és egyéb alkalmazásában...

Remélem nem a mesterséges intelligenciának nevezett szarságra fogják rábízni ezeket a feladatokat, mert abban még annyira sem lehet bízni, mint az emberekben.

UI. Van egy elképzelésem, hogyan lehetne felvirágoztatni a Drupal.hu oldalt, vagy akár egy másikat csinálni, úgy, hogy az anyagilag is megérje. Ha érdekel, valamikor megírom és akár összehozhatnánk...

0
0
Balu Ertl képe

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

1
0