drupal

Az Xdebug lassú és nem hagyja békén a var_dump()-ot

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:

xdebug.overload_var_display = 0
// vagy
xdebug.overload_var_dump = 0

É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:

; var_dump felülírás hatástalanítása
xdebug.default_enable = Off
html_errors = Off

; debug funkciók bekapcsolása, de
xdebug.remote_enable = On

; debug session automatikusan ne induljon.
xdebug.remote_autostart = Off

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.

Milyen modult fejlesszek Nektek?

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.

Mi a közös bennük: Firefox 2, MySQL 3, PHP4, Drupal 5?

Több mint két hete már, hogy megjelent a Firefox 3, kiváncsi lettem, hogy mennyien tértek át. Az F1világ látogatottsági statisztikája alapján az összes Firefox felhasználóból 17% tért át a 3-as verzióra. Ami kevés, szerintem.

Akkor mégis mi is a közös a Firefox 2, MySQL 3, PHP4 és Drupal 5-ben?

Nem, nem csak az hogy internettel kapcsolatos szoftverek, hanem az, hogy túl jól sikerültek, és kevesen tértek át az újabb verziókra.

A MySQL 3 hírhedt arról, hogy mennyi helyen használják, PHP4 szintén, és úgy néz ki a Drupal 5-el is ez a helyzet. Bár ez a hír valószínüleg lendít majd a Drupal 6 elterjedésében. Legalábbis remélem. Az FF3 penetráción meg egy Firebug dobna sokat, szerintem.

Hírek megjelenítése egyszerűen Drupal-al

Egy barátom megkért, hogy segítsek neki összeállítani egy nagyon egyszerű weboldalt: mindössze annyi volt a kérés, hogy egy oldalon egymás alatt hírek jelenjenek meg, fent a legfrissebb. Hírt feltölteni mindössze egy ember tudjon, a megfelelő jelszó birtokában.

Ezt ugyebár a Drupal alapkiszerelésben már tudja, a feladat egyetlen érdekes pontja, hogy az amúgy pilótavizsgás Drupal kezelőfelületet szabjuk a lehető legegyszerűbb formára.

Elkészítettem az oldalt (sminkelés nélkül) és úgy gondoltam, hasznos, ha megosztom másokkal is, melyek voltak a megfelelő lépések:

Modulok - admin/build/modules

Minden modult kikapcsoltam, kivéve:
- Database logging - nem zavar, nem árt
- Path - szép úrl-ekhez, hogy a "/node/13245" helyett "/Szenzacio" legyen a címsorban
- Taxonomy – bár nem volt feladat, egy egyszerű cimkézést (tag-elést) készítek. Ha nem kell cimkézés, ki lehet kapcsolni
- Update status - szól, ha van új Drupal

Felhasználó beállítások - admin/user/settings

"Only site administrators can create new user accounts" – csak az adminisztrátor hozhat létre új felhasználókat.

Blokkok - admin/build/block

"User login" blokkot kikapcsoltam. Az adminisztrátor itt léphet be:
http://example.com/?q=user

Új felhasználó csoport - admin/user/roles

új "role", de felfogható user csoportnak is: "content admin"

Új felhasználó - admin/user/user

létrehotam egy új felhasználó-t, "content admin" role-al.

Tartalom típusok - admin/content/node-type/story

"Story" és "Page" tipusok szerkesztése. Én ezt úgy szoktam, hogy a Story legyen a "hír", a page meg statikus "oldal", ami nem jelenik meg a híráramban, de van neki url-je jól és lehet rá linkelni. Ennek megfelelően a story "published to front page" a "page" viszont nem. Ennél a feladatnál csak a Page típus kell.

Cimkézés - admin/content/taxonomy

Itt létre kell hozni egy új taxonomy-t, ami csak a "hír" tartalomtípusra vontakozik, beállításait tekintve a "free tagging" opciót kell bepipálni.

Jogosultságok - admin/user/permissions

Ez a lényeg, itt egyszersítünk a felületen. Egy kis elmélet: minden felhasználó tagja vagy az anonymous vagy az authenticated csoportnak. Ezért authenticated-től is el kell venni mindent, amit csak lehet, és content adminnak adni pár dolgot, amire szüksége van:
create page content, delete own page content, edit own page content

Mindössze ennyi, ha most belép a tartalom menedzser, akkor egy roppan egyszerű hírfeltöltő űrlapot lát, semmi mást.

A híreknek lehet url álneveket adni (un. url alias), amit érdemes megtenni. Így egy hír nem node/1234 címen fog megjelenni, hanem "/Valami-nagyon-erdekes" címen. A jelenlegi megoldásban ezt kézzel kell megtenni, de már van egy külön bejegyzésem, hogyan lehet automatizálni a szép url-eket Drupal-ban.

Oldalak

Feliratkozás RSS - drupal csatornájára