Működőképesnek
tűnik az elgondolásod, én még nem csináltam ilyet, nem látom át a buktatóit.
Szerintem érdemes saját modult írni, ha kellően önálló a feladat (ez annak tűnik) és ha több függvényt is használsz.
A hook_init mindig lefut, az oldal betöltődésekor, ide be tudod rakni a süti ellenőrzését és lerakását.
> "A regisztrációs form-nál a süti vizsgálat egy form_alter függvénnyel történik modulból"
Ezt a kódot ^^^ is ebbe a modulba pakolnám, hogy egy helyen legyenek az összetartozó dolgok.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Válasz
Kösz. +1
Pontosabban nálam a green-style.css-ben van, de az a lényeg, hogy így már megtaláltam a beállításokat. Az images mappa háttérhez tartozó grafikai elemeit is törölni kellett mert azzal letakarták a valós hátteret. Ezt mondjuk nem tudom miért csinálták a készítők, mivel ezek nem fedik be a teljes hátteret. A "header_bg.jpg"-nek még van értelme mert külön színt lehet vele adni a fejléc hátterének, de a "content_bg.jpg" beillesztésének nem látom az értelmét. Lehet, hogy valamelyik almenüben vagy oldalon használatban van a "content_bg.jpg" képfájl? Inkább visszateszem és a css 44. sorában szedem csak ki a megjelenítését.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Sorry, ha elkeserítelek, de
Sorry, ha elkeserítelek, de ez nem megoldás, csak besöpörted a cuccot a szőnyeg alá.
1. Nézd meg, mi lesz az eredmény ha frissül a smink.
2. Esetleg ha átméretezed a kép presetet, amit most a user képek használnak.
3. Attól, hogy nem látod, az oldalad hányja a php errorokat, warningokat, noticeket.
Ezt a problémát nem lehet cssből megoldani, bármennyire is erölteti a kolléga. De ha már úgyis frissen fenn van a marinelli, esetleg lehet folytatni tovább a debugot a patch alapján, és beküldeni a dorgra a fenti issuehoz, én már töröltem az enyémeket.
----
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
Na, akkor most gyorsan
Na, akkor most gyorsan tegyunk tisztaba par dolgot, mielott ez elharapozik.
1) a JavaScriptnek semmi, de az egvilagon semmi koze nincs a Java nyelvhez, a JRE-hez, vagy barmi egyeb mashoz.
2) A JavaScript szabvanyat ECMA-nak hivjak, a JavaScript masik neve az ECMAScript.
A tobbire nem is ternek ki, mert az egesz kapcsolat a ket nyelv/rendszer kozott nincs, nem letezik, sosem volt. JavaScript tamogatasu bongeszot lehet ugy is irni, hogy fenn sincs JDK a gepeden, lasd peldaul a WebKitet, rengeteg olyan WebKit alapu bongeszo van, ami nem tamogatja a Java alapu Appleteket egyaltalan.
--
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
én nyomtam egy minuszt,
Tehát ha az adott node-ot (vagy tartalomtípust vagy node-on belül a mezőt) korlátozod, akkor az abban szereplő fájlra is vonatkozni fog.
mert ez nem így van, félrevezető. privát filerendszer filejait nem tudod elérni direkt urln keresztül. egy rejtett mezőben lakó filet vagy akár egy nem közzétett node x mezőjében lakó filet is el tudsz érni a publikus filerendszerben urlen keresztül.
bár régebben is volt ilyen beállítás, az globális volt. vagy privát a filerendszered, vagy nem. ez volt régebben. most meg egyszerre van és mezőnként beállítható. remek!
-
clear: both;
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
rossz volt a kérdés
Igen, ezt megértettem belőle, és nem is a jelentésével van bajom.
A helyen kérdés az volna, hogy valóban lehet olyan, hogy egy tartalomtípus, amiben van egy cím, egy törzs meg egy feladatsorszám (még csak nem is hivatkozás) az ennyire sok memóriát igényel?
Közben meg összetettebb nézetek és mindenféle szabályokkal végrehajtott műveletek hibátlanul mennek. Gyanús, hogy valami történik a háttérben, aminek nem kéne. Úgyhogy helyesen az lenne a kérdés, hogy hogyan lehetne ennek utánajárni. Van valamilyen mód, amivel magam is tudok ilyet, vagy mindenképpen a szolgáltató szerveroldali vizsgálódására lesz szükség?
Köszönöm
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Azért írtam ide,mert minden
Azért írtam ide,mert minden kódot és lehetőséget az index.php-tól elindulva nem kis munka lenne meghatározni és gondoltam hátha van egy leírás valahol arról, hogy áll össze a beküldött kód, ami az index.php-hoz megy. Kiindulásnak jó lenne ez a link amit adtál de belenéztem kicsit és nagyon sok az elágazás és variációs lehetőség, hogy nem érdemes belevágni így megszerezni. Akkor már egyszerűbb a kliens oldalon a kimenő kód kis változtatásaival valami szabályszerűséget keresve megtalálgatni a kódok jelentéseit. Arra gondoltam hátha a fejlesztők közzétették valahol a kliens oldali kimenő kódok összeállításának lehetőségeit, szabályait.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
ugyanez a problémám
Sziasztok!
Én csak egy mezei webdesigner vagyok, de most vakarom a kobakom.
Nekem is ugyanez a problémám, egy frissen telepített (nem ingyenes tárhelyen) Drupal 7-el. A képeket más mappából akarja behívni, mint ahol ténylegesen vannak.
Végigolvastam az összes üzenetet, amit az alapkérdéssel kapcsolatban írtatok, de nem találtam meg a választ, hogy HOL javítsak a dolgon. Ha a scriptet kéne átírni valahol, hát az is megoldás, csak nem tudom, hol keressem a hibát.
Másnak nem volt hasonló tapasztalata?
Hálás köszönet minden ötletért:
kalozpepi
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Ugye nem kell belenyúlnod
Ugye nem kell belenyúlnod semmilyen fájlba, hisz saját alsminket készítesz az oldaladhoz ugye, ide mondjuk átmásolod a szülő smink css-fájlját, és ebbe már beleírhatsz, de a letöltött sminkbe nem.
A Sidebar first, azaz a bal oldali sáv nem szűkült be, legalábbis nekem csak akkor amikor összehúztam az böngészőm ablakát. Teljes méretben(nagy monitor) nem szűkül be.
Azt hogy mire mi hat, milyen CSS szabály, melyik classra, Chromeban az elemra jobb klikk majd Elem vizsgálata(Inspect Element) vagy inkább Firefox és Firebug használatával javasolt.
Drupal full-stack developer at Wunderman Thompson Budapest
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Átállás MyISAM-re
A táblákat átállítottam InnoDB-ről MyISAM-ra, így már csak ~2,6MB-ot foglal MySQL-ben. Érezhető sebességváltozás nincs, minden működik. (Ha jól tudom, akkor csak néhány speciális modul igényli az InnoDB-t, egyébként nem okoz gondot a Drupalnak a MyISAM.)
Ez a méret így már sokkal jobban tetszik, de ha valakinek van bármilyen ellenvetése, az most szóljon, vagy hallgasson mindörökké! :D Esetleg a fenti látogatási adatok mellett érdemes valamelyik táblát InnoDB-n hagyni? Mennyire hízhat így az adatbázis cache-eléssel együtt?
(Átállás után a phpMyAdmin több táblánál felülírást jelez. Ez mit jelent?)