Sziasztok!
Regisztrációnál megoldható, hogy egy kódot kérjen az ürlap, és ha az szerepel az adatbázisban, csak abban az esetben lehessen regisztrálni? A kód egy gyáriszám lenne, és így biztosítanánk, hogy aki nem tőlünk vásárolt, ne férjen hozzá az adatok egy részéhez.
Köszönettel:
Andrew
Az elmúlt napokat az alábbi kérdéskör megválaszolásával töltöttem, ám nem jutottam igazán sehova, ezért fordulnék az itteni emberkékhez.
Alapvető kérdés az az lenne, hogy miként lehet megoldani, hogy a felhasználó a saját adatairól eldöntse, hogy milyen láthatósági szinttel rendelkezzen, ki láthassa, ki kereshesse. Az oldal Drupal 7 alapú, és nem akarok visszatérni a régi Profile modulra, a D7-ben bennelevő Field modult és FAPI alapot szeretnék használni.
Alapvetően 2 különböző célban gondolkozom, az egyik
Ahoj! Mire is van pontosan szükséged? Ez lesz a meghatározó, hogy a döntést megtehesd és használd a választott rendszert. Írd meg és konkrét válaszokat kaphatsz pro és kontra. 1. Nem ismerem a Drupalt eléggé, így csak a Joomlarol tudok írni. 2. Ugyan jelenleg Joomlat használok, (üzlet szerűen is), de nyitott vagyok másra. 3. '99 óta használok mindenféle CMS rendszereket fejlesztőként, és amikor a Joomla még Mambo néven futott akkor ragadtam le annál - az akkori Drupal próbálkozások ellenére. A Mambo/Joomla előtt az e-107-et nyüstöltem még mélyebben pár évet. Tehát amiről írni tudok, hogy mi volt az ok, és mi az amit jónak tartok a Joomlaban, azok az alábbiak: Kedvelem a jól átgondolt, rendszerezett admin felületét, Olyan ingyenes kiegészítők vannak mellé amikkel jól megoldhatók az üzleti és marketing fogások a net-en (pl. áruház - VirtueMart -, közösségi és kommunikációt segítő dolgok). Teljesen egyéni alkalmazás jellegű oldalak, form-ok építhetők hozzá a BreezingForms kiegészítővel. Akár MLM rendszert is lehet üzemeltetni vele. Mindez idáig nem volt biztonsági gondom vele - nem úgy mint más CMS-eknél (Nuke, e-107). Ügyesen lehet a kinézeteket kezelni, alakítani. A php kódok jól érthetők, rendszerezettek. Sajna az ingyenes oldalakon nem mindig fut - ezért is vagyok most itt. A Mambo-Joomla szétválás az itthoni közösséget is bizonytalanná tette, és ezért a pl. joomla.hu, vagy a novoportal.hu stb. oldalakra szakadt csapat miatt nem érzem egységesnek itthon a dolgot. De a nemzetközi közösség nagyon nagy, így igen bő választék van megoldásokra. CMS: Tényleg bele kell tanulni és meg kell érteni a funkciók működését ez annyira alap, hogy ez okozza a sikertelenségek kb. 95%-át. A puszta szavak - hogy mikor, hol, mit is jelentenek ott pontosan. És hogy miért is jártam erre? Mert a Joomlanak is vannak korlátaik, ezért az, hogy valaki több rendszerre specializálódik az a mai világban lehet, hogy elengedhetetlen. (sajna!!) És én is tudni szeretném, hogy mi lehet az (azok) a jó ok (okok) ami megéri a Drupal tanulásába fektetett időt. Tanácsokat szívesen fogadok a Drupal-os üzleti és marketing megoldások tekintetében.
Hát szerintem én ehhez a megoldáshoz még kezdő vagyok.
Létre tudtam hozni az új modul 2 fájlját, az .infóval nincs is gond, mert a modulok alatt tudom engedélyezni, a .module már annál macerásabb, szerintem rossz adatokat adtam meg benne.
function mysite_init() { global $user; if ($user->uid = 0 && arg(0) == 'reggeli-gondolatok' && arg(1) == 6) { //adunk neki üzenetet drupal_set_message('A tartalom megtekintéséhéz előbb regisztrálnia kell az oldalra!'); //majd megmondjuk, hogy nincs rá jogosultsága drupal_access_denied(); } }
Az uid = 0 az gondolom marad, az arg részeket nem értem. Leírtad a sort, de nem látom a logikáját.
A 'node' az oldal álneve, vagy a node/ -es neve? Vagy azt nem is kell módosítani?
Az oldal nidje a szerkesztés alapján 6, mert node/6/edit
Jó helyre írtam be ott a végén?
Igazából semmit nem csinál most az oldal, de legalább nem is száll el, mint a rules modul logikusnak tűnő beállításaival.
Lehet, hagyom a franca az egészet, valami egyszerűbb megoldás csak van a problémámra. Végülis csak 1 db oldalnál kellene ezt lekorlátozni. Ez az új modul jónak tűnik, biztos én bénáztam el valamit.
Szerintem senki nem akar lebeszélni semmiről. Csupán megjegyzés volt, hogy túlgondolod a dolgokat.
Az, hogy te mit gondolsz egy egyszerűen megvalósítható dolognak az egy. De ennek sok más aspektusa is létezik amit figyelembe kell venni. Van olyan, hogy egy-egy issue-ról évekig beszélnek, meg készülnek patchek hozzá mert bár egyszerűnek tűnt de mint kiderült mégsem az.
A biztonságot alapból is szeretem ezért telepítem például a drupalt a szerver document root-ja mögé. Ez persze nem megoldás mindenre, de régebben is szerettem, ha a rendszer php fájljai nem elérhetők a közvetlenül a web-ről. Ez nem azt jelenti, hogy egy közvetlenül a web-root-ba telepített drupal rossz lenne.
Mi van?! Nem tudom te hogyan üzemeltetsz, de lehet át kellene gondolnod pár dolgot. Ebből nekem úgy tűnik, hogy nem mozogsz elég biztosan ezen a területen és amit hallottál / olvastál itt-ott azokat alkalmazod. Az, hogy ezek mennyire jók vagy sem, az már egy másik kérdés.
Ahogy Szántó Gábor vagy nevergone is mondta, a GDPR-nak vannak jogi aspektusai is. Nem fekete és fehér ez, hogy ha adatbázis szinten titkosítok mindent akkor ha be is jutnak a rendszerembe, nem tudnak vele mit kezdeni. Én meg kipipálhatom ezt a checklist-emen.
Hidd el, ha valaki be akar jutni a rendszeredbe, akkor be is fog menni előbb-utóbb. Ha neki az érzékeny adatokra van szüksége, akkor nem csak az adatbázist fogja tőled ellopni, hanem a kulcsot is amivel dekódolni tudja az adatbázisodat. Sőt, megkockáztatom, hogy mindent vinni fog ami a kezei közé kerül.
Személyes véleményem az, hogy ha már kompromittálódott a rendszered, de te erről nem értesíted a felhasználókat, mert az adatbázis úgyis titkosítva volt és (szerinted) nem lopták el a mesterkulcsot, akkor morálisan az én szememben egy semmivé váltál.
Láttunk erre példát már a nagy világban, hogy feltörtek bizonyos rendszert / rendszereket, a cég meg próbálta eltussolni, kiderült aztán jött a nagy botrány. Mindenki írtózik attól, hogy feltörjék a rendszerét, ez természetes dolog. Inkább kiadnék egy közleményt amiben leírom a történteket, aztán leírom, hogy mit tettem azért, hogy ez a jövőben ne fordulhasson elő. Illetve javaslok a felhasználóimnak bizonyos lépéseket amivel ők is növelhetik a biztonságot, sokkal jobb hozzáállás. Mégegyszer mondom, hogy szerintem!
De, hogy ne csak a levegőbe beszéljek egy remek példa minderre, igaz ez nem külső támadás eredménye hanem egy belsős hiba: https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/
https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-jan...
--
Borsa Péter
https://peterborsa.eu
Amikor a content a node.html.twig-ben kirajzolódik, akkor ott a drupal a beállítások alapján a content-et maga generálja ki. Itt hozzáférhető minden mező. A mezők twig fájljánál csak az adott mezőbe bekerülő változók érhetők el a teljes tartalom nem (kivéve persze, ha a .theme fájlon át be nem fűzőm őket az adott mező változói közé).
Viszont tudom milyen sorrendben generálódik ki a content. Ekkor, ha több mezőből egy táblázatot szeretnék, akkor az egyes mezőkhöz hozzáfűzhetem a táblázatot alkotó html elemeket, de nyilván nem mindet, hisz a táblázatot az adott táblázatba tartozó mezők fogják kirajzolni.
Példa:
Van 6 mező. Legyen ez egy két soros, három oszlopos táblázat. (A fent említett esetek nem ilyenek, de jól érzékelteti, hogy mire gondoltam rész html esetén.)
Tehát az első mezőbe bekerül mondjuk a táblázat fejléce és az első mező értéke, mint tartalom. Így az alábbi html elemeket tartalmazza (az egyszerűség kedvéért a thead, tbody most lényegtelen):
Első mező twig-jében szereplő html elemek:
table
tr
th-/th, th-/th, th-/th
/tr
tr
td (ide jön at első mező értéke) /td
Második mező:
td (második mező értéke) /td
Harmadik mező:
td (harmadik mező értéke) /td
/tr
Negyedik mező:
tr
td (negyedik mező értéke) /td
Ötödik mező:
td (ötödik mező értéke) /td
Hatodik mező:
td (hatodik mező értéke) /td
/tr
/table
Ilyenkor, mivel az első mező twig fájljában nincs befejezve a táblázat, ezért minden a táblázathoz kapcsolódó html elemet töröl a drupal és a megjelenítésnél, már nem lesznek ott. Ugyanígy jár a többi mező is, mivel hiányos html elemeket tartalmaz, ezért azok nem jelenítődnek meg. Ez olyannyira így van, hogy, ha a table - /table elem hiányzik, akkor is törlődik minden tr, th és td elem. Nyilván tudja a drupal, vagy inkább a twig, hogy ezek csak egy table elemen belül működnének ezért kiveszi őket. Azt sajnos, már nem tudja, hogy ha a hat mezőt egymás után a rész html elemekkel kigenerálná, akkor a végeredményben, már ott lenne a hibátlan teljes táblázat.
Lehet butaság volt ez az elgondolás, de elsőre logikusnak tűnt.
(A vesszővel elválasztott mezők eredetileg külön kategóriákba tartoznak, de az oldaleleji összefoglalóban egy táblázat sorba kerülnek a rokon kategóriák.)
Panels-t, még nem használtam eddig. Nézegettem, már, de komolyabban, még nem alkalmaztam. A drupal igazi mélységeivel, most a 8-as verzióban kezdtem el ismerkedni. A 7-es kapcsán sokan dicsérték a panels és a köré épülő modulok funkcióit, de sajnos, még nem ismerkedtem meg vele komolyabban.
Sok hasznos beállítást ad a drupal keresője, de, ha nem vagy biztos, hogy mit is akarsz keresni, akkor nem érdemes használni.
Nekem leginkább az vált be, hogy angolul beírom a funkciót röviden és utána, hogy "drupal", vagy "in drupal" a google-be.
Például nálam az elsők között hozza a css drupal keresésre az adott modult -kipróbáltam.
Szintén leellenőriztem a https://simplytest.me/ oldalon a drupal 7 alatt a Field group modullal a lehetőségeket. Van benne html elem megadására lehetőség. A beállítások között ráadásul elég részletesen konfigurálható. Css-el persze nem szükséges több lépcsőben a field Group használatával egymásba ágyazott html elemekkel operálni. A css mindenre jó. szinte bármiből bármit lehet vele csinálni. a flex elterjedése óta pedig még könnyebb az elrendezésekkel operálni, de rendelkezésre áll, már a grid is.
A simplytest.me használatakor előre add hozzá a szükséges modulokat, mert a próbarendszer konfigurálása után, már jó ideje nem ad lehetőséget az utólagos modul telepítésére. Ezért, ha kimarad valami, akkor újra kell konfigurálni és elindítani a tesztelést.
Komolyabb munkához, ha nincs minden területre specialista, hanem te csinálod, akkor szükség lesz html, css, js (ezek alapnak számítanak), valamint php esetleg némi sql tudásra. Drupal 8 esetén szükség lesz a twig, yaml ismeretére is. Hasznos, még a composer használatának ismerete és nem árt legalább az objektum orientált programozás alapjait ismerni.
A drupál tanulásáról láttam egyszer egy rajzot vicces volt :D. A drupal learning-re keresve a google képkeresőjében az elsők közt lesz. Jól jelképezi, hogy nehéz megtanulni, ami a 8-asra fokozottan igaz, ha kevés az alapismeret (habár nézőpont kérdése, egyes szemszögből nézve könnyebbnek is mondható :).
A kedved semmiképpen se szeretném elvenni. Egyszerű dolgokra nyilván előnyösebb egy wordpress, ami szintén sokat fejlődött, de összetettebb felhasználásra előnyösebb a drupal. Sokkal több az ingyenes megoldás is, de persze akadnak hiányosságok -inkább 8 esetén akad amire, még nincs kész modul, de egyre kevesebb az ilyen terület. Egyébként valóban rengeteg modul van. Több ezer. A pontos számot nem tudom, most fejből, de sok. Ráadásul mind teljesen ingyenes. Persze mindig eljön az a pont, amikor nincs kész modul, vagy egyik sem eléggé megfelelő. Ekkor kénytelen leszel saját modult készíteni.
Projekttól függően pártól a 10-20-ig terjed maximum általában, de előfordul, hogy egy egyedi modul sem kell, ahogy néha kellhet több is, de ezt nehéz megítélni, mert nagyon projektfüggő. Wordpress-hez, Joomla-hoz előfordul, hogy több teljesen kész megoldás létezik egy-egy problémára, de ezek általában nem ingyenesek.
A mai böngészőkben sok hasznos webfejlesztési lehetőség van, ami szintén sokat segít. Fejlesztés alatt ne aggregáld a css és js fájlokat.
Szóval kitartás!
A kérdésem az lenne, hogy létezik-e a Drupalhoz, olyan Todo modul, amiben az adott feladat állapotát százalékban lehet megadni. Pontosítok: Van 5 feladat, és az lenne legfelül ami hamarossan kész van. Ejj de nem tudok fogalmazni. Remélem azért érthető voltam. A drupal.org-ról töltöttem le egy todo modult, de az nem működik. Ja és bocsi hogy így egybeírok mindent, de nem jó az enter a billennnnytyűűűmön. Ha lesz todo modulom, akkor az enter megjavítása priorításos feladat lesz! :D
Amit el szeretnék érni, hogy egy hiearhikus fában, amit kialakítottam book-al, annak a legalsó szintjén megjeleníteni több másik nodot.
Próbáltam már áthidalni a problémát más megoldásokkal, pl taxonomy_menu segitségével, de ott ugye egy egy menüpont nem az almenüpontokat mutatja, hanem az összes al tartalamt.
Néztem egy befulladt szálat a taxonomy_html-ről, valószínüleg pont az kellene nekem, de az nics 6os alá...
Probáltam az "utodját" a sitemapot de az kifejezetten oldaltérkép lett.
contextual filter
Drupal 7 Views 3-ban át is lett nevezve, argument helyett contextual filter a neve, magyarul talán oldaltól függő szűrő lehetne a neve. Tehát az, hogy mire szűrünk, attól függ, hogy a webhelyen belül melyik oldalon (URL-en) vagyunk, milyen kontextusban jelenik meg az adott lista.