Sziasztok!
Új tartalomtípust hoztam létre.
Telepítve van az Inline, hogy a csatolt képek automatikusan megjelenjenek.
Ahhoz, hogy ez megtörténjen a következő beállítást kell elvégezni:
Beágyazó szűrő: PIPA
Kicseréli az [inline:xx] jelölőket az állományhoz tartozó xx-edik számú csatolt állománnyal.
Ezen kívül a "Webhely beállítása" résznél a Beágyazott almenüben a "Csak a kép megjelenítése" részt kell megjelölni és megfelelően megadni a képméretet az oldal alján.
Ha ezek megvannak, akkor működik is a dolog.
De csak akkor, ha a rendszer által készített Tartalomtípusnál töltünk fel képet.
Ha csinálunk egy új tartalomtípust, annál nem.
Hogy miért nem?
Hát ezért:
A csatolt fájlok automatikus megjelenítése:
Tiltott
Csak a bevezetőben
Csak a teljes nézetben
Az bevezetőben és a teljes nézetben
Itt értelemszerűen a tiltott megjelölésen kívül mindegyik megfelelő ahhoz, hogy működjön a dolog.
Viszont ha egy új tartalomtípust csinálunk, ott a rendszer egyszerűen nem engedi ezt a jelölést, minden esetben mentés után visszaáll a Tiltott beállításra, következmény: nem működik a képek automatikus megjelenítése ebben az esetben.
Minden létező beállítás variációt végigpróbáltam, ugyan úgy beállítottam a tartalomtípust, mint az alap Írás, vagy Oldal esetén, de akkor sem engedi a Tiltott beállítás megváltoztatását.
Ki akartam próbálni egy szűz, újratelepített alap Drupal esetén, hogy engedi-e ezt a beállítást a rendszer egy új tartalomtípus esetén, de természetesen ilyenkor nem jelenik meg ez a beállítás lehetőség, mivel azt az Inline teszi be.
Lehet, hogy az Inline hibázik, de lehet, hogy az alaprendszer.
Van valakinek megoldási javaslata? (Azon kívül, hogy ne használjak új tartalomtípust :-)
Mysql
Van valakinek tippje, hogy az adatbázisban hol található ennek a beállítása?
A csatolt fájlok automatikus megjelenítése:
Tiltott
Csak a bevezetőben
Csak a teljes nézetben
Az bevezetőben és a teljes nézetben
Böngészem már jó ideje különféle elképzelt szavakra keresve, hátha rálelek, de csak nem.
Mert jobb híján megpróbálom így belülről rákényszeríteni a rendszert, hogy jól működjön.
Azért a teszt környezetbe még
Azért a teszt környezetbe még ajánlott feltenni az inline modult, más kiegészítőket viszont nem. Enélkül nem sok értelmét látom a tesztelésednek.
Nagy Gusztáv
Nem értem miért mondod: fent
Nem értem miért mondod: fent van az inline modul, és csak az.
Beléptél?
Próba
Most ismét telepítem a tesztoldalt és még egyszer kipróbálom, ha sikerül megint, akkor leírom a megoldást. Persze ettől a modul még nem lesz jó, de legalább van megoldás.
Nem, nem léptem be
De te ezt írtad:
Én ebből arra következtettem, hogy az Inline modult nem tetted fel a teszt környezetben.
Nagy Gusztáv
Megoldva
Nem tudom leírjam-e, mert úgy látom nem sokakat érdekel az Inline használata, de ha már többszöri nekifutásra, nem kevés keresgélés eredményeképpen megtaláltam a megoldást, leírom:
Hogy hol lehet az adatbázisban állítani, ha a felületről nem sikerül az új tartalomtípusnál megadni, hogy automatikusan jelenjen meg a kép, amit beillesztünk:
Variable tábla, azon belül található az a rész, hogy:
upload_inline_nev, a név helyett természetesen a saját tartalomtípus neve fog szerepelni.
Itt "0/1/2/3"-as értéket vehet fel a mező, ami rendre a "Tiltott/Csak a bevezetőben/Csak a teljes nézetben/Az bevezetőben és a teljes nézetben" beállításnak felel meg, ami az Általános beállítások "A csatolt fájlok automatikus megjelenítése:" részben található a rendes felületen.
Van egy szépséghibája a dolognak: bár a beállítás így megmarad és működik is a képek automatikus megjelenítése, viszont ebben a menüben, mármint a drupal felületen a saját tartalomtípusnál továbbra sem jelzi a beállítást, hanem a "Tiltott" van bejelölődve, így nem lehet tudni később, hogy mi is van beállítva, ahhoz bele kell lesni az adatbázisba.
Nem vagyok (még) programozó, de valószínűleg külön kezeli a rendszer a beállításokat és azok megjelenítését a felületen. Ha ráhibáztam, akkor ennek a kettőnek a kommunikációjában lehet valami hiba.
Ha érdekel valakit és eláruljátok, hogy magát a megjelenést (ami gondolom független a sminkektől) hol kezeli a rendszer, akkor ezt is megkeresem.
ne hasznaljad az upload modult
multbeli kisertet az, hetesben mar nem is lesz.
filefield -et hasznaljad.
-
clear: both;
Sikerélmény :-)
Nekem azért sikerélmény, hogy mindenféle programismeret és adatbázis ismeret nélkül megtaláltam abban a rengetegben a szükséges részt :-)
FileField
OK, elkezdtem ismerkedni a Filefield-del. De sehogy se akarta megjeleníteni egyből a képet, ahogy az Inline.
Aztán feltettem az Imagefiled-et is és az már megtette ezt a szívességet nekem.
Tehát:
Filefield: helyettesíti az Upload alapmodult (csak többet tud)
Imagefield: helyettesíti az Inline modult (ez is többet tud)
Gondolom sokaknak ez már tudott volt, azok ne olvassák el :-)
nem
Nem, ez nem így van.
A Filefield egy általános feltöltő modul, fájlok csatolását teszi lehetővé tartalmakhoz... izé, entitásokhoz, de ez majd később játszik be.
Az Imagefield speciális dolgokat valósít meg a Filefield-re alapozva. Az Imagefield le tudja kezelni a képek speciális tulajdonságait (pl. megjelenítés, ugye egy ZIP fájlon nincs mit megjeleníteni, de egy JPEG-en van), itt megjelennek olyan tulajdonságok is, mint a kép szélessége, magassága, stb.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Kár
Kár, mert jó volt az hinni, hogy ilyen egyszerű :-)
Entitásokat? Tehát arra való a Filefield, hogy anyagokat töltsön fel, általánosságban. Azt, hogy milyen tartalmat, azt pl. az ilyen Imagefield kiegészítők, illetve a létrehozott típusok határozzák meg, pontosabban nem is határozzák meg, csak jelzik.
Mindenesetre az Upload modult kikapcsoltam és az Inline-t letöröltem.
Filefielddel töltöm fel a képeket, pontosabban Imagefielddel, ami ha a listázást a képnél nem jelölöm be, akkor rögtön a képet jeleníti meg, tehát amit akartam, így is elértem.
Most jön az, hogy a Filefield jogosultság kezelő almodulját is beizzítom, hogy hozzáférési jogokat adjak a tartalmakhoz, amit az Upload az Inline-nal úgy sem csinált jól.
Amikor kerestem ezeket a modulokat az orgon, láttam, hogy 7 ezer modul van.
Ez borzalmas. Mert ha lenne mondjuk 100, az is elég lehetne mindenhez, de ekkora mennyiséget ismerni, tesztelni, összerakni... nem is értem minek ennyi. Látatlanban is biztos vagyok benne, hogy ezek nagy része fedi egymást.
Szerintem kellene csinálnia egy komolyabb szűrést a drupal.org közösségnek és nem engedni, hogy bizonyos dolgokat ennyi féle modul oldjon meg. Ha van működő és hibamentes megoldás már, akkor pont, ne engedjenek több modult abban a témában feltenni.
Na, biztos nem ért ezzel sok mindenki egyet, sőt ez off téma itt.
Itt se voltam :-)
ilyen szempontbol teljesen onszabalyozo a kozosseg
neha elhalnak modulok, maskor egyik modul beleolvad a masikba, ha nagyon hasonloak, stb. joomlahoz pl szamszeruen tekintve sokkal tobb "modul" van, "cckbol" pl mindjart van vagy negy fele :) szoval ilyen szempontbol mondhatjuk, hogy a drupalhoz meg keves is a modul :D
-
clear: both;
Javaslat
Javaslom, hogy csináljunk egy olyan fórumtémát, ahol mindenki megjelölheti, hogy milyen modulokat használ általában. Olyan formán, hogy az újakat be lehessen írni, de a már beírtakat egy legördülő menüből kiválasztani. Így lenne egy listánk arról, hogy melyek a legnépszerűbb modulok és így tudhatnánk, melyekről érdemes itt értekezni. Így Inline-okról nem kell fölöslegesen témát nyitni, mert úgyse használja senki, viszont a fontosabbakat még jobban megismerhetné mindenki és úm. közösen tesztelnénk ezáltal.
Ez a tudásbázis készítést is elősegítené, mert szervezettebben történnének a hozzászólások, kielemzések.
volt ilyen ötlet
Volt ilyen, összeírós ötlet, el is halt szépen. Ezért inkább a linkek beküldésekor szoktuk leírni a használt modulokat. Amúgy nem gond, ha sok modul van, némi redundancia belefér, legalább van miből dolgozni. Tudsz válogatni, hogy melyiket mennyire fejlesztik, tartják karban, javítják a hibáit. Érdemes megnézni, hogy egy adott modult hányan használnak, ez is segít a választásban. :)
Ui.: Amúgy érdemes lenne megnézned azt az email-címet, amivel ide regisztráltál. :)
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Megnéztem
Megnéztem és erősen gondolkodom rajta. Kösz!
Csak úgy kiváncsiságból: miért nem tesztek fel ide egy alap szövegszerkesztőt? Nem kell engedni a hülye smile-okat, meg túlzott formázást, csak legalább kód beírása nélkül lehessen fettelni, kurziválni, idézni...
bueditor
Mert az ilyen szövegszerkesztők eléggé csűrik-csavarják a kódot, és sok olyan dolgot is beleszemetelnek, aminek nincs helye bent. Ha nem hiszed, nézd meg egy Word-del készített HTML oldal forrását. :)
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Word
Tudom, meg egyes html szerkesztőkre is igaz.
Ha jól értem a szemetelés azért baj itt nektek, mert az nehezíti, amikor a tudásbázist összekattintgatjátok itt a jó válaszokból.
Bár akkor a beírt formázó kódok is zavaróak lehetnek...
nem
Nem, a "szemetelés" azért baj a legtöbb oldalon (nem csak itt), mert az ilyen tartalmak kinézetét utána nehéz úgy megformázni a CSS segítségével, hogy egységes hatást keltsen.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
nyitott kapukat dongetsz
http://drupal.org/project/usage
tessek, "nepszerusegi" statisztika, havi bontasban.
http://drupalmodules.com/
tessek, kozossegi ertekeles
egy olyan rendszerrel ismerkedsz, ami 10 eves es a drupal.org felhasznalok szama tobb, mint 700 _ezer_ ... 7000 modul az nokedli, par ev mulva tobb tizezer lesz, foglalkoznak is vastagon a "minosegbiztositas" mikentjevel, ne felj. :)
-
clear: both;
Az nem ugyanaz
A népszerűségi statisztika az egy dolog (annyi minden népszerű a világban, az még nem feltétlenül jelent minőséget is).
A közösségi értékelést megnézem, mert így első blikkre ez majdnem ugyanannak látszik.
A redundancia önmagában csak bonyolítja a dolgokat. Ez olyan, mintha két középkategóriás autó közöl lehet választani, csakhogy itt van mégis különbség (pl. design), egy programfelületnél ha sikerült megoldani valamit és jól, tök fölösleges még másik 11-et csinálni.
Az az egy lehet érv, hogy lehet, hogy egyiket-másikat nem fejlesztik tovább. De ez éppen azért van, mert sok van ugyanabból és nem volt értelme. Ha viszont kevés van, akkor közös érdekből úgysem marad árván.
Ez itt már teljesen off téma
szóval szerintem érdemes lenne itt ezt abbahagyni. Ha bármi ilyes fajta észrevételed van, írd meg egy blogbejegyzésben, ircen szivesen elmélkedem veled de ezt itt most hagyd abba kérlek.
--
Borsa Péter
https://peterborsa.eu
egyetértek
Egyetértek, nagyon eltértünk a tartalomtípusoktól és azok beállításaitól.
Szerintem ebben a témában már megbeszéltük amit kellett, irány vacsorázni, egyéb kérdések pedig új téma! :)
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
ne szaladj már ennyire :)
az nem népszerűségi, hanem használati statisztika. hány site használja x modult mikor. :) elég hasznos információ.
szerintem itt senkinek nem kell elmondani miért gáz, ha "redundancia" van.
azért gondold azt át, hogy a nagyon absztrakt modulokból amik igazi építőelemgyárként funkcionálnak, mint cck, token, views, rules, panels, ctools, csak egy van. sőt ezek idővel másokat tesznek feleslegessé, pl én nemigen látom a notifications értelmét, "most" már, hogy ilyen fejlett a rules. :) vagy nemtom hogy fogalmazzam meg ezt.
azt szeretem a drupalban, hogy gyönyörűen fejlődő cucc, szép absztrakt megoldások születnek ahogy halad az idő. régen pl nem volt views, ha te egy listát akartál a nodejaidról modult kellett írnod. aztán született száz modul, ami ilyen-olyan listákat gyártott a nodeokból, némelyik csak egyet, mások többet.
aztán egyszercsak előállt egy tag ilyennel, hogy legyen egy query builder, hívjuk mondjuk viewsnak. milyen elegáns név amúgy.
na ettől eleinte sokan idegenkedtek mert sok mindent nem tudott, sok kompromisszumot kellett kötnöd. fejlesztették, fejlesztették..
most meg teljesen alap eszköz a kezedben, igen erős cucc.
(halkan a 3.x, drupal7ben olyanokat fog tudni, eláll a szava mindenkinek)
az "api modulokból" is csak egy van, pl votingAPI... erre épülhet aztán bármilyen értékelésekkel operáló egyéb modul. fivestar pl.
százával vannak apró modulok, amik "kicsi" de speciális feladatot látnak el, mondjuk egy fizetőkapu x holland bankhoz vagy egy apró modul ami egy kis jquery widgetet szúr be valahova, mint pl a sexy_exposed.
jó példa ami a wysiwyg editorokkal történt. nemrég volt még minden lehetséges editorra külön modul. tinymce modul, fckeditor modul, stb. na, több se kellett, csináljunk inkább egy wysiwyg apit, hívjuk wysiwyg modulnak és egyen meg bármilyen editort amilyet akarsz, de jó móka lesz. (lehet nem volt ilyen könnyed:)
és tadaaa, ma már wysiwyg modult raksz fel és alárakod az editort amit akarsz. akár minden usernek másikat :)
csak arra akartam rámutatni, hogy szerintem nem kell aggódnod a "redundancia" miatt, ez a környezet pont nem az a "van már négy féle ccknk is, dejókvagyunk" hely. :)
-
clear: both;
LEGO
Még annyit hozzátennék aboros nagyszerű okfejtéséhez, hogy a Drupal világ olyan, mint egy nagy LEGO, több szempontból is.
Például kevés modul létezik "egymagában", mert a modulok is egymásra építkeznek, mint ahogy te építesz rájuk az oldalad készítésekor. Ilyen a Filefield -> Imagefield is, az Imagefield készítője megírhatta volna nulláról a egészet, de nagyon ügyesen nem tette. Mivel az Imagefield is fájlfeltöltés, csak annak egy speciális esete (csak képek), ezért felhasználta az Imagefield modult arra, hogy amit abban mr megírtak jól, azt az ő moduljának csak használnia kelljen.
Sok modul van így, elég megnézni, hányan hivatkoznak a CCK-ra vagy a Views-ra, ez így van jól.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
entitás
Nézd csak meg az Upload modult, mit tud? Tartalmakhoz fájlokat csatolni, de azok megjelenítésébe már nem igazán tud beleszólni, és nem is bővíthető.
A Drupalos jövő ugyanis nem ez, hanem az entitások. Az entitás "minden, ami valami". Entitás a tartalmad, a hozzászólásod, a kategóriád eleme, a felhasználói profilod, stb. Egy gyűjtőfogalom arra, amit az oldalad kezed. Ezeknek az entitásoknak pedig mezői lehetnek, fájl, kép, dátum, meg amiket régebben említtettem már neked. Ezeknek a mezőknek tudod szabályozni a megjelenítését, lehet olyan mező, amelyik egy másik mező speciális változatát hozza létre (pl. Filefield -> Imagefield).
Erre halad a Drupal, ezért is került bele a CCK a Drupal 7-be Field API néven, hogy akkor se legyen gond, ha nem tartalomhoz, hanem a hozzászólásomhoz szeretnék képet csatolni.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Hát lehet, hogy elment OFF
Hát lehet, hogy elment OFF topic irányba a beszélgetés, de nagyon élveztem olvasni, sőt egy csomó új dolgot is megtanultam. :)
Néha ilyen is kell!
Gazsesz