Szia Munti,
Letöltöttem a modul oldalán linkelt Webshop_5.0.zip fájlt (alatta a másik link sajnos már nem él, átirányít), kicsomagoltam, és próbáltam rákeresni benne két módon is (a gépem fájlkezelőjével és az IDÉ-n belül is) az "OTP Simple" sztringre, nem volt találat. Lehet, rosszul kerestem.
Az OTP viszont ad a csomagban egy doksit is (InternetesFizetoFelulet_180625.doc, ha az egy dátum akar lenni a fájlnevében, akkor bíztató, h viszonylag friss változat lehet, idén nyári), amiben a 4.5 fejezet címe „SimpleShop – Teszt Bolt”. De ahogy olvasom, ez is csak névrokonságban áll az „OTP Simple”-vel, nem úgy tűnik, mintha sok közük lenne egymáshoz.
Ha összehasonlítom ezt a doksit a SimplePay fejlesztői dokumentációjával, akkor nekem úgy tűnik, mintha itt két teljesen különböző dologról lenne szó, de nem értek hozzá közelebbről:
Azt is érdemes figyelembe venni, hogy egy lassan 2 éves hír alatt beszélgetünk, azóta rengeteg minden változhatott az OTP részéről is, miközben a modulhoz utoljára 2015. májusában volt hozzányúlva. Ha az OTP Simple fizetési szolgáltatás valami ennél újabban bevezetett lehetőség, akkor annak kezelésére a Drupal-modul valószínűleg nincs felkészítve.
Lehet, hogy jól gondolod, de én sajnos nem tudlak követni :)
Van a "cikk" tartalomtípus. Moshe Weitzman azt mondja, kb. 50 CCK mezőből állt össze ez a tartalomtípus (bár nyilván nem használja minden cikk az összes mezőt). Fontosabb mezők: cím, törzs, szerző (node reference), közzététel dátuma, kapcsolódó cikkek (node reference). Tehát létrehozol egy cikket a fenti űrlap kitöltésével, ez lesz mondjuk a node/1234 a rendszerben.
A "rovat" tartalomtípus szintén egy CCK node, ott a mezők lényegében dobozok, pl. "Középső oszlop felső doboz (B1)", "Középső oszlop középső doboz (B2)", stb. Amikor felviszed a rovatoldalt, akkor ezekhez a dobozokhoz node reference segítségével hozzárendeled a cikkeket, pl. a node/1234-es cikket. Az így létrejött rovatoldal lesz a rendszeredben a node/1235.
És végül a címlap a rovatoldalakhoz hasonló dobozokból épül fel, ahol a kultúra rovat mondjuk a B2-es node reference mező, ehhez hozzárendeled a node/1235-öt, stb. Az így létrehozott címlap node/1236 néven fog élni a rendszerben.
Az, hogy az egyes mezők konkrétan hogyan jelennek meg (hogy a B2-es mező hogyan kerül a címlapon oda, ahol van, hogyan néz ki – lista, bevezető – az már a smink dolga. Tehát nem a mezők hasábérzékenyek, hanem a hasábok mező-érzékenyek. Van egy hasábod a sminkben, ami meghatározza a címlapon a B2-es mező helyét, és ebbe töltöd bele a node/1235-öt és társait a megfelelő formában.
Az alapötlet egyszerű és elegáns, a kivitelezés viszont nagyon komoly munkát igényelt, nem véletlenül dolgoztak rajta 2 hónapig (ennek 30%-a csak a sminkkészítés).
Azért nem mert a szerkesztő user a formázott szöveg típusú mezőt a szerkesztési űrlapon látja és szerkesztheti is Szűrt HTML-el. Igaz, hogy a 6. pontod szerint bevitt tartalmat nem látja a szerkesztő user, de az az oldal kódjában ténylegesen sincs ott, így a javascriptem nem tudja felhasználni adatként. Úgy tűnik, hogy a Drupal ki sem küldi az értéket, mivel a user nem láthatja. Valójában ezt a Drupal úgy értelmezheti, hogy nem elrejti a tartalmat, hanem eltünteti. Itt jut eszembe, hogy a mezőhöz hozzá kellene írnom egy hidden tulajdonságot, hátha úgy kiküldi a kódot csak rejtetté teszi.
Modulokat már keresgettem a láthatóság és/vagy hozzáférés szabályozására, de amivel eddig próbálkoztam az mind ugyanazt csinálja, hogy ki sem küldi mező value tartalmát vagy még a meződeklarációt sem a korlátozott usereknek. A "Field Permissions" modul pedig bugos lehet, mert ha az egyedi jogosultságainál tiltom bármelyik mező szerkesztését a szerkesztő user számára akkor a képfeltöltés mező nem hajlandó többé képet feltölteni, annak ellenére, hogy az nem került korlátozásra.
Amúgy ez a változás csak a D10-ben van, mert a régebbi Drupalban (8) elég volt a user hozzáférését tiltani és a Drupal akkor kiküldte a mezőt és a mező tartalmát is az űrlapra csak szürkével jelent meg és nem volt szerkeszthető, de ott volt és a javascript tudta is használni. A D10 már ki sem küldi sem a mező kódját, sem annak tartalmát annak a usernek amely számára korlátozva van a hozzáférés. Nem böngészőfüggő, mert 4 böngészőben is kipróbáltam.
Köszönöm a hozzászólásod.
A következő problémába futottam bele a napokban, leírom a megoldást, hátha hasznos lesz valakinek: frissítettem az IE9-re, utána pedig megnéztem, hogy az oldalaim miként jelennek meg az új változatban.
A probléma ott van, hogy amikor elkezd az ember valamit tanulni, akkor még nem ismeri. Mivel nem ismeri ezért azt se tudja megmondani, hogy mennyi időbe fog neki kerülni, hogy megtanulja és általában túlbecsüli az időt (nagy fehér köd gomolyog szemei előtt;)). Ezért aztán beláthatatlan hosszú időnek tűnik amíg elsajátítja. A másik probléma, hogy nincs gyakorlata, kialakult megoldás rendszere, tehát ha elront valamit jön a pánik.. "mostmicsináljak, uramatyám".
Az első szabály tehát: "Ne ess pánikba" (talán ismerős lehet sokaknak ez a jó tanács;))
A második: aki tudja, az megtanulta már, tehát meg lehet ezt tanulni! Szóval hajrá!
Azzal nincsen semmi probléma, hogy valaki úgy akarja megtanulni, hogy közben csinálja élesben. (nem egy hídról van szó ugyanis, ami ha leszakad sok ember élete kerülhet veszélybe)
Azzal sincs probléma, hogy itt a fórumot felhasználva állítja össze a rendszerét. Ha megfigyelted azokra a "kérdésekre" amelyek konkrét feladat végrehajtásra irányulnak nem mindig érkezik válasz, nem is véletlenül. Hisz itt nem dolgozni akarnak a fórumozók ingyen, hanem segíteni. Ez ám a nagy különbség.
A baj azokkal van, akik bevállalnak egy melót, mert őkaszupermájerek és már 10 oldalt összeraktak ami műxik és itt ingyen dolgoztatják az embert. No ez nem korrekt, de ezek az emberek nem is kapnak segítséget.
Szóval alapvetően nincs baj ezzel, ha valaki élesben tanul és a saját ötleteit maga valósítja meg a fórum segítségével.
Ha megnézel egy gyereket, akkor nem úgy tanul meg járni, hogy nézi, hogy ki hogy csinálja, és googlizik, meg fórumot olvasgat, hanem feláll és elesik, és feláll és elesik. Ez az igazi tanulási folyamat. Neked hányszor volt olyan érzésed, hogy mi a francnak tanulom én ezt meg, és így utólag nem érzed-e, hogy sok felesleges dolgot kellett megtanulnod? Nincs ezzel gond, de azzal sincs, ha valaki csak azt akarja megtanulni ami neki kell, és az, hogy mi kell neki azt az adott feladat fogja majd kialakítani.
Nem bemagoljuk a térképen az utakat, hanem megjelöljük a célt és abban kérünk segítséget, hogy hogyan tudunk oda eljutni. (folow the white rabbit) Sokan azt hiszik, hogy így nem lehet tanulni, mert a suliban nem így tanultak, de hát könyörgöm, azért mert a tanárok azt hiszik(én is ezt hittem, és hiszem is gyakran, csak megpróbálom eljátszani, hogy mégse), hogy kizárólag az az egyetlen üdvözítő út ahogy ők csinálnak valamit ne higgyük már el nekik!
Szóval a lényeg, hogy nem a célhoz vezető utat kell elsajátítani, hanem a célhoz vezető út megtalálásának folyamatát. Ennek pedig a legnagyszerűbb módszere pont az éles magas presszióval/motivációval rendelkező bevetés. Egy megfelelő gyakorlattal rendelkező webes alkalmazás fejlesztéssel foglalkozó szakembert pl. 2-3 óra alatt tökéletesen el lehet igazítani a sminkkészítés rejtelmeibe, és 4-5 óra alatt a modulfejlesztésbe. (nem mindent fog tudni, hanem azt fogja tudni, hogyan fogja tudni biztosan, stabilan, tervezhetően. Tudom, kipróbáltam)
pp
(ja és minél népszerűbb egy rendszer annál több a kezdő, minél több a kezdő annál többször merül fel ugyan az a kérdés. Ezért is készült el a Drupal Mozikönyv)
Palócz István
https://palocz.hu | https://tanarurkerem.hu
A Drupal csak a konkrét node-ok saját oldalainak látogatottságát számolja. A node/1 azt jelenti, hogy az egyes sorszámú node oldala látszik. Írd be, hogy index.php?q=node/1, és akkor ennek számlálója nő. Az itt keringő kód egy konkrét node látogatottságát számolja. Ezzel nem lehet a címlap látogatottságát számolni, ha az nem egy konkrét node. Sőt más oldalak látogatottságát sem lehet mérni, ezeket nem összesíti és így tovább.
A Drupalba az van beépítve, hogy konkrét node oldalak látogatottságát egyenként mérje. Ami nem node oldal, azt nem méri, és semmilyen adatot ezen felül nem összesít.
Ha neked más kell (olyan számláló, ami minden oldallatöltést összesítve mér), akkor vagy keresel erre modult (neked nem ajánlanám), vagy fogsz egy máshol szokványosan használt külső képet megjelenítő számlálót, és berakod a page.tpl.php oldalba, mint ahogy különben az index.html-be szoktad tenni más oldalaidon. Szerintem neked egy ilyen számláló kell, bb.virgo valamiért másképp látja.
van egy 4.6 -os oldal http://okoturizmus.hu amit szeretnék 4.7-re "frissíteni". a gond az, hogy egy szerveroldali "elszállás" után az adatbázist visszarakó szolgáltató kavart valamit, úgyhogy jelenleg olvashatatlan karaktereket és latin1-swedish egybevetést látok aza adatbázisban
egy kis részlet az adatbázisból: ross-motoros rend??rj??r??r??k kezdt??k meg a szolg??latukat szerd??n a
Bakonyban: els??sorban Zirc, Olaszfalu, Epl??ny, Veszpr??m ??s V??rpalota
amúgy az oldal ehlyesen jelenik meg most, de frisstíésnél nem. kértem a szolgáltatót csináljon valamit, és valamit csinált is mert vannak jól megjelenő dolgok a tesztoldalon, de általában nem jók a karakterek (pl külső rss csatornák tartalmai a blokkban) és az adatbázis továbbra is olvashatatlan: http://eco.okoturizmus.hu
sajnos nem értek hozzá (bocs ha rossz kifejezéseket használtam) ha tud valaki segíteni, kérem tegye meg. köszi
Igen, ebből indultunk ki, és épp ez volt a migráció szempontjából a problémám. A node_revisions tábla body oszlopába, azaz az eltárolt html kódba ilyen formában kerül be a link: href="/drupal/node/61", ha ezt adom meg: "/node/61". Csináltam egy próbát: a lokális gépemre, a "localhost/drupal" könyvtárba telepített rendszer nevét átneveztem "dru"-ra, aztán egyedül a .htaccess-ben módosítottam a RewriteBase értékét, és gyönyörűen bejött a főoldal, sőt a menü v. bármelyik a drupal által standard módon generált link működött (nem meglepő, mivel az adatbázisban ezek a linkek tényleg relatívként tárolódnak) - egyetlen kivétel volt: az oldalak forrásába, a tinymce-vel beillesztett linkek, amik ugye megmaradtak eredeti formájukban, és emiatt rossz helyre is mutattak.
Szerencsére ez a teszt bebizonyította, hogy nagy valószínűséggel tényleg csak ezeket a linkeket kell majd a migrációnál módosítani, és hogy hol vannak ilyenek, az egy adatbázis exportból könnyen és gyorsan kiszűrhető (node_revisions tábla).
Azért köszönöm az ötletet, mert ez is hozzájárult, hogy élesedjen a kép.. :)
#wrapper #container #header h1, #wrapper #container #header h1 a:link, #wrapper #container #header h1 a:visited { line-height: 20px!important; /* Az eredeti erteke 120px, ezert van az a nagy tavolsag, atallitgathatod, ha gondolod */ }
az eredeti CSS-t ne változtasd (ugyan olyan ez, hogy a drupal core-t sem változtatgatjuk), mert, ha kijön egy frissítése, akkor elveszik a sok munkánk.
írj egy új css-t (pl. dif.css), abba tedd bele a változtatásokat. ha ügyes vagy, az important szabályokra sem lesz szükséged. i mean, írjad bele ezt az eredeti CSS VÉGÉRE: @import "dif.css";
ninja - http://alleycat.hu
Miután a Rules-re bármikor
Miután a Rules-re bármikor szükséged lehet még egy egyszerűbb oldanál is, így nem árt megtanulni :)
Itt a példa remélem követhető
Rules
Új szabály
1. Nevet adsz neki és kiválasztod az eseményt:
„Új felhasználó létrehozása után” (mentés)
2. Feltételnek megadod:
„Adatok összehasonlítása”
- Adatkiválasztó: account:field[szerepkör_tipusa] (folytatás)
művelet:
- megegyezik
érték:
- a szerpkőr PL: „A” (mentés)
3. Akciók
„Felhasználói szerepkőr hozzáadása”
- Adatkiválasztó: account
- Érték: az „A”-hoz társított szerep választása. (mentés)
Így létre jött az „A” szerepkőrhöz a hozzárendelési szabály, mikor a felhasználó menti a regisztrációnál a listából kiválasztott szerepét.
Ezt még legyártod a „B” és a „C” -re és kész az automatizálás.
A mezőszintű jogosultságra pedig használhatod ezt: field_permissions Itt megadod, hogy csak az admin tudja módosítani utólag és akkor a felhasználó már nem tudja mentés után átállítani.
Módosításra is van Rules :) „Felhasználói fiók módosítása után”
Gyakorlatilag ugyan azt a szabályt kell legyártanod csak erre az eseményre.
Így ha a felhasználó elrontja a regisztrációnál a szerepét akkor, ha admin javítja akkor lefut ez a szabály és kész is az automatizálása a szerepkőrhöz rendelésnek.
Ha megvagy velük rules alapozónak tökéletes feladat.