responsive layout, mobil smink
3. úgynevezett responsive layout használata. pl. omega, Responsive , AdaptiveTheme vagy a ráépülő alsminkek egyike
Nagyon jó írás még a témában:
Murray Woodman: Mobile Drupal
Kipróbáltam a mobile_theme modult is, de boost modullal nem tud együttműködni (két különböző smink ugyanazon az útvonalaon)
ha külön mobil sminket szeretnél, és még a boost modult is használod akkor olvasd el ezt a tutorialt (ez az én szerény hozzájárulásom a drupal-hoz)
Making a Boost cached site mobile
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nem értem ezen miért kell
Nem értem ezen miért kell felkapni a vizet.. F*szságot kérdeztem? Már bocsánat... Az i18n_string jónak bizonyul, megnézem... Köszönöm. Nem kukacoskodni akarok, meg semmi de ezt is most látom ebben a hozzászólásban először...
Mellesleg a t() függvényt nyilván nem írják át a kérésemre, nem is EZT akarom.. (mert itt már felmerült a Drupal 8,9,23,23543 stb..) lehet sokan félreétettek... hanem megoldást a problémára. Bár látom, hogy az okoskodáson kívül konkrét megoldás a magyar közösségben nem fog születni (már bocsánat és tisztelet a kivételnek).
Innentől a téma részemről lezárva, köszönöm a válaszokat.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
mégsem biztos, hogy verzióval kapcsolatos
Hali!
Köszi, hogy megnézted!
Viszont közben rájöttem, hogy rossz volt a tesztelés módja nálam:
- a két Drupal 7.15-ös, amin rosszul működik, localhoston, IIS-en fut
- a 7.12-es, amin jól működik, Apache-on, Linux alatt fut; azóta egy 7.14-es Drupalt is próbáltam, annál is jó ugyanezen a platformon
Tehát akkor derül ki, hogy most akkor az újabb verziószámmal vagy IIS-sel, esetleg egy helyi rossz beállítással hozható összefüggésbe, ha a 7.15-ös Drupal is felkerül az éles szerverre, Apache-ra+Linuxra.
Addig is: tudtok erről esetleg valamit, hogy IIS alatt, 7.15-ös Drupallal jó-e ugyanez?
Köszi továbbra is!
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Egy attached image-t akartam
Egy attached image-t akartam módosítani és ez az üzi...
TÍPUS - űrlap
DÁTUM - péntek, 2012, augusztus 31 - 08:27
FELHASZNÁLÓ - admin (ez az egyetlen user)
HELYSZÍN - http://akarmi.hu/?q=hu/file/ajax/field_image/und/0/form-Np6N0ULod7ExvYwi...
HIVATKOZÓ - http://akarmi.hu/?q=hu/node/34/edit
ÜZENET- „Thumbnail image” mezőben érvénytelen kiválasztott érték ().
SZINT- hiba
KISZOLGÁLÓ NEVE 160.114.166.217
MŰVELETEK
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
http://drupal.hu/comment
http://drupal.hu/comment/65962#comment-65962
"de a mező név kapcsán miért nem "igényes" az ilyen elnevezés?"
Ez most komoly kérdés?
Elkészül egy román nyelvű weboldal a szatmárnémeti művháznak. Azt mondják 3 év múlva, hogy akarnak magyar nyelvű részt is, és megbíznak vele. Ugye milyen jó lenne, ha a meglévő 200 fieldnek nem kéne egyesével összeszedni a fordítását, vagy mondjuk egy views_nem_echte_roman_rizsa machine nameből ki tudnád találni, hogy az a views, panel pane, context vagy bármi más mire való?
És ez nem csak machine namere, hanem adminisztratív leírásokra is (megint csak views, panels, context, etc..) vonatkozik.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
És miért kell ez a dupla fordítás?
Köszi a magyarázatot! Amúgy közben rájöttem, hogy abszolút hülyeség volt feltételezni, hogy más path-on nem működik, mivel itt azonosítók kerülnek a fordítandó tartalmakhoz (például szerkesztéskor az URL ilyesmi: admin/config/regional/translate/edit/15150), és nyilvánvalóan nem path alapján azonosít, elképesztő béna lenne... csak nem volt időm már szerkeszteni a hsz.-t, úgyhogy benne maradt.
De a lényegi részére esetleg nem tudod a választ?
Tehát miért kell lényegében duplikált módon fordítani?
Most közben rájöttem, hogy a Main menu-be beraktam más view-t, és ott nem volt szükség erre a külön macerára, de tényleg csak annyi volt a különbség, hogy az a Main menu-be került, nem saját menübe.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszönöm! De localhoston miért kevesebb mégis a mérések szerint?
Köszönöm a választ!
De továbbra sem világos számomra, hogy localhoston a mérések szerint hogyan lehetséges, hogy mégis jóval kevesebbet mutat az XHProf, meg a Devel modul is, ami az oldal összerakásának legvégén kiírja, hogy mennyi volt a peak memory usage?
Amúgy elfelejtettem mondani, hogy localhoston 5.3.8 van fent (ahol nincs para), a szerveren pedig 5.2.17-es verzió. Már ha ez számíthat.
Szerk.:
közben itt kaptam egy választ, ami lehet, hogy igazából megválaszolja a kérdést:
http://prohardver.hu/tema/php_kerdesek_2/hsz_11415-11415.html
Jó gondolatmenetnek tűnik.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Rejtett állapot vagy Views tiltás
Nem tudom pontosan hol van szükséged rá, de a Drupalban van egy ilyen funkció. Méghozzá ha a tartalom beküldésekor elveszed a pipát a "Közzétett" mellől.
Ilyenkor rejtett tartalmat hozol létre, és csak az admin és a létrehozó láthatja. Persze elég felelősségteljes jogokat kell adni a felhasználóknak, tehát akiben nem bízol azoknak ne adj ilyen jogokat.
Ha nagyon szükség lenne ilyesmire, akkor hozzá lehet fűzni a tartalomtípushoz egy mezőt, ami megjelölné, hogy rejtett-e. És a tartalomlistázó nézetekben pedig beállítani, hogy ha ki van jelölve a rejtett mező, akkor az ne jelenjen meg.
Persze ettől még hozzáférhető a tartalom, de nem listázza sehol, tehát a többi felhasználó a cím hiányában nem is találná meg.
Szakmai blogom: blog.serpens.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nagyon jó, köszi, szantog!!!
szantog, szeretném megköszönni a munkádat, amit a modul fejlesztésébe fektettél (meg persze a hozzájárulóknak is). Eddigi próbáim alapján a modulod nagyon jól működik (végre megoldottnak látszik a fájlok megfelelő elérési utakhoz való feltöltése!), szerintem intuitív a kezelése, és igényesen van megoldva, kihasználva a Drupal adottságait (jó kis AJAX az admin-felületen a tartalomtípusok megjelenítésére, stb.). Nem mellesleg a kódja is követhető, bőven felkommentezett.
Végre tényleg azokon az útvonalakon vannak a fájlok, ahol lenniük kell!
A File (Field) Paths modult tehát felejtse el mindenki, és használja a File Entity Paths modult!
Köszi még egyszer, szantog! :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Két dolog
Két dolgot tudnod kell:
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés