Luigi.hu képe

hiányos IT biztonsági tudásáról szólt az a mondatom, és nem az eredeti problémáról. Őket képezni és amennyire lehet, kontrollálni kell, de nem menjünk el ebbe az irányba, mert nem erről szól ez a topic.

0
0
bmazsi képe

Nagyszerű, köszönöm az iránymutatást, máris elkezdem tanulmányozni az infókat (teljesen rossz irányba keresgéltem eddig). Ha sikerül, jelzem hogyan, ahogy látom ezeken az oldalakon, mást is foglalkoztat a kérdés :)
Köszi még egyszer!

0
0
rendszereto képe

Tehát azt állítod, hogy csak az alaprendszer van fent nálad + az Inline és ha az Upload modulnál nem adsz jogosultságot a csatolmányok (pl. képek) megtekintésére, akkor nem is jelenik meg?

Ez meglepne...

0
0
kismocsy képe

Ha az van amit az úr fentebb említett, és arra gondolt amire én, akkor az internationalization modult kapcsold ki, és uninstalláld, ha ezekután jó lesz, akkor bizony valami nyelv kezelés gond van.

0
0
Nagy Gusztáv képe

Ha a címlapon nem híreket, hanem egyetlen tartalmat akarsz, akkor az admin/config/system/site-information oldalon az Alapértelmezett címlap-nak állítsd be a node/x útvonalat, ahol x a tartalmad id-je. (Az URL-ben látszik.)

0
0

Nagy Gusztáv

gpista képe

Én is egy többoldalas bonyolult formot készítek éppen, és én következő képpen oldottam meg az oldalak közötti váltogatást:
Először is mindig az egész formom, tehát az összes oldal lerenderelődik. Az elementek attribúlumai közé létrehoztam egy "#page" attribútumot, amely azon oldalszámok tömbje, amelyen az adott form element meg kell, hogy jelenjen. Utána form_alter()-ben lefut egy függvényem, ami végigjárja az elementeket, és amiknek nem kell megjelennie az adott oldalon, azokat elrejti ($elem["#prefix"] = '<div style="display: none">', $elem["#suffix"] = '</div>'). Így az előző oldalakon megadott értékek mindig ott vannak POST-ban, nem kell session-ökkel szívni, még a böngésző frissítését és a historyban előre-hátra ugrálást is jól tűri a kód.
Ezen kívül minden gombom submit gomb, az előre-hátra navigációs gomboknak van saját submit függvénye megadva a "#submit" attribútumban, a legvégső, ultimate submit button, ami végleg elmenti a formot, csak az utolsó oldalon jelenik meg, addig rejtett. A navigációs submit függvény megnöveli(vagy lecsökkenti) az aktuális oldal számát (amit hidden fieldben tárolok minden oldalon) és $form_state["rebuild"]-et TRUE-ra állítja, így a form újra felépül, de másodjára a form_alter-ben a láthatóságot kezelő függvényem már az előző/következő oldalon lévő formokat teszi láthatóvá. Viszont ha a validáción elbuktak a megadott adatok, akkor a navigációs submit függvény meg sem hívódik, így az aktuális oldalszám se fog változni, a felhasználó visszakapja ugyanazt az oldalt, ahol éppen járt.
Ez mondjuk Drupal 6-tal van így, de hasonló úton érdemes elindulni 5-ös Drupalban is szerintem(ott talán nem $form_state["rebuild"] van, hanem a form létrehozásánál kell a form #multistep attribútumát TRUE-ra a #redirect-et meg FALSE ra állítani, de ennek nézz utána jobban). Drupal 5-ben nem tudom, hogy pont így meg tudod-e csinálni, én abban buttonokat használtam submit helyett(a buttonokra kattintva nem hívódik meg a submit függvény), és a formnak #pre_render-ben megadott függvényben növeltem meg csökkentettem az aktuális oldalszámokat, de ez egy elég béna megoldás volt, a validation-nal is voltak gondjaim.

Ha az egész formom elkészül, és működik rendesen, lehet, hogy csinálok belőle egy tutorialt, mert vannak benne szerintem érdekes megoldások, amik másoknak is hasznára lehetnek(ismétlődő, többször megadható fieldsetek, amelyek módosíthatók/törölhetők, többoldalas navigáció, stb.).

0
0
Robert Petras képe

Ismét csak oda lyukadunk ki, hogy Te is úgy gondolod, hogy a számítógépet használók és az interneten böngésző emberek tisztában vannak a gyorsbillentyűk használatával és ismerik a böngészők kiegészítő funkcióit. Nincs ezzel semmi bajom azon kívül, hogy én épp az ellenkezőjét gondolom. Szerintem többen vannak akik nem használják ezeket, mint akik ismerik és nekik lehet, hogy igen is problémát jelent a kis betűméret.

Az, hogy ettől miért válik egy böngésző- és eszközfüggetlen az interaktivitást segítő weboldalba beépülő funkció fölöslegessé így általánosan a szemedben, azt nem tudom. Gondolom, hogy pl. egy a tartalmat, kategóriát, kulcsszavat szűrő blokk használata nem zavarna ennyire, mint az "elegánsan" (hi-hi, ezt jól megkaptam Tőled) elhelyezett egyéb elemek/eszközök.

Tök jó, hogy írod, hogy egy jó layout és stíluslap megoldás lehet a problémára. Én is így gondolom, mint ahogy sokan mások is. Az internetes oldalak megjelenési felülete egyszerre szűkül be az okos mobiltelefonok használatának elterjedésével és egyszerre tágul ki a monitorok méretének/felbontásának bővülésével ill. az újabb internet befogadó eszközök pl. a TV készülékek használatával. Egy okosan elkészített weboldal simán lekezeli ezt. Egyébként is erre megy a trend, nem ritka a 16-18pt használata a kenyérszövegre azaz bekezdésre alkalmazva.

Azt nem tudom pontosan, hogy mit értesz azon, hogy a "táblagépek ugyanis a viewport tetejére tappolással mind az oldal tetejére scrolloznak" és hogy miért rossz ettől a fenti példám. Az biztos, hogy az iPhone telefonom nem megy sehova hiába tappolom a weboldal alján, vagy csak én nem tudom, hogy hol van a viewport... ;-)

Twitter mobil alkalmazásom szereti a saját frame-ben megjeleníteni a külső hivatkozásokat, ergo rejtve marad a böngésző/oprendszer chrome, szóval itt biztos megszívom, mert mégiscsak nekem kell felfele scrollozni. Tudom, tudom van arra is lehetőség, hogy az a fránya link mégis csak a mobil Safariban nyíljon meg (én is ezt szeretem használni).

Egyébként az összes táblagép tudja ezt a funkciót, márkára és op. rendszertől ill. kiadástól és böngészőtől függetlenül? Ha igen akkor szuper.
Az iOs szimulátort használva keresem ezt a funciót az iPad nézetnél. A képernyő tetején megjelenő fekete infromációs sávra gondolsz? Az tényleg a weblap tetejére visz ha kétszer tappolok rá, de ezt csak most tudtam meg tőled, eddig ez nem volt egyértelmű a számomra (miért is tappoltam volna csak úgy magamtól a toolbarra?). Mindegy, holnap elmegyek a helyi t-mobilos bemutató terembe és megnézem ezt az android készülékeknél is.

Az akadálymentesített stílussal is teljesen igazad van (valaki szólhatna már a minisztériumban és az EU-s pályázatok elbírálóinak erről...).
Ha készítek egy szimpla HTML oldalt mindenféle CSS stíluslap nélkül, akkor 100% biztos lehetek abban, hogy az nemcsak "akadálymentes" hanem még mobilbarát is lesz, reszponzív!

Igazad van abban is, hogy a Drupal.hu tökéletesen akadálymentesített, hurrá! Most így a fórum textarea-ban írva nekem semmi gondom nincs a kontraszttal és fontmérettel, mert jó a szemem. A gyengénlátó segítségre szoruló tagok pedig biztos használni fogják a CTLR+ kombinációt... no problem.

Amúgy vágom, hogy mire gondoltál és részemről teljesen ok a dolog, ezen nem veszünk össze szerintem.

1
0
Anonymous képe

Nem a sávszálesség a gond, hanem az idő. Most is kb 3 percem van net elé ülni, utána irány az autó, és megkezdem a napi anyagbeszerzést. Esetleg mobilról menne az olvasás ha dugóba kerülök, ki fogom próbálni!

0
0
Hojtsy Gábor képe

A válasz szerintem nem az, hogy itt hogyan csinálja a kérdező, hanem az, hogy mindig olvassa el modulonként a telepítési leírást. Ha nem olvasta el, az nem kifogás, ha elolvasta, de nem érti, akkor jöhet a kérdés.

0
0
kubrob képe

Koszonom szepen az infokat. Legalabb tudom hogy nem lehet hasznalni az utazasokhoz e-commerce! Tul bonyolult a feltoltes. Nembaj. A cuccot elkuldheted az e-mailemre. Lehet valamit meg kiokoskodok. (4.7est hasznaloko). Megyegyszer koszonom szepen.;)

0
0