A WordPress formázási túlbuzgóságának leküzdése

Abban minden felhasználója egyetért, hogy a WordPress egy kiváló rendszer, melynek előnyeit hosszú lenne végigsorolni. Amit viszont ehhez gyorsan hozzá szoktak fűzni az az, hogy csak az editora ne lenne olyan hülye.

Tulajdonképpen azzal sincsen semmi baj, csak hát őrajta csapódik le az a kellemetlen jelenség, hogy a WP lépten-nyomon borsot tör az ember orra alá, mivel a legváratlanabb pontokon nyúl bele az oldal HTML kódjába. Alapvetően ez egy igen dicséretes törekvés, mert amit csinál, azt a felhasználó védelmében teszi – be akar neki segíteni a formázásban, a szabványok betartásában stb.

Meglehet, ez sokakat nem is zavar, sőt lehet, hogy észre sem veszik. Akik megelégszenek a vizuális editorral, és abból is csak 3-4 gombot használnak (ímhol a bölcsesség!), azok minderre valószínűleg csak legyintenek.

Aki viszont ért valamit a HTML-hez, vagy akinek kényszerűségből kell matatnia benne, azt időnként az idegbaj kerülgeti. Márpedig ilyesmi mindenkinél előadódhat, mert pl. egy autoresponder űrlapot csak az oldal HTML nézetében lehet beszúrni.

Odáig nincs is semmi baj – űrlap beszúrva, oldal mentve, júzer boldog. Hanem egyszer csak észreveszi, hogy az űrlap nem működik, vagy nem úgy mint kellene, és máris megy a hibajelentő, hogy hibás az autoresponder. Pedig az köszöni, jól van, és csupán annyi történt, hogy az illető módosított valamit az oldalon, kijavított egy helyesírási hibát vagy ilyesmi, és újból elmentette az oldalt. A WP viszont résen volt, és megnyitásnál vagy mentésnél, ki volna a megmondhatója, hogy mi okból, megcenzúrázta a kódot.

Van amikor nem ennyire súlyosak a következmények, csak a formátum romlik el: a sortörések paragrafus végjelekre cserélődnek stb., ráadásul úgy, hogy kicsit bonyolultabb esetben még a nyitó és záró tegek száma sem mindig egyezik.

Ha aztán az ember kínkeservesen helyrehozza a dolgot, akkor egy mentést esetleg (nem biztos!) változás nélkül kibír az oldal, de újbóli megnyitás és mentés esetén térdre imához, mert fáradozásunk a WP-t hidegen hagyja, és megint beleokoskodik valamit.

Ha a gúgliban rákeresel, százezrével panaszkodnak az itt vázolt okból kifolyólag, de használható megoldással vajmi kevesen tudnak előrukkolni. A fejlesztők pedig valami ismerhetetlen okból bármire hajlanak, de az editort szent tehénként kezelik, és úgy tesznek, mintha minden a legnagyobb rendben volna. Misztérium magnum. Allah hatalmas, és Mohamed az ő prófétája.

A haladottabbak általában azt szokták javasolni, hogy le kell tiltani a vizuális editort, és kizárólag HTML-ben kell dolgozni. Ez egy nagyon szimpatikus és valóban működő megoldás, de csak annak, akinek a HTML nem teljesen kínai. Akitől viszont eléggé el nem ítélhető módon természeténél fogva idegen mindenféle programozási és lapleíró nyelv iránti beteges vonzalom, arra ez a mantram teljességgel hatástalan.

A WordPress formázási filozófiája

Mielőtt azonban kíméletlenül és önző módon pálcát törnénk a WP fejlesztők lelkes csapatának feje fölött, illik meghallgatni őket is, mit tudnak felhozni saját mentségükre (lásd pl. a Codex-ban).

A WordPress többszörösen feldolgozza a szerkesztő panelen bevitt szöveget, mielőtt az megjelenne a látogatónak a böngészőben. Ennek során kiszűri a nemkívánatos kódrészleteket, és megkísérli a tartalmat olyan formára hozni, amin a böngésző garantáltan nem hasal el a megjelenítéskor. Evidens, hogy ha tovább akarunk nyújtózkodni, mint ameddig a WP szerint a takarónknak érnie megadatott, akkor ez nemkívánatos módosításokhoz is vezethet.

A módosítások és a szűrők zöméért a wp-includes/formatting.php fájl a felelős.  A szokásos problémák közül néhány, ami miatt a júzerek haja az önkezűség amúgy teljesen értelmetlen aktusa okán leginkább fogyatkozni szokott:

• Az üres bekezdések, záró </span> elemek és sortörések mentéskor eltűnnek a szövegből.
• A class-ok (CSS osztályokra való hivatkozások) eltűnnek a HTML elemekből.
• A <div> elemek <p>-vé (sima bekezdésekké) változnak.
• A Javascript és egyéb kódrészletek megjelenített szöveggé alakulnak át, ahelyett, hogy a böngésző végrehajtaná őket. (A Javascript beszúrásának egyébként külön tudománya van, de az ember mindig reménykedik, hogy hátha anélkül is meg tudja úszni a dolgot.)

Nézzük meg kicsit közelebbről, hogy a megjelenítés előtt milyen lépésekben gyomrozza meg a WP a szöveget.

TinyMCE

A TinyMCE a WordPress által használt vizuális szerkesztő (Rich Text Editor). Nem kötelező használni, ha elég jó vagy a HTML-ben, akkor egy kattintással kikapcsolhatod (Felhasználók / Szerzők és felhasználók / Profil / Személyes beállítások / Vizuális szerkesztő / Szövegszerkesztő kikapcsolása bejegyzés írásakor). Ha tehát több admin vagy szerző van, akkor ez mindenkinek a saját ízlése szerint működhet vagy nem működhet.

A wpautop() függvény

A wpautop() a wp-includes/formatting.php fájlban található, és a WP központi magjához tartozik. Nevében a p betű arra utal, hogy elsődleges célterülete a paragrafusok (bekezdések) megbecstelenítése. Mindenféle gyanús műveletekkel igyekszik a kétbalkezes szerzők által lépten-nyomon elkövetett baklövéseket korrigálni, ezért aztán aki nem annyira kétbalkezes, annak nagyon gyakran akaratlanul is keresztbe tesz. Ez alakítja át a sortöréseket, bekezdés elemeket, ez pótolja a hiányzó nyitó és záró tegeket, és szűri ki ezek figyelmetlenségből elkövetett duplázásait stb.

A wptexturize() függvény

A wptexturize()) szintén a wp-includes/formatting.php fájlban csücsül. Ez sokkal ártalmatlanabb, mint az Autop, mivel az ő csőszködése abban merül ki, hogy a szöveget könnyebben olvashatóvá és szemrevalóbbá tegye.

Ennek is lehet persze nemkívánatos mellékhatása, pl. ha egy kódrészletet szúr be valaki valamilyen programozási nyelven, amelyben az amúgy ártatlannak tűnő szöszmötölés is szintaktikai hibákat eredményezhet.

A Texturize szűrő kedvenc hobbijai közé tartozik pl. a közönséges idézőjelek nyomdaira cserélése, a sima zárójelbe tett c, r és tm lecserélése ©, ® és ™ szimbólumra, számok szorzásánál a kétségtelenül pórias x leváltása a sokkal elegánsabb × jelre, vagy hogy a három egymásutáni – helyett — (&mdash;), a kettős kötőjel helyett – (&ndash;) és a mezei három különálló pont … helyett az összehasonlíthatatlanul vagányabb, egykarakteres … jelenik meg.

A convert_smilies() függvény

A szokásos, kettőspontokból, zárójelekből és egyéb karakterekből összeeszkábált sima szöveges hangulatjeleket cseréli le azok grafikus megfelelőire. Ez egyébként admin szinten letiltható (Írási beállítások). Ez a konverzió nagyobb galibát nem okoz — legfeljebb rondán fest, ha mondjuk olyan a sablon képkezelése, hogy pl. alapból vastag szürke kerettel szereti körbevenni a képeket. A csere szükséges feltétele, hogy a hangulatjel előtt és után szóköz legyen.

Karakterek konverziója

A formatting.php számos további függvényt is tartalmaz, amelyek különféle ékezetek, egzotikus nemzeti karakterek, miegyebek helyettesítésére vannak idomítva. Ide tartozik pl. a & jel és bizonyos Unicode karakterek átírása HTML entitásokká. Ezek a szűrők nem csapnak különösebb zajt, legfeljebb néha nem őrölnek teljesen egy malomban a böngészővel, ha annak meg másmilyen a beállítása.

Hogyan iktassuk ki a nemkívánatos szűrőket

A legegyszerűbb keményen belenyúlni a WordPress kódjába, bár ettől mindenki óva inti a közönséges halandókat. A belenyúlásnak lehetnek mellékhatásai, és minden verziófrissítéskor elvesznek, tehát időnként újra meg újra el kell végezni ugyanazt az operációt. (Nem szeretnék rossz példával előljárni, de töredelmesen bevallom, hogy én így csinálom.)

Kíméletesebb módszer, ha pl. egy jobb editorra cseréled le a kincstári TinyMCE-t, amelynél letiltható a paragrafus-jelek manipulálása (pl. TinyMCE Advanced). Időnként azonban ez is el tud bambulni – pl. a legutóbbi verziófrissítésnél mintha elkezdett volna megint visszajönni az eredeti állapot. Nagyobb energiát nem fecceltem a pontos diagnózisba, mivel a csábítás, hogy gyors és hathatós tüneti kezelést alkalmazzak, erősebbnek bizonyult. (Mondtam már, hogy mindennek ellen tudok állni, kivéve a csábítást?)

A WordPress.org  egyébként azt ajánlja, hogy nézzünk szét a bővítmények között, ahol számos olyan plugin található, amellyel korlátok között tartható az említett szűrők ügybuzgalma.

Én egyetlen ilyen pluginról tudok: úgy hívják, hogy Raw HTML (nyers HTML).

A Raw HTML plugin

Ennek a bővítménynek a segítségével elvileg korlátozás nélkül be lehet rakni bármilyen HTML kódot, CSS blokkot vagy Javascript kódot a bejegyzések ill. statikus oldalak szövegébe. Ehhez a kívánt részletet két speciális teg (egy kezdő és egy záró elem) közé kell tenni, és akkor a WP ezt békén fogja hagyni.

A bővítmény hozzáad néhány checkboxot (pipálható négyzetet) a szerkesztő képernyőhöz, amelyekkel bizonyos  WP szűrőket bejegyzésenként (oldalanként) is le lehet tiltani. Ily módon a következőkre nyílik lehetőség:

• A wptexturize szűrő kikapcsolása (nyomdaibb megjelenés, ld. fentebb)
• Az automatikus paragrafus-konvertálás kikapcsolása (wpautop szűrő)
• A convert_smilies kikapcsolása (a grafikus hangulatjelek letiltása)
• A convert_chars szűrő kikapcsolása.

A plugin használata

Azt a kódrészletet, amelyet meg akarunk kímélni a WP imént emlegetett szűrőitől, egyszerűen <!–start_raw–> és <!–end_raw–> közé kell tenni. Ehelyett használható ugyan a [RAW] és [/RAW] páros is, de csak addig, amíg a plugint ki nem kapcsolod. Ezek ugyanis utána láthatóvá válnak a böngészőben, míg a másik csak HTML szerkesztési nézetben mutatja magát, mivel gyakorlatilag HTML komment formája van, ami ugyebár sem a böngészőben, sem a vizuális editorban nem jelenik meg.

A plugin szerzője szerint a nyers HTML/JS/CSS kódot tartalmazó oldalak szerkesztéséhez a plugin használata közben is célszerű lehet a vizuális editor kikapcsolása.

A wpautop szűrő rövid úton való kiiktatása

Én úgy vagyok vele, hogy nem szeretek feleslegesen pluginokat használni, és kétszer is meggondolom, hogy mikor telepítsek egy újabbat. A pluginok használata jár ugyanis némi veszéllyel: összeakadhatnak egymással, nem mindig – vagy csak késve – követik a WP verzióváltásait stb. Ezért aztán a WP-nek ezt a “kódbarát” viselkedését úgy oldottam meg, hogy egy határozott mozdulattal mindenestől kiiktattam a wpautop szűrőt.

Azért csak ezt, mert a többi igazán nem sok vizet zavar. (Ha kiviláglik, hogy mégis, hát azok is erre a sorsra jutnak.)

Hangsúlyozom azonban, hogy bár eddig semmi káros mellékhatást nem észleltem, e részben csakis saját felelősségedre kövesd a példámat.

A “megoldás” annyiból áll, hogy meg kell nyitni a wp-includes mappában terpeszkedő formatting.php fájlt, és meg kell benne keresni a wpautop függvényt. A 2.9.2 verzióban ez a 180. sor környékén van, és a sortörésektől eltekintve így kezdődik:

function wpautop($pee, $br = 1) {
if ( trim($pee) === ” ) return ”;
$pee = $pee . “\n”; // just to make things a little easier, pad the end

stb.

Nos, lehetne másképp is, de én úgy oldottam meg, hogy a $pee = $pee kezdetű sor elé beszúrtam egy üres sort, amelybe beírtam a következőt: return $pee; — ami után tehát a kezdő részlet imígyen néz ki:

function wpautop($pee, $br = 1) {
if ( trim($pee) === ” ) return ”;
return $pee; // Ez a sor kiiktatja a wpautop-ot.
$pee = $pee . “\n”; // just to make things a little easier, pad the end

stb.

Természetesen a módosított fájlt vissza kell írni a wp-includes mappába.

Egyéb bővítmények Javascript kód beszúrására

Anélkül, hogy belemennék a részletekbe, hogy ilyen címszóval több plugin is létezik a wordpress.org/extend/plugins/oldalán. Némelyikük speciális célt szolgál, pl. az oldalsávi widgetekben teszi lehetővé Javascript kód veszélytelen elhelyezését. Ilyen bővítmények többek között a következők:

• inline-javascript
• JavaScript to Footer
• JavaScript Block Widget
• Include JavaScript Widget
• HTML Javascript Adder
• You Can Javascript

(Megj.: A formatting.php-nál azért a 2.9.2-re hivatkoztam, mert korábbi tapasztalataimon okulva – és a lassan járj, tovább érsz népi bölcsességét megszívlelve – én csak tisztes távolból követem a WP verzióváltásait. Különösen akkor, ha nagy ugrásról van szó. Akkor és csak akkor térek át az aktuális változatra, ha majd kijönnek a 3.1-es verzióval, amelyben várhatóan több tucat hibát fognak javítani.)

Ha az itt elmondottaknál jobb ötleted vagy megoldásod van, szívesen veszem, ha megosztod velünk. Ugyanez vonatkozik az egyes megoldásokkal kapcsolatos kérdésekre ill. tapasztalatokra is.