nem értem a kérdést
Melyik Drupal verzió? Milyen sminkről van szó? Az átírás melyik fájlban történik (page.tpl.php, template.php)? Mit jelent az, hogy átírsz egy dátumot – valahol bele van kódolva a sminkbe egy dátum??? Csak adminként nem tudsz belépni? Csak az adminnak ad üres képernyőt?
(Egyébként az első tippem az, hogy itt valami karakterkódolási probléma lehet – például a template fájl ANSI, te pedig megpróbálsz ékezetes karaktereket írni bele.)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
A sminket nem én
A sminket nem én készítettem, ahogy az az oldal bal alján is látható. Mindenesetre az eltávolítása után már jól működik minden. Kösz a segítséget.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Jquery + PHP el tudod
Jquery + PHP el tudod menteni az adatbázisba, az új oldal lekérésénél pedig az adatbázisból kiolvashatod. A sütit meg hagyd, hogy a nagymama süsse ;)
...mit tudok: http://web.termuves.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Get -> link
Ha get metódussal adja át az adatokat a form, akkor egyszerűen az url-be is bele tudod kódolni az adatokat.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
mysql limit
szerintem tul nagy meretu az az adat amit az update status kezel, es mentes kozben a mysql tullepi a beallitott idokorlatot vagy memoria meretet.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Nem nehéz elképzelni
Van 100E node-od, mindegyik alias-olva. Ekkor: elindul az oldal lekérése, megvan az útvonal - ahhoz az alias. Ha elavult az alias, akkor kikeresni, mi az új és átíriányítás.
Másik, a webszerver konfigban: jön egy útvonal, illeszkedik rá a minta, átdobom a másikra, az újra.
A dupal (de bármilyen cms rendszer) már az új alias-al találkozik csak. Nincs felesleges db művelet az átirányítás miatt.
A web szerver konfigban a legjobb ez, mert ott a webszerver indulásakor egyszer értelmezi az átirányításokat. Cserébe akkor is a memóriában csücsül, mikor nincs rá szükség.
Ha a .htaccess-be teszed, akkor minden lap kiszolgáláskor értelmeződik. Helyet, időt visz el, de még mindig nincs db művelet.
A global redirrel pedig db művelet is van.
Neked kell eldönteni melyiket alkalmazod, miért. Le kell tesztelni mindent és a számotokra optimális megoldást alkalmazni, amit elbír a szerver, ha az a limit.
Ha nem pár száz redir van csak, akkor én .haccess-be tenném első körben a global redir helyett. Shared hostingon úgysem fogsz a szerver konfighoz hozzáférni, illetve, szinte kizárt, hogy egy rendszergazda mindig beállítgassa neked, amikor szükséges a módosítás.
--
Szabó Dénes - Internode.hu - Munkára fogott weblapok
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszönöm a gyors válaszokat.
Köszönöm a gyors válaszokat. Sejtettem valami ilyesmit már akkor amikor rájöttem, hogy ha a nézetben kattintok rá az egyik tartalom linkjére akkor az utána "eltűnik".
Csak gondoltam hátha, esetleg IP alapján történne az azonosítás, bár akkor meg a többfelhasználós hálózatok felhasználóinál lenne totál káosz akik egy szerver (1 IP) mögül vannak. De így jobban megnézve tényleg a drupal.hu-n is az ubuntu.hu-n is eltünnek ezek a flag-ek ilyenkor. És akkor ezért rakja ki fölöslegesen az összes tartalmat visszamenőleg. Jobban belegondolva tényleg logikus. Bár engem akkor is zavar egy picit , hogy fölöslegesen listázza ki az összes tartalmamat. Esetleg el tudok képzelni egy olyan megoldást, hogy a nézetben beállítható legyen egy időintervallum meddig tekinthető újnak és frissnek a post es update időtől és így ettől az időtől függne, hogy megjeleníti vagy sem. (igaz, hogy ebbe is belekössek magamba így megeshet az az eset, hogy a frissült tartalom újra frissül és nem kelti fel a figyelmemet mert azt hiszem az előző frissítés miatt van még kint a frissült felirat. MErt pont azt akartam, hogy nem a dátumokat kelljen böngészni, hanem legyen egy figyelemfelkeltő flag).
Mégegyszer köszönöm.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Mindent a helyére
Submit függvényben már nem kell ellenőrizni semmit se, mert az összes ellenőrzés és form_set_error() hívás már megtörtént a *_validate() függvényben. Ezt így kell és pont.
Az nem tűnt fel, hogy amikor (szerinted) hibás az űrlap kitöltése és sikerült az átirányítás, akkor eltűnik minden adat az űrlapból, és lehet elölről kezdeni a kitöltést?
A $form_state['redirect']-nek úgy kell átadni a paramétereket mint az url() függvénynek. Tehát a fragment rész is megadható. De szerintem nem ez a helyes megközelítése a problémának.
Próbáld meg azt, hogy a $form['#action']-t helyesen kitöltöd. (Normál esetben ezt nem kell piszkálni) 'mymodule/path#mymodule-form'. Ebben szintén segítségedre lehet az url() függvény.
Az hogy ne az oldal tetején legyenek a hiba üzenetek, az már egy trükkösebb probléma.
Még egyiket sem próbáltam, de van rá modul. Több is.
http://drupal.org/project/inline_messages
http://drupal.org/project/ife
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Views Autocomplete Filters
Megszületett a megoldás!
Először is köszönöm mindegyikőtöknek a nyűgömre szánt időt. Különösen köszönöm Istvánnak a tesztoldalt, ennek az áttanulmányozása nyitotta fel a szemem.
Amit az elejétől fogva kerestem, az a views_autocomplete_filters modul.
Az István megoldása nagyon elegánsnak tűnik számomra és borzasztóan tetszik, de ez az entitás dolog még egy kicsit kemény dió nekem. Az agyam még nem fogja fel a nem tartalomtípusba helyezett tartalmak mikéntjét. Tudom, hogy ez is a jövő része, küzdök is vele, hogy megértsem.
Szóval, az adatok egy excel táblában vannak .xlsx formátumban. Azért ebben, mert ebben kapom meg és nem kell konvertálni semmi más formátumba, csak leválogatni. A Smart Import modul, nekem tetszik, mert egyszerű a kezelése és azt teszi, ami nekem kell. Ez a modul .xls és .xlsx formátumokat importál a megadott tartalomtípusba nagyon szimpatikus módon. A tartalomtípust views jeleníti meg, a szűrőjében használom a views_autocomplete_filters-t és az eredmény pontosan az amit szerettem volna.
Kíváncsi leszek amikor nő az adatbázis, hogy hogyan fog viselkedni, de remélem jól.
Köszönöm nektek
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Szerintem
Szerintem az az irányelv, hogy az is tudjon sminket készíteni, aki nem programozó, nem ismeri a php nyelvet. Az utóbbi esetben (D7) nem kell ismerned az empty függvényt (és annak elég érdekes működését).
Személyes megjegyzés: a D7-es theme system sajnos eléggé félkészre sikerült ebből a szempontból, talán majd D8 kicsit összeszedettebb lesz.
Lippai Ádám
young element