Balu Ertl képe

Beküldte Balu Ertl - 2024. szeptember 28. 16.05

„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

Beküldte druid - 2024. szeptember 28. 16.55

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

Beküldte Balu Ertl - 2024. szeptember 29. 10.37

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

Beküldte druid - 2024. szeptember 29. 15.40

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

Beküldte Balu Ertl - 2024. szeptember 29. 17.25

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

Beküldte druid - 2024. szeptember 29. 18.32

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

Beküldte Balu Ertl - 2024. szeptember 29. 22.29

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

Beküldte druid - 2024. október 22. 21.40
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.

Fórum: 
Modulok használata
Drupal verzió: 
10.x
Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
devel
configuration-manager
Balu Ertl képe

Beküldte Balu Ertl - 2024. október 29. 09.18

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.

0
0
druid képe

Beküldte druid - 2024. október 31. 19.56

Nem támogatom a magyar nyelv rombolását, szóval maradjunk az export szónál, az legalább egyértelműen angol szó, a "ki" igekötő sem kell elé.

Ami a lényeget illeti: újratettem mindent, és nem tettem fel a Devel-t, mivel még csak tesztelem a D10-et és az ECA-t. Szeretném elhagyni a Drupal 7-est, de ez elég nagy munka lesz, főleg, mire az egész honlapot újracsinálom, mivel nem bízok semmiféle migrate megoldásban.

Leírnám ide a tapasztalatokat, hogy mások is okuljanak, de látom ez az oldal halott.

Írod a Configuration Manager használatát. Azt csináltam vele, hogy időnként exportálom az adott állapotot, és ha valami elromlik, akkor importálom a korábbit, a Devel-en kívül még ez lehet, ezek szerint nem lehet megbízhatóan használni, ahogy korábban a Feature modult se. A Backup and Mugrate modul meg úgy szar, ahogy van, azt is sikerült elkúrniuk.

Pedig jó lenne, ha a Configuration Manager jó lenne arra, hogy visszatérjek egy korábbi állapotra (ami a tartalmakat érintetlenül hagyja, tudom, bár ebből is lehetnek problémák, mert ha egy későbbi tartalom alól kiszedjük az adott modult, amivel készült, mármint a korábbi állapotra visszatérés miatt, akkor gondolom a tartalmak ott maradnak az adatbázisban, de már sosem lehet kezelni azokat, csak szemétként maradnak ott...).

A Drupal org-ra tettem fel pár hibajelzést egyes modulokkal kapcsolatban, kérdeztem a Drupal Answers-en, de elég körülményesek ott az adminok.

A Slack oldalt meg egyszerűen nem értem. Regeltem, de hiába kattintok az adott linkre, semmi. Az egész olyan, mintha egyszerre rúgnák ki a régi Drupal-osok lábait, a múltat végképp eltörölni jegyében.

Amúgy már az is eléggé kiakasztó, hogy ha valami kis hiba történik, pl. egy rosszul megadott ECA szabály, vagy más modulnál valami, akkor elszáll az egész honlap a

The website encountered an unexpected error. Try again later.

hibaüzenettel, és adott esetben részletesen ki is ír olyan infókat, útvonalakat a Drupal, ami nagyon kényes. A biztonsági dolgokat itt kéne kezdeni, hogy ne írjon ki ilyeneket a honlap, csak az admin számára, alapból.
Nem is értem, ezt hogy gondolják a Drupal fejlesztői...

0
0