gyermekbetegség
Azt hiszem általános jelenség a Drupallal ismerkedők körében, hogy először, mint gyerek az édességboltban, minden modult ki akarnak próbálni; aki meg ismeri a PHP-t az minden piszlicsáré feladatra saját modult akar írni.
Aztán az első komolyabb verzióváltáskor az ember sűrű szitkozódások között megfogadja, hogy ezentúl legfeljebb 2 – na jó, 3, de legfeljebb 4 – kiegészítő modult fog installálni, különben törjön le a keze. Nálam a 4.6-ról 4.7-re frissítéskor jött el ez a pillanat, azóta szinte mindenre Views+CCK-t használok, képgalériától az üzleti nyilvántartásig. 5.1-re 10 perc alatt frissítettem gond nélkül.
Ha tényleg semmi más nincs azon az oldalon, csak a koncertek adatai, és havonta 1 millióan látogatják, akkor lehet, hogy megéri egy testreszabott, karcsúsított modul, egyébként nem nagyon. Nem csak megírni kell, de karbantartani is... Mondjuk tanulásra nagyon jó a feladat.
A fejlesztőeszköz örökzöld téma a Weblabor portálon. Windows alatt ilyen kisebb munkákhoz a "Notepad++"-t találtam a leggyorsabbnak.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
én is
Én is szerettem a Moodle-t évekkel ezelőtt, mikor dolgoztam vele. Gondolom azóta csak javult. Nem azt mondtam, hogy nem jó. Csak a hozzászóló azt sugallta, talán nem is szándékoltan, hogy egy ilyen iskolai rendszert Drupalban csak összetákolni lehet. Gyakran hallani ilyen hangokat olyanoktól, akik nem ismerik a Drupalt kellő mélységben, és felületesen alkotnak véleményt. Ezért éreztem úgy, hogy világossá kellene tenni: nagyon szépen meg tudja oldani ezt az iskolai rendszert Drupallal az, aki ért hozzá.
Én mindkét rendszert csak ajánlani tudom.
OK, de a kérdés az volt, hogy akkor mégis melyik legyen. :) Szerintem ha egyikhez sem ért, és komolyan gondolja a dolgot (nem valami instant megoldást keres, ami 10 perc alatt feldobható, és úgy-ahogy megfelel az igényeknek), akkor a Drupal jobb befektetés. Szubjektíve, a fejlesztő szempontjából jobban megéri Drupal-tanulásba fektetni az időt. Ennek nincs köze ahhoz, hogy melyik rendszer a "jobb". Mindkettő alkalmas az iskolai feladatra, és a Drupal még sok minden másra is. (A Moodle-t is lehet hajlítgatni, de jóval nehezebben. Nem hajlítgatásra tervezték, hanem oktatási célokra.)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Mea culpa: nagyon elírtam valamit
Igazad van, nem az levélbeni értesítésről szól a változó, hanam az inaktív modulok frissítésének vagy a frissítés mellőzésének figyeléséről. Egy kicsit fáradt vagyok val'szeg, mert ettől föggetlenül pontosan tudtam, hogy mit csinál ez a dolog.
A Drush "dl" és az "up" között pedig szerintem biztos van valami különbség bizonyos esetekben, bár ennyire nem vágom ezt a dolgot. Ha egy mód van rá, akkor inkább ragaszkodnék az "up" használatához. Amikor le kell tölteni valami új modult akkor a "dl", amikor frissíteni kell egy már meglévő modult, akkor az "up" parancsokat használom. Ilyen egyszerű vagyok én is... :D
Nem tudom pontosan megmondani, hogy ez most miért jobb, de pl. amikor klikkelgetve intéztem anno az ehhez hasonló ügyeket a weblapon, akkor is kerültem valamiért a "nyers" SFTP-n keresztül történő modul frissítést vagy manipulálást. Csak egyszer kellett így hozzányulnom egy modulhoz, akkor sem szivesen tettem valamiért.
Pont azért kérdeztelek meg, hogy mit tennél a helyemben, ha a Drush update nem talál egy létező új modul verziót.
Amúgy jó, hogy írsz, mert így legalább lehetőségem van mások workflow-ját megismerni, ebből tudok tanulni + a hiba megoldásán keresztül.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Szoktam olvasni fórumot...remélem olvassa valaki ezt is
tamoca
köszönöm a két linket.
Mielőtt írsz és ha nem érted a problémát legalább ne baltázz le.
Amiket küldtél az a tartalom beküldése okán fordul elő amikor nincs regisztrációhoz kötve a tartalom beküldése.
NÁLAM NEM IS TUDSZ BEKÜLDENI TARTALMAT. SEHOGYAN SE.CSAK ÉN KÜLDÖK BE TARTALMAT.
a PROBLÉMA A KÖVETKEZŐ:
kattints rá a felhasználó létrehozása menüre.
Majd mikor kitöltöd a felhasználói adataidat , és beílleszted a már kitörölt fent említett szemeteket, akkor azok szépen elkezdenek dolgozni.
Na ezt én nem tartom megfelelőnek, hogy ez lehetséges.
Hogy pontosan értsd:4.7.3.verzió,
adminisztráció
beállítások
profilok
itt ha létrehozol egy szövegbeviteli mezőt ahol bekérsz valami adatot a frissen regisztrálótól, pl cím, vagy a rendes neve, vagy cége neve, szóval egy űrlapod van ahool van sima szöveg beírási lehetőség.
Ha a regisztráló új felhasználó ide beteszi a "szemetét" akkor vége az oldalnak spam ágyú lesz belőle. Én így jártam ahogy észleltem azonnal feltettem. Aki olvasta az remélem tesz ellene ne járjon így.
A kérdés mit lehet tenni.
1. megoldás én jelenleg kikapcsoltam az elfogadás nélküli regisztrációt.
Ez nem jó mert bár a probléma megoldva, de nem akarok a gép előtt ülni és engedélyezni egyfolytában a felhasználók regisztrációját.Lehet ki se várják, vissza se jönnek az oldalra.
Megkérek mindenkit aki erre a levélre ír megfelelő megoldást, megfelelő hangnemben azt megköszönöm, és elég sok embert érinthet. Ha valaki élvezkedik a másik leba...án az inkább ne írjon, mert még válaszolok.
P.S.: a MÚLTKOR írtam , hogy az egyik oldalon elvesztettem a jogaimat, beenged az oldal de aztán jogosultság hiányában kidob. Senki nem válaszolt rá semmit, most olvasom a biztonsági hibát.
a VÉLEMÉNYEM A KÖVETKEZŐ.
Ha a settings.php-ből lazán kiolvashatja a felhasználó nevemet, az adatbázis nevét, a jelszavamat akkor az véresen , brutálisan nagy balhé. Nem akkora mint ez a spamágyú, de marhanagy. KB EGY HÓNAP MÚLVA jelent meg a címlapon a frissítésre való felhívás. Ha nem írok akkor a drupálon röhöghetne a világ.
Ha valaki egyszerű ember feltesz egy drupált és csinál egy regisztrációs űrlapot és semmilyen modult az alapokon kívűl nem tesz fel, akkor azzal így ki lehet szúrni az szerintem igen nagy baj!!!!!!!!!!!!!!!!!!!
És hogy ezt megírtam azért páran le... sztak hát kibírom.
tamoca
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Ki lenne a célközönség?
Már tegnap agyaltam rajta, de az előttem szólók hozzászólásai is bebizonyították számomra, hogy el kellene dönteni, hogy kinek a számára készül a kézikönyv.
Véleményem szerint, Gusztáv nem a portálépítők számára kívánt kézikönyvet készíteni, hanem azok számára, akik egyszerűen csak használni szeretnék a már beállított, működő portált, vagyis szeretnének cikkeket, híreket, képeket, … feltölteni, fórumozni, stb. A célközönségként tehát én azok számára készítenék kézikönyvet, akik már régóta használják a netet, nézelődnek, szörfölgetnek, de interaktív közösségi oldalt még nem használtak, viszont szeretnének.
A gond csak az, hogy ez a célközönség is nagyon különböző. Lehet ő egy informatikai vénával megáldott főiskolás, aki egy közösségi oldal felhasználója, de lehet egy falusi polgármester, aki szeretne híreket feltölteni a község honlapjára. Gondolom világos, hogy mindkét felhasználó számára más úton kell átadni azt a tudást, ami a portál használatához kell. Márpedig e tudás - minél szélesebb réteg számára való - átadására fel kellene készülni.
A konstruktív pedagógia a tanulást egy építési folyamatként értelmezi, tehát a tudást nem a tanító adja át a tanulónak, hanem azt a tanuló egy folyamat során építi fel magában. Ami még nagyon fontos ebben a tanulásfelfogásban az az úgynevezett. megelőző tudás, mert mindenki tart valahol a tudásépítés folyamatában. Ez adja a fő különbséget a főiskolás és a falusi polgármester közt.
A tanulási folyamatot úgy lehet elképzelni, hogy a tanulás kezdetén a tanulót a tevékenység elkezdéséhez szükséges (és nem több) ismerettel kell ellátni. A tevékenység során a tanulónak előbb, vagy utóbb igénye mutatkozik az addig végzettnél fejlettebb tevékenység elvégzésére. Ez az ismert, „azt hogyan lehet, …” kezdető kérdés. Tehát a következő „tudáselemet” ekkor kell a rendelkezésére bocsátani. Aztán az azzal való munka során majd újabb igénye lesz a még további tudás megszerzésére.
A dolgot természetesen tovább bonyolítja, hogy a tanuló egyének nem mindig ugyanabban az időpontban, és nem mindig ugyanabba az irányba szeretnének továbbhaladni.
Ami javaslok, az egy olyan felépítésű kézikönyv, ami - egy közösen megállapított minimum szintről indulva - támogatja a tudásépítő folyamatot. Ehhez a minimum szinthez „belőve” lehetne készíteni, egy minimál indító „kézikönyvmagot”, aztán a további tudás megszerzéséhez már csak olyan - fél, egy oldalas - ismertetőket kell összerakni, amik a közben felmerülő továbbhaladási igényekre ad választ. Mindezt természetesen egy jól strukturált, könnyen kezelhető, gyorsan áttekinthető formában képzelem el.
Nem ígérem azonnalra, de egy ilyen mag és néhány modul vázlatát a napokban összerakom, az anyagot a hét végén PP-vel való borozgatás közben átbeszéljük aztán küldöm az elképzelést.
Erre a vázra első körben rá lehetne építeni a Gusztáv által megírt bevezetőt.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
újra
"Most kóstolgatsz minket és teszteled, hogy milyen problémákra tudunk megoldást, vagy tényleg érdekel is? nahmindegy.."
Volna jobb dolgom is, mint kérdéseket feltenni a fórumon, nyilván azért kérdezem, mert érdekel a megoldás és mert igen sok ideje nem bírok rájönni drupal.org+drupal.hu+google+próbálkozás módszerrel. Azóta sem sikerült megoldani a kérdést és kezd egyre égetőbbé válni.
többszörös választás: ismerem, használom, kevés. Szabad szavas: nem jó megoldás a konkrét problémára, részletezhetem miért, de a lényeg nem ez.
Fontos, hogy egy képnek több kategóriába is bele kell tartoznia.
Arra jutottam, hogy a problémám szerintem két módon lehetne megoldani.
1., az image modul telepítésekor létrehoz egy image node típust. Legjobb lenne ha ezt lehetne klónozni, és más tartalomtípusnak minősülne az egyik fajta fotó mint egy másik fajta fotó. Akkor teljesen más taxonómiarendszert tudnék rájuk alkalmazni. Vajon lehet ilyet csinálni az image típussal (vagy más, nem felhasználó által definiált node típussal)? (nekem nem sikerült)
2., Feltételes függőség szótárak közt: attól függően, hogy egy szótár melyik kifejezését alkalmaztam első lépésként egy képre, attól függően kelljen bekategorizálni más szótárakba.
Pl (kicsit más mint az eddigi példa) első kategória: a képen kutya vagy macska vagy ház van. Ez egy szótár három kifejezése melyből csak az egyiket tudja választani az user. Ha kutyát választott akkor kelljen bekategorizálni a kutyafajták szótárba (tacskó, puli, stb) és a nem (hím/nőstény) szótárba. Ha macskát akkor kelljen bekategorizálni a macskafajták szótárba és a nem (hím/nőstény) szótárba. A nem (hím/nőstény) szótár egy és ugyanaz a szótár kell legyen, mindkettő állatfajta esetében, az nem jó, ha két külön szótárat létrehozok a macskán belül és a kutyán belül és beleteszem ugyanazokat a (hím/nőstény) kifejezéseket.
Ezen kívül fontos hogy a kutyafajták ne is jelenjenek meg akkor ha az első kategóriában a macska típust választotta az user vagy fordítva. (ajax?)
Ha házat választott akkor a nem (hím/nőstény) kategóriának sem kell megjelennie, akkor teljesen más szótárakba kell besorolni.
Ráadásul a többszörös választás lehetőségének minden esetben fenn kellene maradnia. Beteg példa, de pl keverék kutya esetén lehessen bepipálni egyszerre két, szótárban szereplő fajtiszta kutyafajtát aminek a keverékeként létrejött a képen látható kutya.
Most itt 2-3 kategóriával és kifejezéssel példázok, de valójában sok-sok kategória van; ha azt leírnám, már érthetetlen lenne. Ha a fenti dolgora megoldást találunk, akkor az alapján már meg tudnám csinálni az én konkrét esetemen.
Nagyon próbáltam értelmesen leírni, remélem már látható, hogy mi az én bajom :S
Köszönöm előre is annak, aki végiggondolja a problémát, és javaslatot ad.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Keresőoptimalizálás, tesztlabor
Azt gondolom ez a sitemap beküldés, ennek a mikéntje, a fontossági szerepe, az álnevek és az ehhez kapcsolódó modulok megérnének egy komolyabb kutatást aztán pedig egy elbeszélgetést.
Sajnos én nem tudtam róla, hogy nem egészséges dolog a sitemap használata, sőt pont az ellenkezőjével találkoztam. Ha erről előbb hallok valszeg bele sem kezdek a modul használatába. Ezeknek a keresőkhöz kapcsolódó moduloknak a használata, hogy úgy mondjam szó szerint húsba vágó téma, mert szoros összefüggésben van a pénztárcával. Az oldalam az első 10-ben volt, most sehol sincs, vagyis kezdhetek beizzítani egy addwords kampányt. Ez bizonyos részben felróható az én butaságomnak, a körültekintés hiányának. Mentségemre annyit tudok felhozni, hogy nem igazán találni a témában a Drupallal összefüggésbe hozható és mérvadó anyagokat, amiket követni lehetne. Pedig a Drupal egy terített asztal amihez minden adva van, remekül használható. Ha viszont nem egy portfoliót szeretnénk bemutatni, hanem pénz termelésre akarjuk használni akkor szükség volna a fennebb említett infokra. Egy ilyen speciálisan a Drupalra kihegyezett “elbeszélgetés” aranyat érne azok számára akik a vállalkozásukat építik egy Drupalra épített oldalra.
Beszélgettem olyan emberekkel akik kereső optimalizálással foglalkoznak. Nagy részük el tudja mondani mit kellene tennem, de ők maguk nem tudják végrehajtani a szükséges változtatásokat mert nem értenek a Drupalhoz. Rá vannak állva a saját fejlesztésekre és nem akarnak felelősséget vállalni azért, hogy esetleg a munkájuk eredményeként visszaesik az oldal a keresőkben. Arról pedig, hogy ezt a kétes kimenetelű tevékenységüket mennyiért csinálnák már ne is beszéljünk :)
Szóval bizonyára vannak tapasztalatok ezeknek a moduloknak a használatával kapcsolatban amiket jó volna ha megosztanánk. Azt is el tudnám képzelni, hogy csinálunk egy esettanulmányt. Létre hozhatnánk egy oldalt egy tetszőleges tartalommal amit megpróbálunk bejuttatni az első három találat közé. Szigorúan csak a drupal adta lehetőségekkel élve. Az így szerzett tapasztalatok, sikerek és kudarcok nem csak feltételezések, innen-onnan összeszedett infók lennének, hanem tényleges eredmény, vagy eredménytelenség.
A Drupalt eleinte mindenki meg szeretné ismerni. De a megismerés után jön a használhatóság, ami alatt nem a felhasználóbarát környezetet értem.
Szerveremen szívesen helyt adok egy ilyen kezdeményezésnek. Talán egy szavazással itt a Drupal.hu-n mérhető lenne, van e igény rá.
Persze az is lehet, hogy ezen tudásukat az érdekeltek nem szívesen osztják meg, ez ellen nem tudunk mit tenni.
az adatbázisban a sitemap modult a pathauto utánra súlyozod
ezt nem értem, nem csunáltam még ilyet :) megtennéd, ha van időd, hogy leírod kicsit másképp? :)
-------------------------------------------------
... értem értem hogy gőzzel megy! De mi hajcsa????
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Get Locations VAGY OpenLayers ajánlott
Nálam a Get Locations nagyon jól bevált! Képes arra, amiket írtam az ezelőtti hsz.-ben! Nagyon jó a Views-támogatottsága (azt leszámítva, hogy a preview-t nem képes sajna megjeleníteni térképen, amikor állítgatsz a Views-felületen, tehát ahhoz, hogy lásd a várható végeredményt, muszáj az adott page-re menned, ahol látható a nézet - de ezzel együtt lehet azért élni, nem vészes, max. új tabot nyitsz ahhoz az ominózus oldalhoz; persze picit kényelmetlen, mert mindig menteni is kell a view-t), szerteágazó beállítási lehetőségei vannak, nagyon szépen működik a node edit oldalon az autocomplete a Google Maps API-n keresztül (pl. bepötyögsz egy címet, egyből felkínálja a lehetőségeket, ahogy a maps.google.com-on is), ha a felajánlott lehetőségek közül választasz, egyből bejelöli a térképen. Azt is sikerült beállítani, hogy alapértelmezettként mindig Magyarországra kerüljön a zoom, mert most nekem hazai helyek bejelölése volt az elsődleges - ezt úgy kell, hogy az adott field beállításainál, az "Input form Map center" mezőbe mondjuk ilyesmi koordinátákat írsz, nálam ez van: 47.5073,19.0421 (így, ebben a formában), aztán a "The default zoom level of a Google map." részt 8-as szintre állítottam.
Az is tetszetős, hogy nagyon könnyű hozzá egyedi markert írni, nagyjából 10 percet töltöttem el max. a dolog tanulmányozásával, és máris a saját markereimet tudtam használni a térképhez. Külön markert lehet választani a node edit oldalhoz, és külön markert a megjelenítéshez a "Manage display" oldalon!
Elég igényes modul, én csak ajánlani tudom eddigi tapasztalataim alapján.
Annyiból érzékeny, hogy modulok frissítésekor, meg hasonló események idején van, hogy a markerek megzavarodnak, ilyenkor a markers library-t újra kell építeni, hogy az elérési utak helyreálljanak (ez leginkább alkönyvtár használata esetén érdekes), az admin/config/services/getlocations oldalon, a "Regenerate" gombra kattintva, de kb. ennyi igazán zavaró dolgot vettem észre.
(Volt, hogy ColorBoxban jelenítettem meg, a sidebarokat levéve: http://drupal.hu/forum/t%C3%A9rk%C3%A9p-megjelen%C3%ADt%C3%A9se-colorbox....)
Ha viszont komplexebb, egyedibb megoldás kell, akkor lehet, hogy az OpenLayers-re lesz szükséged, mint ebben az esetben: http://drupal.hu/comment/67026#comment-67026.
Mindkettő jó lehet.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
fék, idealizmus és opcionalitás
Fék az nem ugyanaz, mint a visszafogó. A fék lassabb sebességre asszociál, míg a visszafogónak éppen az a célja, hogy lehetőleg azonos kiszolgálási sebességet biztosítson nagyobb terhelés esetén, úgy, hogy a terhelést feleslegesen növelő dolgokat kapcsolja ki. Tehát a ballasztoktól szabadítja meg a rendszert (amik normál működésnél aranyos plusz funkciók). Éppen az a célja, hogy ne következzen be lefékeződés. Tehát nem a sebességet csökkenti, hanem a Drupal 'lelkesedését' fogja vissza. Ha most megszemélyesítenénk, akkor magyarabbul fogalmazva azt mondhatnánk, hogy visszafogottá teszi a Drupalt.
Azért célszerű a 'megadható' nem szükségességének jobb hangsúlyozása, mert emberek összevissza mindenfélét elkezdenek kitölteni, ha egy felületen űrlap elemeket látnak. Teljesen egyértelműnek kell lennie számukra, hogy nem szükséges valamit kitölteni.
Ami az egységesítést illeti, az nagyon szép koncepció, csak sajnos nem fog megvalósulni. Lásd például a két népszerű böngésző könyvjelző (bookmark) és kedvenc (favourite) elnevezését. A különböző tartalomkezelőkben teljesen más funkcionalitások vannak. A visszafogóhoz hasonló dolgokat ritkán látni, ugyanakkor egy csomó fontos dolgot találsz más rendszerekben, ami itt nincs. Emellett maguknak a funkcióknak is teljesen más a megvalósítása.
Lehet, hogy nyomdai analógiákat keresel, de zsákutcába mész. Ha egy cég honlapjáról beszélünk, akkor annak szinonímájaként használjuk a cég weboldalát (sőt, webhelyét is), annak ellenére, hogy az oldal az a lapnak csak egyik oldala, ha könyvekről gondolkodunk. Használhattuk volna az írás helyett a publicisztika szót például, mint egy lehetséges alternatívát, hogy a konkrét papíron megjelenő betűk materializálódásának lehetséges analógiáját elkerüljük, de egyrészt ez nem lett volna magyarosabb, másrészt nem fejezte volna ki, hogy miről van szó. Bármilyen szöveg közzétételére fel tudod használni ezt a típust. Lehet, hogy neked tetszene, ha most megegyeznénk, hogy mondjuk csak híreket publikálhatsz vele, és boldog lennél ezzel, de akinek több kell, az igencsak ellenezné...
Különben a könyv az itt egy tetszőleges hierarchiát követhet (miért kellene megkötni bárki kezét?), és valóban kerülhetnek bele oldalak, írások és könyv lapok is, úgy hogy ezutóbbi három tartalomkezelési szempontból egy szinten van. Az oldal ezesetben 'weboldal'-ra utal, de így nem lehet nevezni, hiszen minden weboldal lesz, amit a Drupal generál. A könyv lap pedig a könyvbe tervezett, oda szánt funkcionalitást jelzi. Elnevezhetjük teljesen másnak is ezeket, de ez sem a többi rendszerrel való konzisztenciát nem fogja javítani, sem a való világgal való kapcsolatot – legalábbis eddig még nem érkezett használható javaslat. Én örülnék, ha meglepné a fordítókat ilyen korszakalkotó konkrét javaslatokkal valaki.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Felemás
A prooktatas tanfolyama viszonylag olcsó, de nem is ad sokat. Elég alapszintű tanfolyamnak tűnik. Ez nem azt jelenti, hogy rossz csak kevés kicsit. Ráadásul az egyetemeknél a Pannon egyetemet említik, ami speciel éppen Joomla-t használ :D.
Az euzert képzésének leírása jobb. Az ér sajnos nincs feltüntetve. Érdekes viszont, hogy itt és a másik helyen is 48 óra a képzés ideje. Ezért kérdéses, hogy mennyivel mennek bele jobban a részletekbe.
Igazából a modulok fejlesztéséről egyik helyen sem tesznek említést. Így akiket ez a vonal érdekel lehet csalódni fognak. Ugyanakkor szerintem érdemes kérdést feltenni, hogy van-e lehetőség ilyen irányú képzésre is.
Amit hozzátennék, hogy a html, css, javascript ismerete és a php, sql részleges is szükséges. Akinek nincs ilyen ismerete az olvasson át pár könyvet, ha jelentkezik a képzésekre.
A sminkelést elvileg rendesen oktatják. A második esetben erre utalás is van. A modulfejlesztés rejtelmei viszont, -mint írtam feljebb -egyik helyen sem szerepelnek.
Úgy érzem a kérdést feltevő érdeklődőnk a modulfejlesztés iránt is érdeklődne. (Igaz ez esetben drupal 8 esetén az objektumorientált php programozás ismerete is szükséges.) Szóval valahol az előző kettő és a Cheppers képzése közötti megoldást keres.