Keresés

Tartalomszervezési megoldások II. - Views és CCK modul

Anonymous képe

Negyedik megoldás: Views

Tételezzük fel, hogy egyesületünk honlapján a csapatnevek mellet nem 2 hanem 4 további kategóriát szeretnénk bevezetni: Fiúk, Lányok, Hazai játékosok, Vendégjátékosok. Ez a – rendkívülinek nem nevezhető – helyzet azt eredményezi, hogy webhelyünk szerkezete, és ezzel párhuzamosan a menürendszer kényelmetlenné és a kategóriák közötti átfedésektől függően nehezen áttekinthetővé vált:

  • Piros csapat
  • Piros fiúk
  • Piros vendégjátékosok
  • Piros vendégjátékos fiúk
  • Fiúk
  • Hazai játékos fiúk
  • ...stb.

Ha például azt szeretnénk, hogy a hazai játékosoknak és a vendégjátékosoknak a csapatok mintájára külön oldaluk legyen (ne csak egy-egy lista), akkor ezeknek külön könyvet kell nyitnunk; és mivel egy oldalt (könyvlapot) csak egy könyvbe tudunk beilleszteni, a játékosok oldalait kétszer kell felvinnünk a honlapra. Hasonló problémát okoz az a korlátozás, hogy egy node-hoz csak egy útvonal álnevet rendelhetünk, ezért pl. egy Piros csapatban játszó vendégjátékos fiú oldalán vagy a Piros fiúk, vagy a Vendégjátékosok segédmenüpontot fogjuk tudni megjeleníteni (hacsak nem használunk többszörösen összetett útvonal álneveket, amivel éppen az álnév lényegét – egyszerűen megjegyezhető internetcím – veszítjük el). Ezen a ponton már a Drupal alapcsomag korlátait feszegetjük, és éppen ideje kiegészítők után néznünk: ismerkedjünk meg a Views modullal.

A Views a Drupal rendszer által készített listák felülírására, valamint új listák létrehozására használható. A felülírás azt jelenti, hogy egy adott webcímen, pl. a www.valami.hu/taxonomy/term/1 alatt nem a szokásos kategória-listát látjuk, hanem egy általunk megadott szempontok szerint módosított felsorolást. Lássuk, milyen módosításokat tesz lehetővé a Views:

  • Lista megjelenítése nem csak önálló oldalon, hanem blokkban is
  • Hozzáférés korlátozása felhasználói csoportok szerint
  • Oldalaknak, blokkoknak egyéni cím
  • Oldalaknak, blokkoknak egyéni fejléc és lábléc
  • Listázott elemek megjelenítési módjának meghatározása (teljes node, bevezető, táblázat, felsorolás)
  • Listában szereplő node-ok számának meghatározása
  • Listában szereplő mezők meghatározása (pl. cím, beküldési idő, szerző neve, stb.)
  • Lista szűkítése kategóriák, tartalomtípusok, közzétételi beállítások szerint
  • Lista rendezése növekvő vagy csökkenő sorrendbe
  • ... stb.

A fenti felsorolás nem teljes, de talán érzékelteti a modul sokoldalúságát. Számunkra most a legérdekesebb az a lehetőség, hogy a listázó oldalakhoz egyéni fejlécet készíthetünk. Eredeti problémánk az volt, hogy nem tudtuk a kategória listázó oldalak tetejére beszúrni a csapatok elérhetőségét és egyéb információit – ezt a feladatot szépen megoldhatjuk a listázó oldal felülírásával. Készítsük el tehát a kategóriákat és vigyük fel a játékosok oldalait:

  • Piros csapat (taxonomy/term/1)
    • Játékos-1 (node/1)
    • Játékos-2 (node/2)
    • Játékos-3 (node/3)
    • stb.
  • Kék csapat (taxonomy/term/2)
    • Játékos-4 (node/4)
    • Játékos-5 (node/5)
    • stb.

Ezután az admin/build/views/add oldalon készítsük el a nézeteket, amelyekkel felülírjuk a taxonomy/term/x oldalakat:

  • Name (név): piroscsapat
  • Access (hozzáférés): mivel mindenki számára elérhetővé kívánjuk tenni az oldalt, ne jelöljük be egyik csoportot sem
  • Description (leírás): Piros csapat oldala (ezt a szöveget csak az adminisztrátor látja)
  • Page (oldal)
    • Provide page view (oldal készítése): kipipálva
    • URL (webcím): taxonomy/term/1
    • View type (nézet típusa): Teaser List (bevezetők)
    • Title (az oldal látható címe): Piros csapat
    • Use Pager (lapozó használata): kipipálva
    • Breadcrumb trail should not include "Home" (A morzsa ne tartalmazza a 'Nyitólap' linket): hagyjuk üresen
    • Nodes per Page (node-ok száma): 10
    • Header (fejléc): ide illeszthetjük be a Piros csapatra vonatkozó információkat; ha HTML vagy PHP kódot használunk, ne felejtsük el átállítani a beviteli módot
  • Filters (szűrők):
    • Node: Published -> Equals: Yes (csak a közzétett oldalak szerepeljenek a listán)
    • Taxonomy: Terms for Csapatok -> Is One Of: Piros csapat (csak a 'Piros csapat' kategóriába sorolt cikkek szerepeljenek a listán); Option: 10 (ha szeretnénk, hogy a 'Piros csapat' kategória alá besorolt esetleges alkategóriák tartalmát is listázza)
  • Sort Criteria (sorrendezési szabályok):
    • Node: Sticky -> Order: Descending ('kiemelt' cikkek az oldal tetejére, csökkenő időrendi sorrendben)
    • Node: Created Time -> Order: Descending (többi cikk csökkenő időrendi sorrendben)
  • Látogassunk el a www.valami.hu/taxonomy/term/1 oldalra: a korábbi egyszerű listázó oldal helyett most a fejléccel kiegészített, teljes értékű Piros csapat oldalt látjuk. Természetesen használhatunk egyszerűen megjegyezhető webcímeket is; ehhez navigáljunk az 'Útvonal álnevek' menüpont alá, és adjuk meg, hogy a taxonomy/term/1 mellett legyen oldalunk a piros címen is elérhető. A 'Menük' oldalon állítsunk be egy piros címre mutató menüpontot is – ezzel el is készültünk a Piros csapat oldalával. Ismételjük meg a nézet készítés, útvonal álnév megadás, menüpont készítés lépéseket valamennyi kategóriánkra. Ha ezek után felkeressük bármelyik játékos oldalát, ott találjuk a kategória linkeket (Piros csapat, Fiúk, Vendégjátékosok); és ha bármelyik linkre rákattintunk, a Views által készített, fejlécekkel/láblécekkel feljavított nézet-oldalakra lépünk. Ezeket az oldalakat igen jól lehet sminkelni, tehát egyéni megjelenést is tudunk nekik adni; emellett a fejléc/lábléc szövegbe egyszerűen beilleszthetünk kombinált taxonómia-linkeket (pl. a Fiúk oldalon a hazai és vendégjátékos fiúk listájára mutató linkek), ill. Insert View modullal bármilyen más nézetet – így kordában tudjuk tartani a csak bizonyos oldalakon megjelenítendő másodlagos menük burjánzását. Webhelyünk ezzel áttekinthető szerkezetet és következetes navigációs struktúrát kapott.

    Megjegyzés: A Views nézetkészítő űrlapján lehetőség van URL-ként útvonal álnevek megadására, valamint menüpont készítésre is. Ezeket a szolgáltatásokat akkor célszerű használni, ha teljesen új, a rendszerben nem szereplő listát készítünk (pl. ha a "Piros csapat" kategóriában szereplő "kép" típusú tartalmakat szeretnénk kigyűjteni egy külön képgaléria számára). Ha egy meglévő listát szeretnénk felülírni, akkor először készítsük el a nézetet a rendszer által meghatározott URL (pl. taxonomy/term/x) megadásával, majd külön lépésben definiáljuk az útvonal álnevet és a menüpontot. Ezzel elkerülhető, hogy webhelyünkön egymás mellett éljen a hagyományos oldal és annak felülírt verziója, ami esetleg megzavarhatja a barangoló látogatókat.

    Ötödik megoldás: CCK + Views

    A Views modullal már egészen összetett webhelyeket is építhetünk anélkül, hogy egyetlen sor PHP-kódot kellene írnunk; mégis elképzelhető néhány olyan eset, amikor még ez a megoldás sem elégíti ki az igényeinket. A Views kezelőfelülete meglehetősen bonyolult, márpedig minden egyes alkalommal, amikor új nézetet készítünk (pl. új kategóriával bővül a webhely), vagy meglévőt módosítunk (megváltozott a csapat telefonszáma), akkor kénytelenek vagyunk ezen a barátságtalan űrlapon dolgozni. Húsz-harminc nézetnél többet ilyen módon kezelni még akkor is kényelmetlen, ha a webhely karbantartását hozzáértő webmester végzi – laikusoktól pedig egyáltalán nem várható el, hogy kiigazodjanak a Views bokros opciói között.

    Szintén tovább kell lépnünk akkor, ha szeretnénk kétszintes honlapunkat (játékosok, csapatok) három- vagy többszintessé bővíteni. Képzeljük el azt az esetet, amikor több tucat csapatunk van, és szeretnénk a csapatok részvételével versenyeket szervezni. Létrehozhatunk egy Versenyek kategóriát, de ehhez nem tudjuk hozzárendelni a csapatokat, mert azok nem node-ok, hanem kategóriák, ill. a kategóriák módosításával létrehozott nézetek. Ennek a problémának a megoldására született a Category kiegészítő modul – az ezzel a modullal létrehozott kategóriák tehát egyúttal node-ok is, amelyek tetszőleges információkat (elérhetőségek, verseny helyszíne, időpontja, stb.) tartalmazhatnak, és amelyeket a szokásos módon kategorizálhatunk és listázhatunk. A Category felülete azonban legalább olyan bonyolult, mint a Views modulé, és csupán egyetlen szolgáltatást kínál. Cikkünk megírásának időpontjában általában jobb megoldás a Content Construction Kit (rövidítve CCK) modul használata.

    A Drupal alapcsomaggal létrehozott tartalomtípusok csak két mezőt tartalmaznak: a címet és a törzset. A CCK modul legfontosabb szolgáltatása, hogy lehetővé teszi a tartalomtípusok bővítését további mezőkkel. Ha jól strukturálható adatokkal dolgozunk, akkor a CCK segítségével a tartalmak beküldését és megjelenítését nagymértékben szabályozni tudjuk. Példánknál maradva hozzunk létre 3 tartalomtípust a szükséges mezőkkel:

    • Játékos
      • Name: Játékos
      • Type: jatekos
      • Title field label: A játékos neve
      • Body field label: A játékos életrajza
      • Text field: A játékos telefonszáma
      • Node reference: Csapat
    • Csapat
      • Name: Csapat
      • Type: csapat
      • Title field label: A csapat neve
      • Body field label: A csapat története
      • Text field: Az edző neve
      • Text field: Az edző telefonszáma
      • Node reference: Játékos
    • Verseny
      • Name: Verseny
      • Type: verseny
      • Title field label: A verseny neve
      • Body field label: A verseny leírása
      • Text field: Helyszín
      • Date field: Időpont
      • Node reference: Csapat

    A tartalomtípusok létrehozása után a "Tartalom beküldése" menüpont alatt megjelenik a 3 típus – az ezekhez tartozó beküldő űrlap kitöltése pedig a laikus felhasználó számára sem okoz gondot. Tartalomszervezés szempontjából figyelemre méltó a "Node reference" mező, amely megoldást jelent kategorizálási problémáinkra: ennek segítségével a versenyzőket a csapatokhoz, a csapatokat pedig a versenyekhez tudjuk rendelni. A gyakorlatban ez azt jelenti, hogy például egy új játékos létrehozása két lépésből áll: először is létre kell hoznunk a "játékos" típusú tartalmat, amelynek során kiválasztjuk a node reference listából, hogy az új ember melyik csapatban játszik; majd az adott csapat node reference listájára fel kell vennünk az új játékost. A munkafolyamatot tovább egyszerűsíthetjük, ha a csapatok tagjait nem node reference útján határozzuk meg, hanem Views modullal készítünk egy csapattagokat listázó nézetet, majd ezt beágyazzuk a Csapat tartalomtípusba.

    • URL: csapat
    • Filters:
      • Node Published -> Equals: Yes
      • Node: Type -> Is One Of: Játékos
    • Arguments:
      • Argument type -> Node reference: Játékos (field_csapat)
      • Default -> Summary, unsorted

    Ezzel lényegében megmondtuk a Views-nak, hogy készítsen listát azokból a játékos node-okból, amelyek rendelkeznek field_csapat nevű CCK-s mezővel. Ha a nézet nem kap argumentumot az URL végén (pl. a www.honlapneve.hu/csapat címen), akkor készít egy összesített listát, zárójelben a csapat játékosainak számával:

    • Piros csapat (20)
    • Kék csapat (18)

    Ha a nézet az URL végén argumentumot kap (pl. www.honlapneve.hu/csapat/12), akkor kilistázza az adott csapatra – esetünkben a node/12 azonosítójú, csapat típusú tartalomra – node reference útján hivatkozó node-okat, azaz a csapat játékosait. Ezt a nézetet Viewfield modullal tudjuk beágyazni a csapat node-okba:

    1. Egészítsük ki a Csapat CCK-s tartalomtípusunkat egy Viewfield mezővel.
    2. Argumentumként adjuk át az aktuális node azonosítóját: %nid.
    3. Ha ezek után felkeressük bármelyik Csapat típusú node-ot, ott látjuk az adott node-ra node reference útján hivatkozó játékosok listáját.

    A CCK és a Views a legdinamikusabban fejlesztett kiegészítő modulok közé tartoznak, egyes funkcióik hamarosan az alapcsomagban is megjelennek. Számíthatunk rá, hogy a jövőben a hasonló rendszerező oldalak készítése tovább fog egyszerűsödni. Elég jó angol nyelvű dokumentáció található róluk a Drupal.org kézikönyvében:

    További újdonságot jelenthet a Book modul tervezett átalakítása, amely kimondottan a hierarchikus honlapok készítését fogja megkönnyíteni.

    Remélhetőleg a fenti példákból is nyilvánvalóvá vált, hogy szinte bármilyen tartalomszervezési problémával kerülünk szembe, találni fogunk a Drupal kínálatában olyan megoldást, amellyel PHP kód írása nélkül, esetleg pár soros kódrészlet beillesztésével a feladat megoldható. Azonban a Drupal csak a kódolás terhét tudja levenni a vállunkról – gondolkodni nem tud helyettünk. A számunkra optimális megoldást csak akkor tudjuk kiválasztani, ha a webhely építését megelőzően elemezzük, modellezzük a feladatot, és még a tartalmak tömeges felvitele előtt alaposan tesztelünk.

    CsatolmányMéret
    Kép ikon cck_viewfield.png13.35 KB

    Újság elektronikus kiadása CCK alapokon

    Anonymous képe

    Ma már szinte minden nyomtatott sajtótermék elérhető interneten is. Ezeknek az internetes verzióknak a fejlesztése során két felfogás valamelyike szokott érvényesülni: az egyik szerint egy külön online verziót készítenek, amibe feltöltik a nyomtatott példány fontosabb cikkeit; a másik szerint az internetes és a papíralapú verzió lehetőség szerint legyen egymás tükörképe.

    Az előbbi megközelítés jobban illeszkedik a webes tartalomkezelési megoldásokhoz, ezért gyorsabban, olcsóbban fejleszthető és karbantartható – a második felfogás előnye, hogy a látogatók – és ami legalább ilyen fontos: a hirdetők – egységes arculatú és színvonalú kiadvánnyal találkoznak a neten és az újságárusnál. Ez utóbbi megközelítés viszont azzal a következménnyel jár, hogy a minőségi újságok elektronikus szerkesztőségeit rendszerint igen bonyolult, egyénileg fejlesztett tartalomkezelők szolgálják ki.

    Moshe Weitzman és Barry Jaspan nemrégiben arra kaptak megbízást, hogy elkészítsék a New York Observer c. lap internetes verzióját, méghozzá úgy, hogy a kiadó a webes verzióban is ragaszkodott a nyomtatásban érvényesülő szerkesztési és grafikai igényességhez. Hogy hogyan sikerült 2 Drupal fejlesztőnek 2 hónap alatt megoldani a feladatot, arról a Drupal.org honlapon közölt írásukban számolnak be.

    Az újságok elektronikus kiadását hagyományos Drupal módszerekkel a következő módon készítettük:

    1. A cikkek a rendszerben valamilyen tartalomtípusnak (pl. írás) felelnek meg.
    2. A cikkeket a rovatoknak megfelelő kategóriákba rendezzük.
    3. A címlapon és a rovatok oldalain blokkokat helyezünk el, amelyek megjelenítését/elrejtését az útvonal álnevek segítségével szabályozzuk.
    4. A blokkokba a tartalmat (a cikklistákat) kézzel írt adatbázis-lekérdezésekkel, vagy újabban Views modullal készített nézetek segítségével töltjük fel.
    5. Az egyes számok cikkeit kategóriákkal fogjuk össze (pl. a „2007. május 6-i szám” egy kategória).
    6. A rendszerbe feltöltött cikkek megjelentetését valamilyen cron alapú időzítő végzi.

    A New York Observer – és a legtöbb „komoly” újság – számára ez a megoldás azért nem elfogadható, mert a lapkiadásban elengedhetetlen, hogy a szerkesztők előnézetben lássák, egy adott tartalmi elem hogyan fog mutatni a végleges helyén és formájában. Gyakori, hogy egy címet, bekezdést átfogalmaznak, egy kép méretét és arányait megváltoztatják annak érdekében, hogy a cikk megjelenése jobban illeszkedjék az oldal struktúrájához, vagy a mellette álló hirdetéshez. Ehhez lényegében annyi párhuzamos tesztwebhelyet kellene működtetni és összehangolni, ahány rovat van az újságban – plusz egyet külön a nyitólap számára.

    A két fejlesztő ennek a problémának a megoldására egy újszerű megoldást vetett be: a címlapot és a rovatok oldalait, sőt, a cikkekhez kapcsolódó további cikkek listáit is CCK tartalomtípusként definiálta. A kilistázandó tartalmakat node reference segítségével kapcsolták az oldalakhoz, a megjelenítést pedig tartalomtípusra szabott template fájlokkal oldották meg. Összességében mintegy 110 CCK mezőt definiáltak a webhely felépítése során – ezek közül talán a legfontosabb a "Közzététel időpontja" nevű mező, ami feleslegessé tette a cron alapú időzítő használatát: egy oldal lekérésekor a rendszer egyszerűen a múltbeli időpontban publikálandó tartalmak közül a legfrissebb közzétételi időponttal rendelkezőt küldi ki a látogatónak. A megoldás további előnye, hogy a nyitólap és a kategória-oldalak „közönséges” tartalommá alakításával elérhetővé váltak a Drupal alaprendszer és a kiegészítő modulok node-okra fejlesztett szolgáltatásai.

    Moshe és Barry cikke az eredeti alapötlet mellett számos ügyes fogást mutat be. A fejlesztők egy idő után nagyon megunták a blokk beállítási oldalakon a szerkesztgetést, ezért a blokkok bonyolult ki- és bekapcsolási utasításait egyszerűen egy tömbben helyezték el, amit beépítettek a sminkbe. A címkefelhő elemeinek méretét nem a címke – önmagában nem sokat mondó – „népszerűsége”, hanem az adott címkével megjelölt cikkek olvasottsága határozza meg.

    A fejlesztők beszámolójához érkezett hozzászólások egy része a webhely optimalizálására vonatkozott, különös tekintettel a közfelfogás által problematikusnak tartott CCK és Views használatára – Moshe szerint komolyabb optimalizálásra nem volt szükség (vélhetően a webhely dedikált szerveren fut), viszont nagyon egyszerű módon, az Apache mod_expires moduljának bekapcsolásával elérték azt, hogy az oldal jóval gyorsabban töltődjön be a böngészőbe. Kérdésekre adott válaszként bemutatták a legolvasottabb és legtöbb hozzászólást vonzó cikkek listáit rejtő füles megoldást, beszámoltak a projekt részfeladatainak időigényéről, és még jónéhány érdekes témáról. Érdemes tehát legörgetni a cikk aljáig és a hozzászólásokból is kimazsolázni a számunkra érdekesebb részleteket.

    Egyedi "Karbantartás alatt" oldal készítése

    Anonymous képe

    Ha Drupal honlapunkon karbantartási munkákat végzünk, az admin/settings/site-maintenance oldalon célszerű a webhelyet offline üzemmódba kapcsolni. Ekkor csak a webhely adminisztrátora fér hozzá a honlap tartalmához, a többi látogató az alábbi feliratot látja:

    Karbantartás miatt zárva

    Az oldal szövegét szintén az admin/settings/site-maintenance oldalon tudjuk módosítani – például ha szeretnénk jelezni, hogy mikor indul újra a honlap, itt megtehetjük. Lehetőség van HTML kód bevitelére is:

    A nyitás tervezett időpontja:

    2007. június 24. hétfő, reggel 9 óra

    Nyitás: 2007. június 24. hétfő, reggel 9 óra

    Ha szeretnénk teljesen egyénivé tenni az oldalt, könnyedén lecserélhetjük a Drupal logót és a „Karbantartás miatt zárva” főcímet is a theme_maintenance_page() függvény felülírásával.

    Az egyik lehetőség, hogy egyszerűen bemásoljuk a függvényt a template.php fájlba, átnevezzük phptemplate_maintenance_page()-re, és elvégezzük a kívánt módosításokat.

    Kicsit bonyolultabb, de végső soron kényelmesebb megoldás, ha külön sablont készítünk a karbantartási oldal számára. Ehhez hozzunk létre egy page-maintenance.tpl.php nevű fájlt a sminkmappában, és hívjuk meg a template.php segítségével:


    function phptemplate_maintenance_page($content, $messages = TRUE, $partial = FALSE) {
    return _phptemplate_callback('page-maintenance', array('content' => $content, 'messages' => $messages, 'partial' => $partial));
    }
    ?>

    Ezek után készítsük el a page-maintenance.tpl.php sablont. Belinkelhetjük a webhely favikonját és a karbantartási oldalhoz készített külön CSS fájlt is. Az admin/settings/site-maintenance oldalon megadott üzenetünket a $content változó segítségével tudjuk kiíratni.




    Webhely karbantartás | Honlap.hu


    Sajnáljuk, honlapunk pillanatnyilag nem elérhető




    A végeredmény:

    Egyedi karbantartásjelző oldal

    Biztonsági javításokkal megjelent a Drupal 4.7.7-es és 5.2-es verziója

    Anonymous képe

    A frissítés az új verziókra feltétlenül ajánlott: Drupal 5.2 letöltés, Drupal 4.7.7 letöltés

    A bejelentés szövege felhívja a figyelmet arra, hogy ne tartsuk meg a sites könyvtárban található settings.php fájlokat:

    Az egyik felfedezett biztonsági sebezhetőség a settings.php fájlt érinti. Nagyon fontos, hogy lecseréljük a sites alkönyvtáraiban lévő settings.php fájlokat az új csomagban található állományra. Utána ne feledjük a $db_url változó értékét beállítani annak megfelelően, ahogyan az a régi settings.php-ben szerepelt. A változó szükséges ahhoz, hogy a Drupal az adatbázishoz kapcsolódni tudjon.

    Kategóriák: 

    RSS publikálás közép-európai időzónában

    Anonymous képe

    Sziasztok!

    A Drupal által készített alap RSS csatorna (rss.xml) a <pubdate> értéket a szerveridő alapján állítja be és nem a webhelyen beállított időzóna alapján. Magyarán a node_feed() a $node->created értékkel dolgozik és nem adja hozzá a $timezone-t. Találtam ezt a 2005-ös hibajelentést, mást semmit. Elég alapvető dolognak tűnik, lehet, hogy nem jó helyen keresem a megoldást!?

    Lehet-e pénzt kérni a Drupal módosításáért?

    Anonymous képe

    Folytatva ezt a témát, a kérdés tehát az, hogy lehet-e pénzt kérni pl. a Garland smink módosításáért. Az én értelmezésem szerint bármit lehet csinálni GPL-es szoftverrel, kivéve a GPL eltávolítását vagy szövegének módosítását. Az egyetlen érinthetetlen része a csomagnak a LICENCE.TXT, a többit kedvedre módosíthatod, és a módosított változatot terjesztheted ingyen vagy pénzért, de ha csak egyetlen bitet tartalmaz a módosított változat az eredetiből, akkor a LICENCE.TXT-t és a forráskódot mellékelned kell. Ti hogyan értelmezitek a licencet?

    Fórum: 

    CCK 6.x-2.x-rc8/dev modul nem megy Windows alatt

    Anonymous képe

    Sziasztok!

    Fut valakinél Drupal 6 + CCK rc8/dev (vagy bármilyen más 6-os CCK) Windows rendszeren? Nálam nem megy: http://drupal.org/node/317167 Nyugtassatok meg, hogy az én készülékemben van a hiba (ellenkező esetben az ablakos PHP bugos, és azt rövid távon legfeljebb megkerülni lehet).

    Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
    Drupal verzió: 

    Tárhelyszolgáltató checklist

    Anonymous képe

    Sziasztok!

    Hamarosan én is szeretnék elkezdeni blogolni a Planeten, és arra gondoltam, mindig írnék egy rövid kis ismertetőt azokról a tárhelyszolgáltatókról, amelyekkel a munka során összehoz a jó/rossz szerencse. A túlságosan szubjektív (és ezért használhatatlan) leírásokat kerülendő jó lenne egy standard ellenőrző lista, ami alapján jellemezni tudjuk az adott szolgáltatót. Például:

    1. Barátságos URL-ek (mod_rewrite): OK
    2. .htaccess engedélyezett: OK
    3. Rendelkezésre álló memória: 25MB
    4. Ingyenes kipróbálási lehetőség: 5 nap
    5. Tech support átlagos válaszadási idő: 1 munkanap
    6. ...stb.

    Ha van kedvetek, gyűjtsük össze együtt, mi fontos nekünk, mire figyelünk, amikor Drupal rendszer számára tárhelyszolgáltatót választunk.

    WYSIWYG kódtisztító

    Anonymous képe

    Sziasztok!

    Kinek milyen bombabiztos módszere van arra, hogy a WYSIWYG editorokon keresztül feltöltött szövegből kiszűrődjenek a microsoftos szemetes kódok? Példa. Ezt itt történetesen TinyMCE-vel töltötték fel egy másik webhelyre, FeedAPI-val húzzuk át hozzánk, de azt meg mégse lehet, hogy Full HTML-t beengedjek. Ugyanez a probléma minden általam kezelt webhelyen jelentkezik, nem lehet a feltöltő egyéneket rávenni a szövegek jegyzettömbözésére.

    A TinyMCE-hez van egy plugin, de azt hallom megbízható forrásból, hogy nem működik rendesen. Más megoldást tudtok, ki mit használ?

    Ha kérhetem, ne azt javasoljátok, hogy ne tegyek fel WYSIWYG-et, ez sajnos mindig vesztett meccs. Kell.

    Melyik modulhoz, modulokhoz kapcsolódik a téma?: 
    Drupal verzió: