parancs futattása
Oké, ez azt jelenti, hogy oda nem a közvetlen URL-t kell megadnod, hanem a parancsot, amit futtatni szeretnél.
A helyzet így annyiban módosul, hogy ha a Google-ban rákeresel a „Drupal cron” kulcsszavakra, akkor az első találat ez az oldal lesz: Set up cron
Itt elég hosszan írnak a témáról, számodra ennek egy aloldala, a Configuring cron jobs using the cron command lesz érdekes, abból is különösen ez a rész:
„In the following example, the crontab command shown below will activate the cron tasks automatically on the hour:
0 * * * * wget -O - -q -t 1 http://www.example.com/cron.php”
Itt az első számmal és a csillagokkal ne foglalkozz, az csak az ütemezést biztosító crontabnak kell, mint ahogy azt lentebb írják is.
Szóval marad ennyi:
„wget -O - -q -t 1 http://www.example.com/cron.php”
A többit már a találékonyságodra bízom. :)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
státusz üzenet
Oké, az ott státusz üzenet.
A kérdés az, hogy kinek jelenik meg? Mert ha csak az adminnak, akkor én nem piszkálnám: Tájékoztató üzenet, neked szól.
Ha mindenkinek megjelenik (vagy tényleg zavaró), akkor két lehetőség jut eszembe:
- Kiszedném a sminkből a státusz üzenetek megjelenítését. Ez egy elég rossz módszer (mert ettől kezdve egyik sem jelenik meg), és lehetnek ott sokkal fontosabbak is. Ha ezt szeretnéd, akkor a sminked page.tpl.php fájljában keress egy ilyen részt és töröld ki:
<?php print $messages; ?>Drupal cache ürítés szükséges lehet. - Ha pedig csak az üzenet nem kell, akkor egy kis PHP varázslással kiszedheted a theme_status_messages() sminkfüggvényben, Drupal cache ürítés kell.
Amúgy mi lenne, ha letiltanád az érintett hírcsatornákat?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
cél?
Ha a submit esemény bekövetkezik, akkor már küldi is a form tagnél megadott metódussal az adatokat az action attribútumnál megadott feldolgozó fájl felé.
Itt kérdés, hogy máshol pongyolán fogalmazva "megállítod-e" ezt a lap-újrafrissítős mechanizmust a böngészőnél, és mondjuk AJAX-szal küldöd-e tovább az adatokat.
JavaScripttel teljesen felülbírálhatod a form default "viselkedését", de ha kiszámíthatóvá akarod tenni, hogy még a form elküldése előtt milyen JavaScript-kód jusson egyáltalán érvényre, akkor azt annak megfelelően kell intézned.
Mi a célod?
Az, hogy egy esemény mindenképpen bekövetkezzen a form elküldése előtt? Ha így szeretnéd, akkor a submit gombra való click eseményre kötött függvénynél return false;-szal (meg létezik event.preventDefault()) kell visszatérni, hogy ne frissüljön az oldal; de előtte megcsinálni, amit még szeretnél, hogy bekövetkezzen a click eseményre - ha viszont utána mindenképp szeretnéd mégis elküldetni a formot, akkor callback-ként még mindig megadhatod azt, hogy a form legyen elküldve submit()-tel.
Szóval mit szeretnél?
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszi, ez most sokat segített
Köszi, ez most sokat segített! A beállítás eredményeképpen a dátumargumentum nélküli url esetén az aktuális dátum heti táblázata jelenik meg. Nekem ez volt a lényeg, mert így egy menüpontból megnyitható ez a nézet.
Ami viszont hiba megmarad, de szerencsére ez nekem nem probléma, mert nem fogom használni a második naptár mini-calendar nézetét:
- a második mini-calendar blokk is hetire vált, amiben viszont csak akkor jelenik meg bármi, ha van ide tartozó tartalom, egyébként üres.
- ha a második mini-calendar blokkban a következő hétre léptetek, akkor az első naptár mini-calendar blokkja is heti nézetre vált, a fentihez hasonlóan.
Tehát a két calendar nézet összeakad.
De az én problémám úgy tűnik, megoldódott!
Arra van ötleted, mi kell ahhoz, hogy a napi nézetben az időpontok megjelenjenek? Másik honlapon ez működik, itt nem. Illetve a "Jó változatban" is rossz helyen jelenik meg az Egész napos esemény.
Jó megjelenés:
Rossz megjelenés:
Csökönyi Ferenc
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
mi lenne, ha nem szivatnád magad?
„Nos Win XP-n futó Apache-php-Mysql-ről van szó, külön lettek telepítve és egymáshoz konfigurálva.”
Mi lenne, ha nem szívatnád magad feleslegesen? Lehet, hogy tévedek, de úgy gondolom, hogy te ezek konfigurálásában nem állsz a helyzet magaslatán. Nem baj, nem is kell.
Itt van pl. az XAMPP. Letöltöd, telepíted és ennyi. Benne van az Apache, PHP, MySQL, ezek be is vannak állítva (lehet, hogy a fenti „AllowOverride” dolog kell még) és ennyi. Nem kell azzal vacakolnod, hogyan kell normálisan az Apache-ot összekötni a PHP-val, a PHP-t a MySQL-el, és a többi ilyen cseppet sem érdekes (mondhatni unalmas) dolog. De az Acquia oldalán találsz szuper telepítőt a „Dev Desktop” részben, és akkor kb. megvan a fenti, plusz még a Drupal is. Bár én az előbbit preferáltam, amikor ilyenre volt szükségem, ezeken kívül számtalan ilyen egybeépített csomag van még.
„Annak a .htaccess fájlnak a Drupal gyökérkönyvtárában kell lennie? Mert ott van 1 ilyen.”
Igen, arra a fájlra gondoltam.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Biztonsági szempontok
Ezek a frissítések biztonsági frissítéseket is tartalmaznak, ezért számíthat a dolog.
Legszélsőségesebb elképzelhető esetet említve nem árt frissíteni, ha nem akarod, hogy az esetleges ismert Drupalos (azóta javított) biztonsági rések ott tátongjanak a hekker pistikéknek.
Amit a frissítéskor mindenképp csinálj meg:
- használj Drush-t, és biztosíts neki megfelelő jogosultságokat, ha azt akarod, hogy egyszerűbb legyen az életed (
drush up, mindezt-ykapcsolóval kiegészítve minden kérdésre automatikusan igent válaszolhatsz) - készíts backupot MINDENRŐL (összes fájl, adatbázis), akár több példányban is legyen meg inkább, mint hogy egyszer sem.
- lehetőleg teszteld localhoston először a frissítés sikerességét; a frissítés után kattintgass mindenfelé, megnézve, hogy a modulok ugyanúgy működnek-e, nem kapsz-e hibákat bizonyos oldalakon, stb.
- csak akkor rakd fel az éles szerverre is a frissítést, és cseréld le az előző változatot, ha tényleg mindent leteszteltél frissítés után
- az előző változatot se dobd el, rakd el későbbre a mentést
Egyelőre ennyi jutott eszembe.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Köszönöm a segítséget!
Köszönöm a segítséget!
A honlapom naptárában csak 1-1 esemény szerepelne 1 adott napon, több biztosan nem, így sem lehetséges bekapcsolni a link-to-node üzemmódot? Vagy csak kódolással lehetne ezt kikényszeríteni a Calendar-ból?
Esetleg a calendar_tooltips segítségével több link-to-node eseményt is lehetne kezelni, ha adott napra viszem a kurzort, majd a tooltip részben egymás alatt felsorolná az adott nap több eseményét, és ott is lehetne rá kattintani. Nem túlzottan értek hozzá, ez csak ötletelés volt részemről. De az biztos, hogy csak napi 1 esemény lenne, így nem okozna problémát a több esemény kezelése.
Közben kipróbáltam a Calendar block modult is, ebben nem találtam eseménykezelést, viszont a Pretty calendar modulban találtam, de ott valami miatt nem működik megfelelően az ajax (load-nál nem töltődik be a tartalom, nem működik se a tooltip, se a pager)
Így csak a Views + Calendar maradt, mint utolsó lehetőségem, csak finomhangolni kéne...
Ha végképp nem működik a link-to-node, olyat lehet csinálni, hogy az adott napra kattintva a nagy naptár jelenjen meg, de havi bontásban? (Calendar beállításinál próbáltam átírni az Útvonal mezőben található hivatakozást day-ről month-ra, de nem működik)
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
+1
A memória cache nálam mindig az első lépések egyike. Annyi kiegészítéssel, hogy nálam 4-6MB mindig elég volt memcache-ből egy sitehoz, nem biztos, hogy nektek kell olyan sok, mint alippai javasolta.
Amúgy meg csodálom, hogy senki nem írta, de Devel modulnak van olyan funkciója hogy kiírja az összes lefuttatott SQL-t a lap aljára. Azzal nézd meg. Sajnos 200-400 query normális egy Drupal site esetén, ahol nincs memória cache. De ha jól olvasom a számokat, nálatok ennél sokkal-sokkal több query fur le.
Egy tipp vaktában: nincs véletlenül nálatok sok fájl feltöltögetés? A fájlfeltöltés állapotát AJAX-szal kérdezi le a file field, és nem másodpercenként, hanem brutál gyakran. Ha valami más modul pl. hook_init()-ben sok query-t futtat, akkor az tényleg tud ilyet produkálni.
A core hackelést pedig tényleg felejtsétek el. Nem azért, mert az kiváltságosok privilégiuma lenne, hanem mert hosszú távon marha sok fejfájást fog okozni. A user api nagyon sokoldalú volt már D6-ban is, erősen csodálkoznék ha nem lehetne megoldani saját custom modullal az igényeiteket. Csak néttetek utána alaposan, akár a régi 6-os verziós Pro Drupal Development könyvben a lehetőségeknek.
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
Minden kivitelezhető, a
Minden kivitelezhető, a Drupal tartalom hozzáférés szabályozásával gyakorlatilag bármi megvalósítható.
Működése nagy vonalakban úgy néz ki, hogy minden felhasználónak adhatóak kulcsok, és minden tartalomra tehetőek zárak. Ha a felhasználó bármelyik kulcsa nyitja az adott zárat akkor a felhasználó hozzáfér a tartalomhoz. A kulcsok és zárak tipizáltak. (tehát a Tuto lakatot nem nyitja az Elzet kulcs)
Ez az alap Drupal része, de kell egy modul, ami kulcsokat ad a felhasználóknak és zárakat tesz a tartalmakra. Több modult csak akkor használj, ha tudod mit csinálsz! (vagy ajánlják, mint a content access - acl páros)
Itt az igazi kérdés, hogy létezik-e arra modul amit szeretnél, tehát programozás nélkül könnyedén megléphető-e.
A legtöbb modul vagy tartalmak egy csoportja (pl.: tartalomtípus) / szerepkör(csoport) vonalon gondolkodik, vagy tartalom-felhasználó(acl) vonalon. Az acl talán tudja a tartalomtípus/felhasználó relációt is, de nem vagyok benne biztos.
Jó lenne a konkrét problémát látni, mert akkor talán tudunk javasolni olyan absztrakciót, amit létező modulokkal meg lehet lépni.
Láthatóan te tartalmak egy csoportját szeretnéd felhasználóhoz kötni, ami nem olyan egyszerű, talán a taxonomy access (tac) modullal, vagy tac_lite-al megléphető.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
- A hozzászóláshoz regisztráció és bejelentkezés szükséges
inspiráció(nem .click)
http://frankleng.me/2010/07/21/drupal-tip-lightbox-pop-up-on-page-load/
(Part 3 - Load it)
http://jqueryui.com/demos/dialog/
http://jacklmoore.com/colorbox/
http://point47.com/journal/2010/06/modal-box-on-page-load-with-jquery-fa...
http://www.dynamicdrive.com/forums/showthread.php?t=56899
(De és írom de, engem pl nagyon zavar az ilyesmi. Főleg hogy állandóan fel fog "jönni". Ettől sokkal jobb megoldás a .click().[ezért is linkeltem azokat a csodaszép és praktikus megoldásokat] - valami szép, figyelemfelkeltő képet adsz hozzá és ha van kedve az embernek rákattint ha nincs akkor meg nem. Főleg meg ha szerves része az oldalnak az a views-os page-ed. ) - persze ez csak az én véleményem.
Drupal Hétvége 2011