Formokat gyártok,
Formokat gyártok,
custom submit handlereket is. Ezzel nincs bajom. A két fent vázolt űrlap is ilyen. EGY formot akárhogy kezelek, multistep-es verziókkal is dolgozok minden probléma nélkül.
A fenti példában - kérésben - KÉT DARAB form van, nem egy, nevezzük őket A és B formnak.
"A" form blokk pozícióban van, kint az oldalsávban - mint pl. a kereső textbox -, "B" űrlap meg az egyik oldalon szerepel. Értelemszerűen, "A" űrlap minden oldalbetöltődéskor látszik, mert ő fixen ki van téve az oldalsávba, de "B" csak akkor, ha egy bizonyos oldalra megy a user.
"B" form egy multistep form: az első, elküldött értéktől függnek a következő oldalon látható értékek. Itt szöveges értékek is vannak, mindenféle kiiratások - egyszóval sok látható anyag, azért van itt a középső, tartalmi részben ez az űrlap, hogy jól elférjen.
"A" form csak egy sima szövegdoboz-submit gomb páros. A feladata csak annyi, hogy bármelyik oldalról meghívható legyen.
A feladat az lenne, hogy az "A" formba beirt és elküldött érték úgy jelenjen meg, mintha a "B" első lépéseként küldték volna el. Vagyis "hajtódjon végre" "B" form első submitja IS, az "A" formba beírt értékkel.
Próbálkoztam jQuery-vel átadni az értéket a "B" formnak és szintén jQueryvel submitolni is. Próbálkoztam GET-es értékkel az adott oldalnak átadni az "A" űrlapból submitolt értéket és ezt figyelni "B" formban. Elképzelhető, hogy bármelyikkel megoldható a dolog, de nekem nem jött össze...
---------------
Tátrai József
Drupler Kft.
http://www.drupler.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A Google keresőt mondjuk
A Google keresőt mondjuk elfogadhatónak tartom, bár nem vagyok híve a mindent kívülről megoldásnak. A Drupal végülis elég jó ahhoz, hogy saját keresője legyen, nem?!
Angol nyelvű honlap: ezt inkább meg sem hallottam...
A naplózást kikapcsolhatom, bár a profik (amilyen még nem vagyok) nem abból szokták kitalálni, mi a baj, ha éppen baj van?
A 100 MB-os korlát tényleg dühítő, de ismert tárhelyszolgáltatót akartam és máshol, ahol nagy volt, ott a tárhely volt brutálisan kicsi, 500 MB és majdnem dupla volt az előfizetési ár.
Egyébként próbáltam egyezkedni az adatbázismérettel kapcsolatban, mondván, hogy nem használom az 500 MB-os e-mail tárhelyet, mivel Google Apps-ot használok, de nem voltak vevők az ötletemre, inkább azt szeretnék, ha vásárolnék 100 MB-onként 2000 Ft + ÁFÁ-ért plusz adatbázist.
Mellékesen: ha plusz 1 GB tárhelyet akarnék, az 10 ezer!!! + ÁFA
Visszatérve: mint korábban írtam, az meglepő, hogy 63 MB volt tegnap előtt, nem csináltam pedig előtte 1 napig semmit. Írtam nekik, miután másnap 47 MB lett, pedig azt mondták nincs mit tenniük, váltsak át myISAM-ra.
Az érdekes, hogy a phpmyadmin-juk még a 2-es verziót nyomja és az InnoDB táblák alján az összesítő myISAM-ot ír és a karakterkódolás is más, mint a táblákban, ugyanez az adatbázis a localhostomon, ahol 3-as a phpmyadmin, rendesen InnoDB-t mutat az összesítő sor is (mint korábban mellékeltem a képet) és helyes karakterkódolást...
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
PHP 5 támogatás
Ez ugyan nem szerepel a bejelentésben (még?), de elméletileg a Drupalnak ez a verziója már PHP 5-el is jól elfut. Többen hónapok óta használtak PHP 5-el Drupalt gond nélkül. Persze mint kiderült, főképp az xmlrpc és az xtemplate támogatásban voltak gondok (melyeket az említett tesztelők nem használták), de ezt is megoldották az utóbbi napokban.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nekem ugyanaz a problémám,
Nekem ugyanaz a problémám, azzal az eltéréssel, hogy a böngészőben a cookie nem is jön létre, és a honlap nem aldomain-ként érhető el. A drupal alatt a SESSIONS táblában két bejegyzés, 1 és 0 uid-al.
Drupal 4.7.6
MySQL 5.0.24a
Az érdekes az, hogy egy ideig már működött az oldal, és egyszer csak nem.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszönöm válaszodat!
Köszönöm válaszodat! [http://www.snap.com/about/shots.php] -tehát ő lenne az. Az oldalon link fölé viszed az egérmutatót, akkor megjelenik egy kis betekintő ablak, egy előnézet a hivatkozott oldalról. Megpróbáltam az aktuális smink page.tpl.php fejrészébe illyeszteni a scriptet, de nem műxik. Más ötlet eseleg?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
alázás?
Arra próbáltam röviden és tömören felhívni a figyelmet, hogy a probléma az, hogy a Drupal fórummal nem vagy megelégedve, nem pedig az, hogy hogyan tudsz phpbb-t telepíteni. Hogyha az eredeti problémát vizsgáljuk, és nem valami levezetését, akkor kiderül, hogy erre jelentősen eltérő megoldások is adódnak, például az eredetileg magyar fejlesztésű (Négyesi Károly) flatforum modulból kiindulva.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Sajnos valmi hasonló
Sajnos valmi hasonló problémám van nekem is az oldalamon (http://hnje.hu/portal) anyi különbséggel, hogy nálam a Firefox tökéletessen jeleníti meg az oldalt, de az IE a fejécet és az elsődleges menüt nem. Ha valakinek van 5lete akkor segítsen, mert sajna nem igazán értek a css-hez.
Norbiii
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Igen
Szia, köszönöm a választ!
Igen megadtam, különben adminisztrátorként sem látszana.
Viszont közben megtaláltam a megoldást!
Az ACCESS CONTROL oldalon a filter module szekcióban a csoportnak kellett engedélyeznem az administer filters beállítást, így most már a kérdéses felhasználói csoport FULL HTML-ben adminisztrálhatja az általam kijelölt nodeokat!!!!!
Nagyon köszönöm még egyszer az ötleteket! :)
e.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Firebug
A webdeveloper őskövület. Használj firebugot, az azonnal mutatja, hogy a #header-inner valóban 100px magas, csak (az egész #page-inner-rel együtt) el van tolódva lefelé 10px-szel. Némi nézelődés után az is látszik, hogy a #logo-title felső margója tolja le (hogy miért, az nekem se világos, de egy margin-padding cserével könnyen javítható).
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Szépség relatív.
Az előfeldolgozó szerintem arra való, hogy megváltoztassunk, vagy hozzáadjunk változókat nem pedig arra, hogy töröljünk. Ráadásul nevergone megoldása szerintem warningot, vagy legalább is noticet fog eredményezni, mert a $title változó nem létezik és azt használják az if-ben. Az
unset()helyett tehát$title = ''lenne ebben az esetben a célravezető.Nevergon megoldása jó lenne abban az esetben, ha a kérdező azt kérné, hogy "ne legyen cím". Persze abban az esetben is csak arra lenne jó, hogy rámutasson: tessék pontosan kérdezni. Ebben az esetben viszont a "cím éltüntetését" kérik, márpedig ennek a legjobb megoldása az amit Te adtál. Itt ugyanis pontosan az történik amit a kérdező akar. Ráadásul a későbbi fejlesztések, vagyis az oldal normális élete során is egy jobban áttekinthető és karbantartható valamit kapunk. Ha ránéz valaki a sminkre akkor pontosan fogja látni, hogy mi az ami más, hisz ez a fájl nevében kódolva van. Hogy miért más azt pedig egy diff-el könnyedén kiderítheti, nem beszélve arról, ha a spec template elejére még egy megjegyzést is beletol a készítő.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu