Az upload modulhoz van egy ilyen kis kiegészítő: Uploadpath modul. Lehet, hogy kisebb hekkeléssel rá lehet venni, hogy az Image modullal is együttműködjön. CCK image field esetén ez azt hiszem megoldott.
Az igényeimet tökéletesen kielégítené egy "normális" image_gallery modul, amiben a képek sorrendjét meg tudom változtatni.
Ha csak egy "normális" hierarchikus rendszerező modul kell, akkor ott az alapcsomagban a Book modul. Én is azt használtam galéria kialakítására nemrégiben.
Sziasztok!
Sajnos elég komoly gondban vagyok, remélem tud rá valaki megoldást. Elfelejtettem a jelszavam (adminként) ezért nem tudok belépni az oldalamra. Ez még nem lenne tragédia, ami bonyolítja a helyzetet, az az, hogy az oldal le van zárva. Vagyis ha rákattintok az elfelejtett jelszó opcióra, bejön az oldal ahol jelzi hogy a weblap karbantartás alatt áll. Mit tudok csinálni?
Sziasztok!
Van egy ingatlanos oldal, ahol minden ingatlanhoz tartozik egy ár, forintban. Viszont az ingatlanok árát EURO-ban is meg kellene jeleníteni úgy, hogy erre az árra szűrni lehessen (views), és az árat bizonyos időnként magától számolja ki újra a forint alapján, árfolyamváltozások miatt.
Most van az "ingatlan"-ban FORINT és EURO mező is, de az EURO üres.
Azt szeretném megvalósítani, hogy ha árfolyamváltozás van, akkor valami automatika az összes EURO mezőt újraszámolja, az új árfolyamot elég, ha az user "adja be".
Kedves József nálam nem igy működik, mert ez történik:
magyarul : Első oldal - node/add/page (egy belső hivatkozás)
angolul . : First page - node/add/page (egy belső hivatkozás)
Mindkettő mindig látszik. A Drupal a magyar esetén a két útvonalat node/add/page -nak mutatja ha váltok angolra akkor meg en/node/add/page -nek mutatja. Ezt úgy olvasom le, hogy jobb egér-tulajdonságok. A változókat ha kikapcsolom, ugyanez a helyzet. Ezért csináltam a kisérletet, mert nem értem mi történik abban az esetben ha az útvonal egy belső drupalos hivatkozás és mindkét esetben ugyan az. Ha ez nem egyforma akkor meg nem kell a settings.php módosítása ehhez, mert úgy is működik. Ha az oldal fejszövegét váltani akarom, akkor a settings.php-t módosítani kell és a leírásod szerint korrektem is megy, logikailag értem is.
Ha a beállítás oldalon állítok akkor ott van a "This is a multilingual variable." felirat, de a combobox felirata az angol nyelv alatt, részben magyar, részben angol. Ezek nálad is így látszanak, vagy angol nyelv esetén angolul, magyar nyelv esetén magyarul.
Igy látszik nálam:
------------------
Elsődleges linkek
Másodlagos linkek
Navigáció
No primary links <- ha magyarra váltok akkor ez itt magyarul jelenik meg !
Úgy tudom a Drupal az útvonal és/vagy a nyelvi előtag alapján vált. Ha váltom a nyelvet akkor szerintem ezeket a belső útvonalakat átírja, ahogy most látom. Vagy valamit nem jó sorrendbe adok meg neki. Nem értem mi történik nálam vagy mit nem csinálok jól vagy jó sorrendbe és minek kellene történnie.
Ha szeretném neki én megadni ugyanazt amit kiir akkor meg visszadumál:
"The path 'en/node/add/page' is either invalid or you do not have access to it."
"The path 'hu/node/add/page' is either invalid or you do not have access to it."
Ha létrehozok pl egy "Főmenüt és ott adom meg a node/add/page hivatkozást az angol és a magyar ágnak egyformán, akkor az jól működik, mert a menü felirat az vált. A settings.php-hoz nem kellet nyúlni.
Németi Vilmos - méregzöld kezdő Drupal-os
„A két sql -t összevettem és megkaptam azt amit valójában a drupal módosít az adatbázisban.”
Akkor, ott, olyan beállításokkal. Csinálsz valamit ami csak egyszer lesz használható soha többet. Amint állítasz valamit a rendszereden ami picit is módosít a folyamaton akkor máris kukázhatod a nagy tudásodat, hogy mit is csinál valójában a Drupal mert nem azt fogja csinálni.
Leírták, hogy bármit is csinálsz ilyen hozzáállás mellett nem lesz jó. Azért mert egy adott pillanatban amikor elkészíted talán működni fog, de éppen hogy egy paraszthajszálon múlik ez a működés.
„Ebből kiindulva azon is folyhatna a vita hogy nem lehet a drupal adatbázisra scriptet írni ami megjeleníti a node -t mert nem hasznalok api -t. brrrr.”
$emitt = node_view(node_load(1));
Lécci mellékeld már a scriptedet ami ugyan úgy helyesen működik, ha ki be kapcsolnak egy modult, ki be kapcsolják a gyorsítótárat, változtatnak a hozzáféréseken (content_access() pl.), módosítanak a sminken stb.
Senki nem mondta, hogy nem lehet, csak annyit mondtak nem kell megírnod újra a Drupal-t mert már megvan írva. Ráadásul nagyon jól úgy, hogy ha bele akarsz túrni mélyen a rendszerbe akkor adnak neked eszközöket, hogy ne kelljen szétbarmolnod az adatbázist, amiről azt se tudod hogyan kerülnek bele az adtok. Kapaszkodj meg nincs a földön olyan ember aki tudná hogy pontosan mi történik. Azért mert egy Drupalt most már kb 5000 külső modullal bővíthetsz és kvadrillió módon konfigurálhatsz amikor is máshogy és máshogy fog működni ez a folyamat. Az egyetlen biztos pont az API. Amikor azt mondod node_save() akkor lejátszod mindazokat a folyamatokat amik akkor történnek amikor egy node mentésre kerül. És hidd el, hogy mi történik ilyenkor az száztrillió dologtól függ. Te egyszer megnézted az derék, de azért az nagyon, nagyon kevés a működés megértéséhez.
Amit csinálsz az gányolás és kerülendő értsd meg.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
ez egy tudásbázis próbál lenni, ahol feltett kérdésekre érkeznek válaszok. itt nem volt kérdés. a hasonló elemzéseket írd egy saját blogba vagy ilyesmi, de itt most nem tudom mi volt a kérdés vagy milyen reakciót vársz egy ilyen bejegyzésre. :)
mivel új vagy, gyorsan el is mondom, hogy a hetes drupal iszonyú régóta készül már és nem ad-hoc módon dobálják bele a funkciókat meg változtatják meg a dolgokat, hanem komoly usability tesztek eredményére reagálnak a változtatások.
azért sorra "válaszolgatok" a feltett "kérdéseidre", hogy kicsit tisztuljon a köd. :)
xampp:
a hetes drupalnak kell a php pdo kiterjesztés. ez valószínűleg nincs az xamppodban, azért nem települt fel. (legközelebb a "hibaüzenettel elszáll" kijelentésed ha esetleg megtoldod magával a hibaüzenettel, az igen jó lenne..:)
a megnyíló ablakot "overlay" -nek hívjuk, a core nem kötelező moduljai között találod, simán kikapcsolod és nem lesz megnyíló ablak sehol.
lehet kicsit lassabb alapkiszerelésben, igen. cserébe többet tud, cck, imagecache, filefield mind a core része, több erőforrást eszik természetesen.
a szépség igen relatív dolog, hálistennek olyan sminket választasz/építesz magadnak amilyet akarsz. :)
az admin user role azért került létrehozásra telepítéskor, mert amúgy mindenkinek kb ez volt az első dolga. (óriási volt rá az igény, hogy legyen egy admin csoport alapértelmezetten) hogy elvettél a csoportól jogokat és az "admin usered" mégis tudta csinálni a dolgát, annak valószínűleg az az oka, hogy uid=1 user -el voltál belépve, aki a "superuser" őneki mindig mindenre joga van és általában semmilyen csoportnak nem tagja, nincs rá szüksége. jólnevelt drupalosok egyébként nem használják uid1 -et semmire, ez egy speciális felhasználó a "szuperadmin" vész esetére tartogatjuk, illetve különös feladatokat hajtunk végre vele, pl update.php futtatása.
szintén ugye, uid1 -et zároltad, nem túl nyerő ötlet. :) persze az adatbázisban kézzel le tudod venni róla a zárolást, úgyhogy emiatt nem kell újratelepítened.
általános jótanács,
ha majd lesz egy nagy honlapod, este, k. fáradtan ne zárolgass usereket. :) human interface error ellen a legjobb nasa rendszerek se tudnak védekezni. :P
-
clear: both;
egy jól kitalált rendszer, de meg kell érteni a logikáját, és mivel most ismerkedsz a Drupallal ezért első talán soknak tűnhet a rengeteg info. :-)
Ha fenti pizzarendelés weboldat kellene elkészíteni, akkor az előtelepített Commerce Kickstart rendszer verziót tenném fel. Azután a Commerce Extra modulban csak a Commerce Extra Quantity és a Commerce Extra Login Page részeket használnám, hogy könnyen tudják a mennyiségeket változtatni a Kosárban és a visszatérő vendégeknek egyszerűbb legyen az újrarendelés, mert ők így azonnal be tudnak lépni.
A Commerce Addressbook modul azért hasznos, mert a vendégek ezzel a korábbi szállítási címeiket egyszerűen ki tudják választani az ismételt rendelésnél.
A Product Display Manager-t is fel lehet tenni, de anélkül is van élet. A Commerce AutoSKU akkor előnyös, ha mindegy, hogy milyen belső cikkszámod van, mert nem egy meglévő rendszerhez igazodsz, ekkor automatikusan hozza létre azt a rendszer a megadott paraméterek alapján, és nem kell mindig azt kézzel beírni.
A termékvariációk (pl. pizza feltétek, méretek) létrehozásához a Commerce Product Attributes modul szükséges, aminek a segítségével hozzá tudod adni a termékhez a plusz mezőket vagyis a jellemzőket (pl. pizza feltétek, méretek).
Ezeknek a mezőknek értékeket is kell adni (pl. + sajt, + oliva, ...), majd létre kell hozni az összes termékvariációt az árakkal.
Azután egy Product display-be, "termékcsoportba" kell rendezni az összetartozó termékeket (pl. a négysajtos pizza összes feltét variációját), ami azt eredményezi, hogy az adott pizza oldalán pl. egy legördülő menüből lehet kiválasztani a feltéteket. A rendszer automatikusan számolja ki az árat, mivel azt a termékkombináció létrehozásakor már bevitted.
Ez persze csak nagyon tömör összefoglalása a sok apró részletnek, ezért érdemes megnézni a leírásokat és az oktató videókat, aminek itt van egy jó gyűjtőoldala: http://www.drupalcommerce.org/faq/training
Ez egy jó kezdő DC bemutató: http://www.ostraining.com/blog/drupal/drupal-commerce-first-look/ , ezek pedig profi, nálam sokkal jobban magyarázó :-) videók: http://vimeo.com/channels/commerceguys
Sok sikert! :-)
Igen, nem pont úgy működik, ahogy a Gmail, tehát tényleges mentés tényleg nem történik (nem menti végleg az entitást), csak Ctools cache-be/munkamenetbe ment. Ami tulajdonképpen valahol érthető: gondolj bele, hogy mondjuk olvasgatod a kedvenc híroldaladat, és azt látod, hogy az egyik cikkben szerepel egy értelmetlenül félbehagyott mondat, és csak nézel, hogy hát ez meg mi. Írsz is egy kommentet gyorsan, hogy itt valami bibi van, nézzenek rá jobban a cikkre. Pedig mondjuk lehet, hogy a cikk szerzője épp frissítette a cikket, de közben egy ilyen modul elmentette véglegesen a változtatásokat. Na ez elég kellemetlen lehet, főleg, ha közben valami hatalmas baromság került a cikkbe, és a szerző nem olvasta át még egyszer (hogy publikálható állapotba kerüljön, ergo véglegesen mentsen).
A Ctools cache szerintem csak cache-törléskor ürítődik, míg a sessionbe mentés addig tart, amíg él a munkamenet - vagyis például amíg a felhasználó böngészőjéből nem törlődik az erre vonatkozó cookie. Tehát ha a felhasználó úgy dönt, hogy törli az összes cookie-ját, akkor a piszkozata is el fog veszni. VAGY például ha másik böngészőt használ, akkor nem fogja tudni visszaállítani a módosításait, hiszen ahhoz más munkamenet, más cookie tartozik. Úgyhogy szerintem érdemes inkább a Ctools cache-t meghagyni, ami az alapértelmezett.
A Ctools cache-sel kapcsolatos írtak csupán feltételezések.
===================
Szerk.:
ezt vissza is vonom. Kipróbáltam, hogy ugyanazzal a júzerrel másik böngészőben bejelentkeztem, és nem tudtam restore-olni azt a változtatást, amit készítettem az előző böngészőben, tehát igazából nem nagyon értem, akkor ez most miért is jó.
Ezt mindenképp jelezni kéne a fejlesztőnek egy issue keretén belül, mert ezen bőven van mit csiszolni. Úgyhogy hajrá! :D
===================
Egyébként jogosnak érzem az igényedet, hogy valamilyen néven legyen elmentve, és több változat is mentődjön! Jelenleg ugyanis tényleg csak felülíródik mindig a korábbi változat, az meg sok esetben nagyon nem jó.
Szerintem írhatnál a sandbox projecthez egy feature requestet erre vonatkozóan! Biztos a fejlesztője nyitott lesz az ötletekre, és legalább kap egy feedback-et, ami nagyon sokat számít.
koszi de
Koszi de az a bajom, hogy csak admin altal letrehozott tartalmakat hajlando atvenni. Adminkent kuldom, adminkent kapcsolodok, de ha a tartalom letrehozoja nem az admin akkor nem veszi at. PEdig letezik ugyanaz a juzer a fogado oldalon is nev, email stb ugyanaz