Ugyanaz a probléma...
Ugyanez a problémám.
Installáltam 6.10 alá az image modult és nem hozza létre a könyvtárt, folyton a piros üzenet jön fel:
# könyvtár nem létezik.
# Hiba miatt a beállítások elmentése sikertelen.
Publicra van állítva a fájlrendszer, a könyvtár írási jogosultsága is ok, szerintem minden jól van beállítva. Találtam egy patch-t, ezt alkalmaztam (http://drupal.org/files/issues/image_file-exists_243895.patch), annyit értem el vele, hogy kép importálás beállításnál már meglátta a könyvtárt, mert addig ott is ugyanazt az üzenetet kaptam, amit fent írtam, így az importálás funkció már működik.
Viszont hiába töltök fel képeket, ezt a hibaüzenetet kapom:
user warning: Table 'dbname.image' doesn't exist query: INSERT INTO image (nid, fid, image_size) VALUES (22, 17, '_original') in /var/www/vhosts/weboldalam.hu/httpdocs/includes/common.inc on line 3422.
Az érdekes, hogy feltettem az Imagepicker modult, ami egyből létre tudta hozni a neki szükséges könyvtárakat a sites/default/files könyvtárban. Na, ez nem sikerült az image modulnak, csak ugye az image modullal lehet sok képet egyszerre feltölteni és galériákba rendezni, így nekem arra lenne szükségem.
Nem tudom, mi lehet a baj, de már nagyon idegesít és egyre inkább kétségbe esem. Esetleg ötlet valakitől?
Update (másfél órával később):
Közben annyira idegesített a dolog, hogy letöröltem mindent a szerverről és kitakarítottam az adatbázist is és újratelepítettem mindent, de most az első az image modul volt és láss csodát, működik a dolog. Nem tudom, mivel akadhatott, de úgy gondolom a devel modullal, azzal már voltak korábban is problémáim, főleg a theme devellel.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Egyre gondolunk
Kedves Zoli egyre gondolunk, azt hiszem, mert minden rendszernek van egy terminológiája. Nekem itt ezt nehéz volt az elején elkapnom, és szenvedtem is emiatt. Azonban sokatoktól kaptam jó tanácsot és ezt mégegyer köszönöm. Tényleg sokat segített. Meg kell tanulni "Drupal-ul" Igaz. Nem erre értem, hanem arra, hogy egy kezelő felület az egy kezelőnek szóló felület. Egy ilyen megtervezése az egy szakma és nem autodidakták próbálkozásának helyszíne. Sokan bele fognak most kötni abba amit leírok, de vállalom, az Apple, Novell és a Microsoft párharcából kialakult ikonos kezelő felület egy elfogadott és megszokott dolog.
Biztos te is találkoztál már sokféle felülettel és gondolom volt ahol azonnal képben voltál és volt ahol nem. Kérdés kinek szól a felület. Lehetnének pl. olyan rendszerek, ahol állítani tudod a nehézségi szintet, mint a játékoknál. Kezdő haladó, profi stb. Ha nekem az a fontos hogy programozó kezelje akkor olyat kell csinálnom, ha az a szándékom, hogy kezdő se tévedjen el akkor olyat kell csinálnom. Ez két ellentétes szempont. Erre egy igen jó kezdeményezés a sokak idegeit borzoló extra.hu beépített blogja. Az előbbi ötletet tőlük vettük és alkalmazzuk is a céges adatkezelő rendszereinkben. Nekem teljesen kezdőnek a Drupal-t mint felületet belakni talán egy hét alatt sikerült, az is igaz először feraktam és utána le is vettem, és mást próbáltam. Elsőre idegen a megjelenése. Én a Gusztáv könyvében ajánlott admin menüt használom, mert hozzám az áll közel.
Ha ebben a felület és működési elv dologban mindenki megtalálja a neki megfelelőt akkor az jó dolog. Ha ebben egy kezdő jó segítséget kap akkor azt fogja érezni, érdemes belevágni. Ebben nekem a jegyzet sokat segített.
Remélem hasonlóan gondolod te is.
Üdvözlettel :)))
Németi Vilmos - méregzöld kezdő Drupal-os
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Miután alaposan elolvastam a
Miután alaposan elolvastam a két modul leírását (már amennyire angolul értettem), nem láttam különbséget csak abban, hogy az egyik egy külön a szerverre telepítendő program, amiből azt a következtetést vontam le, hogy akkor az mégis csak gyorsabban és jobban dolgozhat.
Egyébként semmi bajom nem lenne a GD-vel, de az ImageAPI telepítésekor mindkét lehetőséget ki lehetett választani és a GD-vel kezdtem, viszont ott szólt a Állapot jelentés, hogy a 64 RAM nem a legoptimálisabb, mert 1200×1600 pixeles képnél az kevés lehet, főleg, ha egyszerre két képet dolgoz föl (nem értem miért kettőt említ, hiszen ha egyszerre több felhasználó dolgozik vele, akkor ez még több lehet) és 96 MB RAM-ot javasol.
Engem zavar, ha nem minden zöld színű az Állapot jelentésnél, viszont így is 32 MB-ról sikerült megnöveltetnem a tárhelyszolgáltatótól a feltöltésenkénti maximum méretet 64-re és azt mondta akkor, hogy nagyobbat már nem szeretne. Most ha a RAM-ot is növeltetni akarom, nem sok esélyem van rá, bár úgy tudom nem kell mindenkinek engedélyeznie, hanem megoldható, hogy csak egy-egy usernak.
Szóval ez van.
Egyébként már pár napja szédelgek a sok image modul miatt, mert van az Imagefield, az ImageApi, Az ImageCasch, a sima Image és még sorolhatnám, na meg a Lightbox2, pedig mindössze csak azt szeretném elérni, hogy ha egy felhasználó feltölt képeket, akkor azok Lightbox2 módon automatikusan megjelenjenek, mert ugye ők nem fognak linkeket "kódolgatni". Ugyanis amit "alapból" tud a Drupal, azaz, hogy a szülő ablakban megjelenik a kép, ha rákattintanak, egy üres lapon, az elég gagyi.
Őszintén szólva a képkezelés a 6-os verzióban elég körülményes, szerintem ezt az egészet egy modulba be lehetne és kellene pakolni.
Sajnos nem tudok még programozni, de ha már tudok adok a közösségnek egy ilyet :-)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Szerintem ez egy összetett probléma
Pl. ha az oldalra látogatva a bejelentkezett felhasználónak megjelenik a visszaszámláló, és ad 10 percet a feliratkozásra.
A kliens oldalon a böngészőben is több variációt át lehet gondolni:
- Mi történik, ha 2 perc után frissíti az oldalt? Újraindul a számláló vagy folytatnia kell 8 percről a visszaszámlálást?
- Mi történik, ha elnavigál az oldalról 2 perc után a felhasználó és fél óra után visszajön? Lecsúszott a feliratkozásról, vagy újraindul a visszaszámlálás, esetleg 8 percről folytatva.
- Mi van ha kikapcsolja a javascript-et? Ha fontos a védelem, akkor a szerver oldalon is kell majd valamilyen ellenőrzés.
A szerver oldalon:
Itt egy lényegi adatod van, hogy az adott user mikor nézte meg az adott oldalt először. Ha pl. bekapcsolod a statistic modult, akkor a drupál naplózza ezeket: http://drupal.stackexchange.com/questions/60296/track-individual-user-pa...
--------------------------
El tudok képzelni pl. egy ilyen megoldást:
- A user betölti az oldalt és elindul a timer (10 perc), a szerver oldalon bekerül a statisztikai táblába, hogy ez a user ezt az oldal ebben a időpontban nézte meg.
- X percenként futtatsz egy szkript-et (van hook_cron() is), megnézed a statisztikai táblát és minden olyan user-től, aki több mint 10 perc nézte meg az oldalt, elveszed a megtekintési jogot (ezt a content access modul valamelyik táblája tárolja).
- Így ha kb. 10 perc után (ha sűrűn futtatja a cron a szkriptet) a user betölti újra az oldalt, már nem lesz jogosultsága, kap valamilyen "Access denied" jellegű hibaüzenetet. Így akármit csinál a visszaszámláló a kliens oldalon, az oldal mindenképp le lesz tiltva.
- Persze a kliens oldalon is ki kell írni valamit a user-nek, ha lejár a számláló...
Kicsit programozós feladatnak tűnik ez így, bár lehet hogy a rules-al is lehet ilyesmit, legalább részben.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Igen ebben részben igazad van
Azért ebben az esetben kapcsolatban áll a két fél és ismeri egymást. A jelszót pedig nem véletlenül nem lehet megnézni, csak felülírni. Ekkor pedig bizonyítható, hogy a jelszó módosítva lett, hisz a régi, már nem működik. Tehát nem lehet stikában garázdálkodni a rendszerben.
Ha a rendszerhez és az adatbázishoz hozzáfér valaki, akkor akár végül is bármit megtehet. Ha nagyon akarja, még az admin jelszó nélkül is újraépítheti az oldalt, hisz minden fontos tartalom és beállítás ott van az adatbázisban és a rendszeren.
Próbálom elképzelni, amit mondasz, de ez akkor lehet inkább probléma, ha nincs szerződés a felek közt és a partner, vagy megrendelő fizetés nélkül akarja a teljes jogot gyakorolni és kizárni a fejlesztőket. Szerintem mindig érdemes jól dokumentált szerződést kötni, amiben igyekezni kell minden eshetőségre kitérni.
Bár a világ sokszor igen gonosz, de elképzelhető, hogy tényleg elfelejtette a jelszót. Érdemes olyan jelszómegadási stratégiát választani, ahol különböző jelszavak képződnek, de a módját csak te ismered. Érdemes jelszó-emlékeztetőt használni, vagy biztonságos formában tárolni a jelszavakat, ha máshogy nem megy. A tárolás esetén a jelszókezelőben mindenképpen érdemes egy erős jelszót választani, mert, ha valaki hozzáfér a jelszótáradhoz, akkor mindenhez hozzá fog férni. Tárolt jelszavak esetén hajlamosak az emberek elfelejteni a jelszavaikat, ezért minimum két, vagy három helyen érdemes a tárat elhelyezni. Mivel, ha az elvész, akkor minden jelszó elvész. Vannak netes tárak is, de ott sem mehet biztosra senki. Akár az ezekben tárolt jelszavak is elveszhetnek (igaz erre kicsi az esély, de megeshet). A másik, hogy feltörhetik ezeket a szolgáltatásokat (ez sem könnyű, de szintén nem lehetetlen). Tehát nincs tökéletes megoldás. Valamit viszont alkalmazni kell, mert adódhatnak olyan esetek, amikor egy elfelejtett jelszó nem pótolható.
Tehát, ahogy az alább hozzászólaló is mondta, weitam801 legalább használj egy emlékeztetőt legközelebb.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Még egy ötlet
Nem biztos, hogy működik, mert nem próbáltam ki, de talán a legegyszerűbb megoldás lehet, ha nem akarsz modult fejleszteni a problémára.
A Mega Menüben lehetőség van extra osztályok hozzáadására. Az oldal sminkjében be kéne injektálni a Mega Menü témájába a jogosultságot. Ekkor eldönthető lesz az adott jogosultsági kör. A jogosultsági körtől függően pedig két irányba lehetne a menüelemek megjelenését legenerálni. Ha például admin vagy, akkor marad a hagyományos menüelem megjelenítés. Amikor viszont nem, akkor egy szűrővel kiszűrhetők lennének a megjelölt elemek. A Mega Menü lehetőséget ad egyedi osztályok megadására a menüelemeknél. Oda beírva a kívánt elemekhez például, hogy admin az elem, már meg is van jelölve.
Tehát a fenti megoldás esetén, amikor nem aktív az admin jog, akkor minden menüelem kirajzolásakor a twig szűrője megvizsgálja, hogy az adott menüelem rendelkezik-e a fenti példában használt admin osztállyal és ekkor nem adna kimenetet. Ha nem rendelkezik az admin osztállyal, akkor pedig úgy jelenítené meg a menüelemet, ahogy eredetileg is.
Tudom, tudom ez is igényel némi kódolást egy pici php és némi twig, de talán ez a legegyszerűbb. A pontos megvalósítás függ a Mega Menü működésétől, annak sminkrendszerátől. Ahogy elsőre látom az li twig-jét kell módosítani. Viszont a https://simplytest.me/ segítségével próbálva nekem most rendre elfelejti az extra osztályokat. Az admin felületen még megjelenik a mentés után, de újra betöltve, vagy a honlapon nézve, már nem.
Más esetben fel kell mérni a Mega Menü pontos működését és megvizsgálni, hogy miként lehet hozzá menüelem jogosultságkezelő kiegészítő modult írni, ha lehetséges.
Ha nem lehetséges, akkor magát a Mega Menüt kell átírni, hogy belekerüljön a jogosultságkezelés és megkérni a készítőket, hogy adják hozzá az alapkódhoz, különben mindig külön kel patch-elni, amikor kijön egy új verzió.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Ez ravasz
Erre nem gondoltam, az egész theme kezelést nyelvfüggővé tenni... az i18n_variables -t pedig szoktam ajánlgatni a support listán. Szép.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszönöm
A htmlarea-val az a bajom, hogy telenyomja a tartalmat java scriptel és ez a PHP-beküldésnél picit zavaró:)
Az image_assist viszont ígéretes.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
gd2
azt már kijavítottuk, lerágtam Steven fülét hogy tegye be az egy karakteres javítást, mert az idegeimre mentek vele a #drupal-support -on...
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Na még 1xer :)
Ezt írhattam volna pp-nek is, de azért akkor még egyszer leírom, mert tudom kihagytam, vagy nem voltam közérthető.
Eddig sem arról kellett meggyőzni sem nevergone-t, sem engem, hogy ezek az aggregált hírek mennyire jók és milyen előnyökkel jár az, hogy ide is bekerülhetnek.
Ezt elsőre megértettük, hurrá, legyen sok ilyen hasznos tartalom!
A problémát a drupal.hu fórum témáinak és a direkt a drupal.hu-n létrehozott, a közösséget érintő témáknak (pl.: DUG, Konferencia, stb) a nyomon követhetősége volt.
Egyébként az első importálások után, majd jóval kevesebb aggregált hír jelenik majd meg a tracker első oldalán, de a bloggerek rám is cáfolhatnak ;-)
Igen, én is így gondoltam, csak hogy Goba úgy reagált, mintha nevergone nem tartaná fontos tartalmaknak ezeket az aggregált híreket, így "első felindulásból" javasoltam, hogy akkor jelenjenek meg a címlapon. Persze, azért ez így nem lenne szerencsés, mert azért hagyjuk meg a drupal.hu szerkesztőinek, hogy eldöntsék, hogy melyiket tartják arra érdemesnek, hogy kitegyék a címlapra, tehát most pont jó helyen vannak a drupal.hu/planet alatt.
Persze ez még nem jelent megoldást az általunk felvetett problémára, ezért javasoltam, hogy legyen egy olyan view, amiben a fórum témák és az "itt helyben előállított" tartalmakat tudjuk nyomon követni, úgy mint azelőtt, mielőtt megjelentek volna az aggregált hírek.
Egyébként ha valaki ránéz a trackerre az egyből érti, hogy miről van szó. De a többi ezzel kapcsolatos meglátásaimat, inkább itt folytatom.
Remélem ez már érthetőbb volt és bocs, hogy ilyen hosszú voltam.
Páldi Zoltán