A probléma a GDPR megfogalmazásának lazasága
Igazából a helyi hatóság kezébe olyan hatalmat ad, amely alapján mondhatni szinte azt büntetnek meg, akit akarnak.
Több olyan pont is akad, amely nem elég konkrét, vagy nem veszi figyelembe a rendszerek működését, összetettségét, megosztottságát.
Az egyik kérdés a sütik használata. Ha jól értelmezem, akkor, míg tevőlegesen nem engedélyezi a sütiket a látogató -vagyis nem kattint az engedélyező gombra, vagy pilpálja ki a négyzetet -addig az oldal nem is használhat sütiket. Igen ám, de sok beépülő modul, mint egy facebook, vagy google szolgáltatások azonnal használnak sütiket. Ugyanakkor, ha jól értelmezem a szöveget, akkor az oldal látogathatósága nem tagadható meg a süti használatot nem engedélyezők számára sem.
Véleményem szerint ezt a funkciót inkább a böngészőkbe kellene applikálni, mint az oldalakba.
Aztán mindenki kötelessége ezek után a hatóság értesítése, ha az oldalát feltörik, vagy, ha a szolgáltató rendszerét feltörve férhetnek hozzá az oldalához. Láttunk erre példát korábban az egyik szolgáltatónál.
Egy átlag magán ember részére minden jogi csűrcsavar követése nem is olyan egyszerű.
Ami biztos, hogy minden személyes adatot bekérő űrlapra ki kell tenni egy beleegyező rubrikát és elérhetővé kell mellette tenni az oldal adott részére vonatkozó adatvédelmi szabályozásról szóló tájékoztatót.
Ez a minimum. Jelzem a drupal.hu sem felel meg a GDPR elvárásainak!
Sem hírlevélre, sem más hasonló dologra nem lehet automatikusan feliratkozni, sőt közvetlenül ilyen ajánlattal sem kereshető meg a felhasználó. Mindig üres négyzetekre van szükség nem lehet előre bejelölni!
Külön beleegyező négyzet kell az ÁSZF-nek és az adatvédelmi szabályok elfogadásának.
Mindig csak a minimálisan szükséges adatot kell bekérni és azt is fel kell tüntetni, hogy mikor kerülnek törlésre, ha, már nincs rájuk szükség. Például egy vásárlásnál meg lehet határozni, hogy a bekért adatok csak a garanciaidő lejárta után törlődnek, de akkor törlődniük kell! Vagy mégsem?! Nos azoknak az adatoknak, amelyeknek megőrzését törvény írja elő, akkor jelezni kell, hogy az xy törvény miatt a nav 5-6 év tárolási időt ír elő, de ebben az esetben az adatok titkosított tárolását is biztosítani kell...
Szóval sok-sok szabályozás és kevés konkrétum a pontos kivitelezésre.
Első körben azt javaslom tanulmányozzátok a nagyobb webáruházak ezen opcióit. Sok helyen, már előálltak különféle megoldásokkal. Támpontnak jó lehet ezek tanulmányozása.
Mindenképpen el kell kezdeni az oldalak legalább minimális átalakítását, mert az új szabályozás szerint a kiszabható büntetés felső határa 20 millió euró is lehet, sőt az is megeshet, hogy ennél is több (az előző év világpiaci termelésének 4%-a -mindig a magasabb érték az irányadó).
Picit aggódom az első időszak miatt, de remélem a hivatalok igazságosan kezelik a dolgokat és emberségesen döntenek az esetleges problémás ügyekben. Remélhetőleg nem lesznek túl szigorúak, ha az oldalak a tőlük telhető legtöbbet megteszik a legjobb megfelelés érdekében, de valahol valamit elrontanak.
A GDPR is folyamatosan formálódik ezért is nehéz a tökéletes megfelelés. Biztos kell pár év mire minden területen kialakulnak a végleges szabályok és megvalósítási megoldások.
A tengerentúli szolgáltatások európai oldalakba történő integrálása is egy érdekes terület. Gondolom a nagyobb szolgáltatásoknál kevésbé lesz probléma.
Még egy nagyon fontos dolog!!!
Nem szabad hírlevélben, vagy bármilyen más formában direkt marketinget küldeni!!!
Ehhez egy plusz jelöletlen jelölőnégyzet kell! Tehát előfordulhat, hogy egy négyzet az ÁSZF, egy az adatkezelési hozzájárulás és egy a marketing!!!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszi
Köszönöm a videót és a könyvet!
A videó néhány dologra úgy rávilágított azért amivel előbbre kerültem ugyan de nem teljesen világos hogy pontosan mit csinál az argumentum, ergo a működése kicsit még homályos de már nem tök sötét... :)
Találtam egy rövid leírást az argomentumról (ami hát nem tudom hogy egyenlő-e az argumentummal) mint kifejezésről egy lexikonban:
" Az argomentum nem más, mint a függvény bemenő adatai független változók, amivel számolni kell, vagy amit át kell alakítani a függvény jellegéből adódóan. "
(hát ez is azért elégé zavaros még így számomra)
És persze az ajánlott könyvben is ez szerepel:
"A nagy újdonság az eddig még nem ismertetett Argumentumok doboz. Ennek a segítségével további információt tudunk a nézethez rendelni. Enélkül nem csoportosítva, hanem listázva látnánk a tartalmakat."
Hát én megpróbálom megfogalmazni a gondolatokat a fejemben és kérlek titeket javítsatok ki ha valamit rosszul gondolok vagy látok.
Egy argumentum hozzáadásával egy nézetbe csoportosítani lehet a nézetet nem pedig felsorolni (kilistázni), pl a videóban is látott módon hogy az első képgalériába csak az első képgalériába tartozó képeket mutassa és ne mutassa a többit is meg benne. És ezt különböző módon el lehet érni (nem csak egy képgalériáról beszélve hanem bármi másról) úgy hogy az útvonalból szerezzen információt a views és aszerint módosítsa a nézet kimenetét. Tehát a videóra utalva megint... első képgaléria elérési útvonala a NODE-1 -> tehát az első argumentum aminek a száma 1 -> tehát az első képgaléria nézetét úgy módosítja hogy csak az abba tartozó és feltöltött képeket jeleníti csak meg... És ez ugyan így működik tovább a második galériánál is vagy ami még lenne de én ahogy látom jelenleg hogy ebben az a jó dolog hogy nem kell újra és újra és újra beállítani meg megadni minden paramétert hanem ez az argumentum segít nekünk "automatizálni" ezt a funkciót és a második képgalériához aminek az elérési útvonala NODE-2, csak az abba feltöltött képeket jeleníti meg. És ha lenne harmadik vagy még több és több képgaléria akkor mindet automatikus módon elrendez/csoportosítsa a views és az ő argumentum részlege (meg persze a többi paraméterezés)
Röviden talán összefoglalva ezt úgy tudnám hogy az argumentum egy kitétel hogy a megjeleníteni való elemek miknek feleljenek meg. Ergo egy szűrő...
Nem tudom hogy jól látom-e a működési elvét ennek? (mert mindig azt tartottam hogy ha valaminek a működését nem értem meg hogy hogyan működik akkor nem fogok tudni hozzányúlni belepiszkálni röviden nem is értek hozzá)
Egyébként azt is ahogy látom hogy vannak ilyen "tokens jellegű" rövidítések is amik használhatóak pl
%1 -> a ... CÍME amiben a szám az argumentum "sorszáma"
!1 -> a ... BEMENETE itt is szintén az argumentum sorszámát jelöli a szám de bemenet alatt mit kell itt pl érteni?
Ez a részleg egy bármilyen mező hozzáadásánál van a mező kimenetének felülírása részleg alján.
Köszönöm az eddigi segítségeket és az ez utáni segítségeket is. Ha rosszul látok valamit javítsatok ki egész nyugodtan :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Ezzel csak szívni lehet ;)
A web alapvetően állapot mentes kommonikáció, tehát a webszerver nem emlékszik arra, hogy melyik oldalakat kérte le a kliens. Bizonyos állapotokat meg lehet jegyezni, erre jó a munkamenet. Azonban a munkamenettel az a probléma ebben az esetben, hogy a munkamenet emberhez kapcsolódik, nem böngészőhöz. Amennyiben a júzer több bongészőt/böngésző lapot néz egyszerre ugyan arról az oldalról, akkor már is meg vagy lőve, és a munkamenetben tárolt változó, hogy honnan jött értelmetlen lesz. Megoldás az lehet számodra, hogy minden egyes a node-ra mutató linkbe beleteszed azt, hogy honnan érkezik majdan, és ettől függően más és más megjelenítést készítesz. Ezt talán a legegyszerűbben js-el teheted meg. (megkeresel minden linket és hozzáadod az aktuális oldal címét tartalmazó paramétert)
Ha ez túl bonyolult, akkor a $_SERVER['HTTP_REFERER'] változót kell figyelned, amiben nem mindig van benne az az érték, hogy honnan jött.
Szerintem érdemesebb lenne elgondolkodnod azon, hogy változtass ezen az elgondoláson. ;)
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Hellosztok! A szolgáltató
Hellosztok!
A szolgáltató nevében írok. Először a szolgáltató nem az 1b telekom kft, hanem az 1kb kft, de mindegy.
Második dolog pedig, az oldal látogatottságáról, hogy azt a képen is látható 45ös szerver loadot úgy sikerült elérnem , hogy egy firefox ablakban megnyitottam 6-8 példányban az 5x5 oldalt. Így egy stabilnak mondható 4-6 os szerver load felszaladt másfél perc alatt 50-re. Nem is azt modanám hogy konkrétan a drupállal lenne problémánk, mert számos drupálos oldal fut még a szerveren, egyikkel sincsen probléma. Szóval az, hogy megnyitom néhány példányban az oldalt, az nem tudom miért látszik meg egy 2 xeon processzoros hp szerver teljesítményén? Mellesleg memóriából is 5 giga van benne, amiből átlag 1 környékén használ a szerver, szóval abból vihet amennyit csak akar.
Jelenleg áttettük az oldalt egy üres gépre. Most a szerver 1,24es szerver loadot mutat.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
reglang modul
Tegnap óta annyit haladtam előre a témában, hogy találtam egy modult (registration language) - drupal.org/project/reglang.
Ennek az lenne elvileg a haszna, hogy ha a felhasználó bizonyos nyelvet választ a regisztráció során, akkor neki az oldal így fog mindig megjelenni. Először létrehoztam a felhasználót adminként, közben az alapból angol felületet magyarra állítva. Az eredmény semmi, vagyis amikor bejelentkeztem a felhasználóval, nem magyarul, hanem a difólt angol nyelven jelent meg az oldal. Utána engedélyeztem a látogatóknak a regisztrációt, majd így is felregisztráltam a felhasználómat (persze előtte kitöröltem), közben magyarra állítva a felületet. Ez se használt, utána, amikor bejelentkeztem a felhasználóval, épp úgy maradt minden angolban.
Most vagy nem csinál semmit a modul, vagy még az ötletem, hogy nem az kavarja-e be, hogy a difólt angol nyelvhez nincs megadva előtag (pl "en"), vagyis ha nincs /en a wwww.example.com után, ez az angol nyelv, lehet ez a gáz?
Kollányi Dániel
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
hook_noodapi
Szóval van ugye a modules/node mappán belül egy egy node.module fájl. Ennek van egy load,insert,delete függvénye, amiket én bővítettem, de ezt a három bővített függvényt egy külön modulba szeretném kitenni, hogy az illetőnek ne kelljen programozni az alap node.module fájlt, hanem modulként behozni.
Olvastam, hogy ehhez a külön modulba, amit én fejlesztetem ezt a függvényt kell használni
function hook_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
switch ($op) {
case 'load':
és így tovább, ahol a load jelenti ugye a beteöltést.
A gondom az, hogy nem ez fut le, hanem az alapdrupal rendszer szerinti node. module fájlnak a load függvénye és nem az amit én külön modulba megírtam, az előbb említett kód segítségével.
Röviden hogy kell ugy modult fejleszteni, hogy az én függvényeim éljenek, és ne az alaprendszerbeli
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A tárhellyel van a baj
Feltettem egy másik tárhelyre aldomainbe ugyan azt a tartalmat, és ott villámgyors!
A wget 2,7 sec alatt leszedte azt az oldalt, amivel a másik tárhelyen 62 másodpercig szenvedett.
Egy Speed Test oldalon összehasonlítottam a két tárhelyet, és ledöbbentem:
Az eredeti tárhelyen az átlagsebesség: 0,11 sec/KB
Az új tárhelyen az átlagsebesség: 0,03 sec/KB
A Load Time az eredetin: 2,85 sec
Az új tárhelyen: 0,69 sec
Így kiderült, hogy a bibi nem a views-al, a lekérdezéssel, vagyis egyáltalán nem a drupalban van, hanem a tárhely lassú valami miatt, és a legjobban ennél a nézetnél jött ki a lassúság, hogy azt hittem ezzel van baj.
Köszönöm a segítséget aborosnak és pp-nek, mert nagyon hasznos tanácsokat adtak!
Az oldalban még találtam optimalizálni való dolgokat a srácok által említettek alapján, így még fejleszteni fogom tovább, természetesen ;)
Írj rám, ha érdekel a Győri Drupal Használói Találkozó.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Egységesre törekedtünk
Egységesre törekedtünk korábban, az eltérés oka legtöbbször figyelmetlenség.
Az „elmentésre került” a fordítási segédletben is meg lett említve, mint negatív példa, indoklással. A másik 3 változat mindegyike helyes, egységesíteni nem szükséges, mert van olyan szövegkörnyezet, ahol az egyik vagy másik nagyon erőltetett lenne.
A domain és társai elég megosztó, jó látni, hogy a domain helyett a domén egyre elterjedtebb. A tartományt általában megkülönböztető jelleggel használtuk ott, ahol nem webről volt szó (lásd tartományvezérlő).
Az anonymous esetében a vendég szerintem távol áll a jelentéstől. A névtelen sem áll, mert neve attól még, hogy nem tudjuk, van neki. A nem azonosított felhasználó lenne a legjobb, a be nem jelentkezett felhasználó kicsit nyakatekert.
Az online usernél a bejelentkezett mellé felvenném az azonosítottat, ha az előbbinél a nem azonosított… volt az előnyös. A jelenlévő nem rossz, kérdés, hogy mennyire általánosítható. El tudok képzelni sok olyan mondatot, ahol furcsa lenne, mivel a jelenlévőhöz nekem a fizikai jelenlét társul.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A Computed field volt a megoldás
Gazsest prezije sokat segített a Commerce megértésében, de végül a Computed field modul volt a megoldás.
Az árak kiírásához computed mezőt kellett létrehozni, és itt a "Computed Code" beviteli mezőben az igény szerinti php scriptet kell írni. Az én esetemben kellett még egy árfolyam lekérdezést is csinálni, és ezt a php kiterjesztésű fájlt a szerverre feltölteni.
Tehát bejön az arany tőzsdei ára euróban, ez szorozva a grammal (tömeg field) és az árrés szorzóval (ár szorzó field). A kiírás pedig euróban és forintban történik. Fontos, hogy a "Store value in the database"-t ki kell kapcsolni!
Amit még szeretnék megoldani, hogy az összes terméket egy oldalon kilistázni (ez megvan), de úgy, hogy az árrés szorzóját(ár szorzó field) ezen az oldalon lehessen szerkeszteni, termékenként és a végén a lap alján menteni. Azaz ne kelljen egyesével megnyitni a termékek szerkesztését. Drupal-ban lehetséges ez?
Köszönöm!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszönöm! Egy másfél nap
Köszönöm! Egy másfél nap keresgélés után lassan látom a fényt az alagút végén!
Az a baj ezzel a témával kapcsolatban, hogy rengeteg megoldás, létezik rá de egyik sem az igazi. Én lehetőség szerint mindig az olyan megoldásokat keresem ami a legegyszerűbben megvalósítható és nem kell hozzá még 8 modul. Így pl. a fent említett notificationt nem javaslom.
Szóval a tapasztalataim:
A Rules modul önmagában kevés ehhez a művelethez (javítsatok ki ha tévedek) mivel a modul az alaprendszer különböző eseményeire van kihegyezve. Mást nem is nagyon tudok vele csinálni mint mondjuk küldök egy levelet, hogy most beléptem, most frissítettem egy tartalmat stb.. Tehát igazából kevés a token amit biztosít, a feltételekhez is nagyjából csak azt lehet megadni, hogy épp melyik felhasználó van bejelentkezve vagy melyik az aktuális oldal. Pl. csak a felhasználóknak lehet tömeges e-mailt küldeni, ami az én esetemben nem követelmény az ügyfeleim részére (ez csak egy nyílvántartás) róluk.
A megoldást a rules mellé a Views Rules modul jelentette, de nem volt egyszerű kitalálni hogyan működik.
Ha valaki hasonlót szeretne véghez vinni tegye a következő lépéseket:
Miután fent van minden szükséges modul (Views, Rules, Views Rules, Token):
1.: Készítsünk egy új Views-t és tegyünk bele minden adatot amire később szükségünk lesz. Pl. a node-ban szereplő e-mail címet, az ügyfél nevét, szolgáltatásait. A mezőknél állítsunk be mindent, hogy lehetőség szerint plain text legyen. Ugyan itt állítsuk be a szűrési feltételeket ami alapján a tartalmak megjelennek majd.
2.: Ha ez kész a Views-ünkhöz adjunk hozzá egy új display-t. (+Add) aminek a típusa Rules. (Ez jön a Views Rules modulból)
3. Ezen az új display fülön találunk egy Row variables részt. Ha szerkesztjük akkor láthatjuk az összes mezőt amit az előbb hozzá adtunk. Mindegyiknél használjuk a Use rendered result opciót és a Data Type volt számomra még kérdés, én a Text-et választottam. Amiket itt engedélyezünk azok lesznek később a Rules-nál elérhetőek mint Token.
4. Ha megvan mentsük a nézetet.
5. Lépjünk be a Rules konfigurációjába.
6. A sima Rules fülön adjunk hozzá egy új szabályt (Add new rule), a neve akármi lehet az esemény amire lefusson (React on event): Cron ...
7. Ezután az Akciókhoz fel tudjuk venni az előbb elkészített nézetet (Add view loop).
Eddig jók vagyunk de ezzel még semmi nem fog történni, most fel kell venni az e-mail küldés akciót.
8. Add action / send mail
És ez a "megtévesztő" rész mert első pillantásra nem látjuk az előbb említett Token-eket csak az eredetiket.
A megoldáshoz előbb mentsük el a most létrehozott e-mail küldés akciót (A mentéshez írjunk be akármit a csillagozott mezőknek)
9. És itt jön a trükk, mentés után megjelenik az e-mail küldés akció a views loop akció alatt. Fogjuk meg az e-mail küldést és akárcsak a menük átrendezésénél húzzuk kicsit jobbra, hogy az e-mail küldés akció a view loop akció gyermeke legyen. ->Mentés
10. Ha most ismét szerkesztjük az e-mail küldés akciót, akkor a viewsben hozzáadott mezők token-ként elérhetőek lesznek az e-mail mezőiben!
A címzetthez mehet az e-mail cím, a levél szövegébe akármilyen másik változó a szűrést pedig előre elvégzi a már létrehozott views!
Futtassuk le a CRON-t és már repülnek is az e-mailek! :)