A WYSIWYG szerkesztők a Drupalban egy örök téma. Több megoldás is van, de különbözőek az igények, különbözőek a funkciólisták és különbözőek az egyes megoldásokkal járó bug halmazok is :)

Aki esetleg nem lenne tisztában a fogalommal: a WYSIWYG a "What You See Is What You Get" rövidítése, és egyszerűen fogalmazva, ezek ügyes kis javascript eszközök, melyek segítségével úgy lehet szöveget (HTML-t) szerkeszteni egy böngészőben, mint pl. a Word-ben.

Személy szerint szeretek a HTML felett teljes uralommal lenni, ezért több kipróbált modul után, úgy döntöttem hogy, nem használok ilyen eszközt. Valahogy túl nagyok és böszmék voltak. Az volt az érzésem, mintha azt hinnék, nálam is jobban tudják hogy én mit akarok. Egyszóval nem volt jó az összkép. Egy Drupal felhasználói találkozón, még a corvintetőn, CHX ajánlott egy modult amit a NowPublic-kal közösen fejlesztettek ki.

A modul neve HtmlBox, hasonlóan a JavaScript eszközhöz, amin alapul. Anno kipróbáltam, de nem ment, nem tudom miért. Ma viszont adtam neki egy második esélyt és működik, ráadásul első ránézésre bíztató: egyszerű, nincs túlzsúfolva minden funkcióval, gyors, és teljes kontrollt ad a generált HTML kódon. Igaz ez utóbbit a többi hasonló megoldás is tudja, viszont nekem úgy tűnt (2 használat után!) hogy tisztább kódot generál. Elkezdtem hazsnálni, majd elválik mennyire jó.

Egy gondom volt vele: az alapesetben átméretezhető szövegdoboz már nem az, ha használjuk a HtmlBox-ot. Ez viszont nem jó, mert van aki szereti ha sok szöveget lát egyszerre. Pl. én.

De szerencsére erre van egy egyszerű megoldás a Resizable Body modul képében. Pofonegyszerű amit nyújt: meg lehet határozni hogy a node  szerkesztő oldalakon a body szövegdoboz hány sorból álljon. Ennyi.

A fenti két modul kombinációja  hasznos eszköz lehet egy sitebuilder kezében, vagy olyan szerkesztőnek aki nem fut anyuhoz sírva, ha meglát egy kis HTML kódot.

Vigyázat, ez az aktuális világmegváltó agyszüleményem! A Drupal Forms API előtt használtam néhány másis űrlap generáló rendszert is, de volt egy funkció, amivel soha nem találkoztam, pedig szerintem sok különböző weboldal hasznát venné.

Miután egy felhasználó kitöltöti, és a szervernek visszaküldi az űrlapot, ne csak azt lehessen eldönteni, hogy a kitöltés helye-e vagy sem, hanem legyen egy figyelmezetető, megerősítő funkció is. Úgy tudom elképzelni ezt a legjobban, hogy ha hiba helyett csak figyelmeztetést adunk ki egy mezőre, akkor az űrlap ugyanúgy megjelenik mint hiba esetén, kiemelve a problémás elemeket, de alul a submit mellett, lenne egy Igen, biztos ezt akarom checkbox. Ezt bepipálva már lefutna az űrlap _submit függvénye.

Miért van erre szükség? Azért, mert a hibás- nem hibás eldöntése túl nagy felelősség. Néha vannak veszélyes (vagy szinte bíztosan rossz) űrlap kitöltések, amelyeket nem szabad rögtön feldolgozni, de teljesen elvenni sem lehet egy ilyen kitöltésnek a lehetőségét.

Tengernyi konkrét példát tudnék mondani amikor erre szükség van:

• Használtautó kereskedő oldal, az árat ezer forintban kell megadni. Erre a felhasználó beírja, hogy 150000. Persze lehet, hogy ez egy 150 milliót érő használt autó, de azért elég valószínűtlen. Jó lenne erre figyelmeztetni.
• Klasszikus példa, és drupal-ban is számtalan helyen van, a törlés megerősítés (delete_confirm fg.) Ha lenne form_set_warning(), nem kellene plussz egy űrlapot definiálni minden egyes törlés funkcióhoz.
• Linkeket akarunk tárolni. A http://www.example.com már bent van a rendszerben, mikor valaki hozzá akarja adni a http://example.com–ot, vagy a http://www.example.com/index.php-t.

Persze, most is el lehet érni ezt a funkcionalitást Drupal-ban (lásd delete_confirm), de csak hegesztéssel, egy form_set_warning-al sokkal elegánsabban meg lehetne oldani ezeket a helyzeteket. Ráadásul, amennyire ismerem a Forms API lelkivilágát, ezt nem is lenne túl nehéz beleimplementálni jól.

Kiváncsi vagyok a véleményetekre, nálatok is felmerültek már ilyen igények?

A Budapesti vidámpark oldala is Drupal alapú. Figyelem, hangszórókat bekapcsolni, fülhallgatót felerősíteni :)

Mondjuk azt nem sikerült kinyomozni, hogy hányas verzió.

Tamás postján fellelkesülve, én is beállítottam itthon a php debug környezetet (PHPEclipse+xdebug). Eddig megvoltam nélküle, de bizony ha egyszer kipróbáljuk, nehéz lesz megválni tőle. Nélkülözhetetlen segítség a mindennapi PHP/Drupal hekkelés közben.

Az Eclipse-et én nem szerettem, és most sem a szívem csücske, de a PHPEclipse-el együtt egy használható eszköznek mondható. A debug melett kifejezetten hasznos funkció a kód kiegészítés és a gépelés közbeni szintaxis elemzés.

Viszont az Xdebug-os környezettel volt két komoly bajom: egyrészt érthetetlenül lassú egy oldal megjelenítése. Érthetetlen, mert sem az sql szerver, sem az apache (+php+xdebug) sem a böngésző kliens nem pörgette a CPU-t, mégis több másodpercig tartott egy oldal megjelenítése. A másik gond, hogy képtelen voltam rávenni az Xdebug-ot, hogy ne definiálja felül a var_dump() függvényt.

A var_dump()-ot sokat használom, főleg a Drupal devel moduljának dvm() függvényén keresztül. De ha belenyúl az Xdebug, a dvm() használhatatlan lesz. A neten (és az xdebug.org/docs-on!) jópár pletyka terjed, hogy miként lehet ezt hatástalanítani. Találtam én mindent, pl ilyeneket:

Érdekes módon nem működnek. Hosszas kutatás után viszont rátaláltam a megoldára: a nevével ellentétben az xdebug.default_enable nem a teljes xdebug-ot kapcsolja ki/be, hanem csak a megjelenítéssel kapcsolatos funkciókat. Tehát ha kikapcsoljuk, attól még a debug működik. Emellett érdemes még kikapcsolni a html_errors standard php.ini kapcsolót is, a teljesen korrekt működéshez.

A másik gond, ami felmerült, a lassú oldal letöltés. Egy E8500-as procin szerintem nem kéne 2-3 másodpercig tartania egyetlen oldal generálásának. Ezt az xdebug.remote_autostart = On beállítás okozta, ami miatt minden egyes oldaletöltés debug session-ként futott le. Ez felesleges, ki kell kapcsolni a fenti funkciót és ha debugolni szeretnénk, elég a GET paraméterek közé felvenni az XDEBUG_SESSION_START=debug_id változót.

Összegezve a fent leírtakat nekem xdebug-ra a következő recept vált be:

A fenti beállításokkal és Tamás leírásával és linkjeivel, teljesen jól használható debug környezetet lehet kialakítani.

Mindenkinek jó rovarírtást.

Nagyon sokat köszönhetek a Drupal-nak, és szeretnék, legalább részben, visszaadni valamit a közösségnek. Mivel programozásban vagyok járatos, a legcélszerűbb, ha készítek egy modult, és mindenki számára letölthetővé teszem a drupal.org-on. Azaz elkészítem első drupal contrib modulom.

Több ötletem is van, olyan funkciókkal, amikre nekem volt szükségerm valamikor, de nem találtam megfelelő kész modult.

Azért, hogy ebből a dolgoból, a lehető legtöbbet hozzam ki, azaz a Drupal közösség számára a lehető leghasznosabb dolgot készíthessem el, szeretném ha Ti döntenétek el, mit valósítsak meg contrib modul formájában.

Az ötleteim dióhéjban:

1. Látogatottsági és feed olvasottsági statisztika

Minden oldalletöltést naplóz a modul és egy AwStats-hoz hasonló táblázatban megmutatja a látogatottságot napi, heti, havi, évi bontásban. Emelett a feed-ek olvasottságát is naplózza és arról is mutat egy statisztikai oldalt. Néhány blokkot is biztosít a modul, egy például a feedburner widget-hez hasonlóan a feed-ekre feliratkozott olvasók számát jelenítené meg. Természetesen minden információ megjelenítése jogosultsághoz kötött, így csak azok látják akiknek erre jogot ad az oldalgazda.

2. Blokkok gyorstárazási (cache) paramétereinek szerkeszthetővé tétele

Nagy örömömre szolgált mikor megtudtam, hogy a Drupal 6-ban a blokkok gyorstárazása az egyszerű ki/be állapotnál lényegesen fejlettebb lesz: kinek és meddig mutassunk gyorstárazott információt. Lássuk be, a Drupal nem a sebességéről híres, így erre nagy szükség van.

Viszont döbbent arccal fogadtam, hogy a finomhangolást nem lehet az admin felületen elvégezni, csakis a blokkot biztosító modul fejlesztője szabályozhatja a gyrstárazási paramétereket. Szerintem ez rossz megközelítés, nem csak a blokk tartalmától, hanem a weboldal típusától is függ, hogy ezeket hogyan érdemes beállítani.

A modul egyszerűen egy admin felületet biztosít, ahol ezeket a paramétereket átállíthatjuk.

3. Képgaléria tömeges importálási lehetőséggel

Itt a nyár, az ember sokat utazik és közben kattintgatja a fényképezőt. Nagy mennyiségű kép gyűlik össze ilyenkor. Szeretnék készíteni egy olyan képgaléria megoldást, amely lehetővé teszi hogy egy zip fájl feltöltésével automatikusan importálásra kerüljenek a benne lévő képek. A feltöltés történhet webes felületen, vagy közvetlenül a tárhelyre pl. FTP-vel.

Emellett jónéhány egyéb dologra is szükség lehet: hozzáférés szabályozás jogosultságokkal, dátum szerinti galériák, hozzászólás és szavazás (a képek node-ként élenk), több méret egy képhez, esetleg EXIF adatok kinyerése.

4. Form builder adatbázis sémából

Ez egy meglehetősen régi ötlet: a szoftver fejlesztőket segítsük egy olyan eszközzel, amely a már meglévő adatbázis séméhoz automatikusan generál minden táblához listázó, beszúró, szerkesztő és törlő űrlapot.

Alapvetően hasznos segítség, meggyorsítja a munkát. Általános PHP megoldást már készítettem, ez volt a diplomamunkám. Most készítenék egy teljes mértékben Drupal-ra szabott megoldást. Több kérdés is felmerül a feladat kapcsán, a legfontosabb hogy kódgenerálással vagy API használatával jöjjenek létre a megfelelő űrlapok. A jobb testreszabhatóság miatt a kódgenerálás tűnik célravezetőbbnek, de az API-t sem vetem el első körben. Ez további kutatást igényel.

5. Felhasználói aktivitás naplózása IP szinten

A Drupal közösségi oldalakban a legerősebb. De valóban nagy forgalmú közösségi oldalak esetében a visszaélés (spam,flood,stb…) reális veszély. A modul minden regisztrált felhasználó minden tevékenységét (regisztráció, bejelentkezés, tartalom és hozzászólás beküldés, szavazás) naplózná és, hogy ez az akció milyen IP címről történt. Ennek segítségével kideríthető, hogy kik azok akik több különböző felasználálói névvel regisztráltak az oldalra, és az IP alapú tiltás hatékonyabb eszközzé válhatna.

Ennek a postnak a hozzászólásaiban várom a „szavazatokat”, hogy melyik feladatba vágjak bele. Emellett persze jöhetnek avaslatok, hogy a fenti modulokat hogyan lehetne még jobbá, használhatóbbá tenni.

A hozzászóláshoz nem kell (nem is lehet) regisztrálni, az email címeket bizalmasan kezelem, senkinek nem adom oda, és reklámot sem küldök.

Most lelépek a Szegedi konferenciára és maradok a Code Sprint-en is. Valószínüleg ott nekifogok a munkának, ha valakinek van kedve, csatlakozhat.