Drupal 10 fejlesztői téma

druid képe

Üdv!

Drupal 7-esnél a Zen témát használtam alapként, azonban 10-eshez nincsen.
Néztem a 10-15 legtöbbet használt Drupal 10-es témát, az Adminimal-ról nem egyértelmű, hogy az egy fejlesztői alaptéma-e, vagy az csak adminisztrációs téma.
Van több Bootstrap féle, de telepítve nem egy legalább átlagosan jól kinéző felületet ad, hanem úgy néz ki az oldal tőle, mintha nem lenne megcsinálva a formázás.
Amúgy nem is akarok Bootstrap-os oldalt, mert szeretem magam csinálni a CSS-t, nem függeni semmitől.

Fórum: 
Drupal verzió: 
Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
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

Devel modul átírja az admin email domain-jét?

druid képe

Üdv!

Telepítettem a Devel modult, utána valami furcsaság történt.

Például az admin email címének domainje gmail.com domainról, example.com-ra változott. Ez hogyan lehetséges és miért?

Másrészt átváltott a felület angolra, amit ha visszaváltottam magyarra, mindaddig megmaradt, amíg az admin fiókjának szerkesztésére nem mentem, akkor visszaváltott angolra, de csak, ha az admin fiókjára mentem.

Azért telepítettem, hogy mélyebben bele tudjak nézni dolgokba, nem azért, hogy létező dolgokat elrontson.

Drupal verzió: 
Melyik modulhoz, modulokhoz kapcsolódik a téma?: