No, it’s not easy. I keep history of my webpage in Subversion, so every time I need to upgrade WordPress I need to add the new version into Subversion in the vendor branch, merge in the changes in a WordPress current branch and then merge the changes into trunk of my web page. Why I do this, you say? No software is perfect, WordPress is far from it, so I need to alter some core code from time to time. That’s why.

Ok, back to the topic. Matt Mullenweg does not tell me in his blog post (link above) anything about what versions of WordPress that are potential targets for this Internet worm that exploits this security breach, nor what part of the code that makes it possible, not even how to patch it up. The entire blog post is just explaining that security holes do happen and some theory about how to protect yourself from it. Nothing concrete. Not very useful.

The blog entry 5 Essential Tips for Overcoming WordPress 2.8 Performance Problems describes some severe issues that WordPress blogs has, especially regarding bad performance.

In short: “Deal With It.”

Dersom man kun beholder én PHP-fil, som vi kaller for “loader”, i rotkatalogen til pluginen kan ytelsen økes noe. Denne filen inneholer plugin-headeren og den eneste oppgaven til denne filen er å laste de resterende filene i pluginen. Denne loaderen vil videre laste en kontroller i en katalog vi kan kalle for “core”. Denne kontrolleren har som oppgave å sette opp hooks for å intregere mot WordPress og ellers kontrollere dataflyten i pluginen.

Den viktigste grunnen for å organisere filene sine er for å få bedre oversikt. En måte å gjøre dette på er å benytte underkataloger basert på funksjonalitet og filtype. For eksempel kan man plassere alle Javascript-filer i en “js”-katalog og alle CSS-filer i en “css”-katalog. Dersom pluginen din skal ha et administrasjonsgrensesnitt kan disse filene legges i katalogen “admin”, og en widget-støttet plugin kan ha widget-relaterte filer i en “widget”-katalog. All denne strukturen krever litt ekstra koding og flere filer å holde styr på, men til gjengjeld slipper man å se sine filer vokse til store monstere på flere tusen linjer. Store filer kan lett bli et problem, noe jeg selv har erfart i utvikling av WordPress-plugins.

Eksempel på katalogstruktur for en plugin av passe stor størrelse:

my_plugin_loader.php
/actions/controller.php
/actions/widget.ajax.php
/admin/options.php
/core/my_plugin.php
/css/admin.options.css
/css/widget-css.php
/js/script-loader.php
/js/some_lib.js
/js/widget-js.php
/languages/my_plugin-nb_NO.po
/languages/my_plugin-nb_NO.mo
/widget/widget.control.php
/widget/widget.php


Jeg har her brukt noen passende filnavn. Det er ofte ikke nødvendig å spesifisere katalognavnet som en del av filnavnet, men av og til kan det være smart, avhengig av hvilken editor som benyttes. Selv benytter jeg Eclipse som viser kun filnavnet, og det kan være vanskelig å skille tre åpne filer som alle heter “control.php” fra hverandre.

Jeg har tatt med i eksempelet en fil som heter “script-loader.php” som kan benyttes for å laste Javascript-filene. WordPress har funksjonalitet for å registrere Javascriptene med navn, URL og avhengigheter. Det er også mulig å spesifisere versjon av Javascriptet, som blir en del av URL-adressen til filen. Dette er svært aktuelt for å tvinge nettlesere til å laste den nye Javascript-filen fremfor å benytte en som kan finnes i en cache ett eller annet sted.

Man kan ha behov for å kalle på funksjonalitet i pluginen som ikke skal benytte det vanlige themet til WordPress, men kanskje bare returnere noe data til et Javascript, utføre en oppdatering eller printe ut en CSS- eller Javascript-fil. Man kan dermed ha behov for en egen front-kontroller som tar seg av disse forespørslene.

Jeg benytter PHP5 og objektorientering for å utvikle plugins til WordPress, men tankene og forslagene i denne artikkelen kan like gjerne benyttes med en strukturell programmeringsmetodikk. Jeg synes det er alt for mange dårlig skrevne plugins for WordPress, hacket sammen for å gi funksjonaliteten som er ønsket på det gitte tidspunktet. Dette gjør det vanskeligere å vedlikeholde dem senere når nye krav kommer og det gjør integrasjon med andre plugins og nyere versjoner av WordPress til et mareritt. Disse pluginene benyttes så som et utgangspunkt for nye plugins ved hjelp av copy/paste-metoden. Jeg tror at bedre dokumentasjon med gode eksempler kan bidra til bedre kodestandard på plugins.

Det er en handlingskrok (action hook) som heter “init” som blir kalt på rett før themet skal lastes inn for presentasjon av postene. Når denne kroken skal eksekveres er plugins lastet og innstillinger lest fra databasen, så denne kroken egner seg svært godt for det jeg nå skal vise, nemlig hvordan man kan kalle på funksjoner i sin egen plugin med via lenker på siden, med HTML forms eller via Javascript og AJAX.

Jeg har ofte hatt behov for å kalle på funksjoner i min plugin fra Javascript på siden, også kjent som Ajax/Web2.0. Jeg har utviklet en plugin som lar brukeren sette et filter, slik at kun innlegg som matcher dette filteret vil bli vist. Jeg skrev denne pluginen på jobben og den er foreløpig kun for internt bruk og er derfor ikke tilgjengelig, men det hindrer meg ikke i å forklare hvordan jeg har brukt denne teknikken.

Dette filteret settes i cookie i nettleseren til brukeren slik at filteret er aktivt helt til brukeren bytter til et annet filter. Filtere kan ligge i nivåer underhverandre. Tenk på det som kategoriene i WordPress, hvor kategorier kan ha en forelderkategori. Jeg skal her vise to eksempler hvor jeg først bruker en link for å bytte til et annet filter, for så å vise hvordan jeg bruker AJAX for å hente en liste med filter.

Linken for å bytte filter kan for eksempel se slik ut:

<a href="http://example.com/?myplugin=set&filter=sport">Sport</a>


Da har jeg behov for en sjekk i min plugin, som jeg har valgt å kalle “myplugin” (ja, jeg vet, men dette er ikke navnet på min ekte plugin ), for å kunne snappe opp ønsket om å bytte filteret til “sport”. Jeg har valgt kodeordet “myplugin”, det samme som navnet på pluginen jeg har skrevet for å minke risikoen for navnekollisjon. Jeg har en funksjon jeg har hengt på “init”-kroken som sjekker om kodeordet er blitt angitt i adressen samt om det finnes en passende handling å utføre.

I eksempelet nedenfor viser jeg også PHP-kode som tar i mot ønsket om å liste ut alle filtere som har et angitt filter som forelder. Legg merke til dersom testen matcher ‘list’ vil den printe ut listen for så å dø, hardt og brutalt. Dette er faktisk ønskelig fordi vi skal utføre et asynkront kall med Javascript, noe som betyr at nettsiden ikke skal lastes på nytt, men bare en liten del av nettsiden skal oppdateres. Det som PHP-scriptet skriver ut i eksempelet nedenfor blir hentet opp av Javascriptet som utførte kallet, klar til å inkluderes på nettsiden. Om det er en <select>-liste, en rekke med checkboxer eller noe annet som gjøres med denne listen bestemmes av Javascriptet.

$myplugin = new MyPlugin();
add_action('init', array(&$myplugin, 'check_action'));
//
// Hovedklassen i min plugin
class MyPlugin {
    function check_action() {
        $action = _REQUEST['myplugin'];
        switch($action) {
            case 'set':
                $this->set_filter($_REQUEST['filter']);
                break;
            case 'list':
                $list = $this->get_list($_REQUEST['parent']);
                echo $list;
                exit;
        }
    }
    // Setter nytt filter
    function set_filter($filter = '') {
        // Setter en cookie for brukerens nettleser
    }
    // Returnerer en liste med filtere som har en angitt forelder
    function get_list($parent = '') {
        // finner og returnerer listen med angitt forelder
    }
}

Hvordan Javascriptet som utfører dette asynkrone kallet er programmert skal jeg ikke komme inn på her. Det er et for stort tema å skrive om i denne artikkelen, men det finnes gode ressurser på Internett om AJAX, Google vet det meste. Det kan være verdt å sjekke ut Cross-Browser XMLHttpRequest, som gjør det enklere å bruke Ajax uten at man vrir seg i smerte over de mange forskjellige teknikkene som er brukt i nettlesere.

Dersom man utvikler nettsider som skal ha støtte for flere språk er det vanskelig å komme utenom UTF-8, unicode. Ofte vil man teste på en variabel om den matcher et sett med konstanter eller andre variable som brukere skriver inn. Brukere er generelt sett svært ustabile når det gjelder hva input som kan komme inn til serveren, spesielt når det gjelder bruk av store og små bokstaver.

Et eksempel på dette er tagger i WordPress. Hvorfor skal man måtte ha to separate tagger som betyr det samme bare fordi den ene ble skrevet med stor forbokstav mens den andre med liten? Her kan det være kjekt å bruke PHP-funksjonen strtolower, helt til man kommer til spesielle bokstaver og tegn som ikke finnes i tegnsettet man normalt bruker, ofte ISO-8859-1 av en variant. Dette kan fungere greit dersom teksten som kommer inn er i samme tegnsett som serveren benytter, men når det gjelder unicode så er saken annerledes.

Strenger eier ingen informasjon om hvilket tegnsett som benyttes, dette må utviklere holde orden på. Funksjonen strtolower takler unicode svært dårlig. Spesielle tegn, som de norske bokstavene æøåÆØÅ, kodes i unicode med lengden av to vanlige bokstaver. Dette fører til at strtolower deler disse tegnene i to før den utfører konverteringen. Resultatet av dette blir mest sannsynlig et uventet tegn som nettleseren har problemet med å vise. Selv har jeg sett ?-tegnet ganske ofte

Løsningen rundt dette problemet er å benytte PHP-funksjonen mb_convert_case. Som vist i eksempelet konverteres tekststrengen til små bokstaver, lowercase:


// UTF-8 tekststreng
$orig_string = 'Hei på deg. Hvordan er været i Østfold?';
$new_lower = mb_convert_case($orig_string, MB_CASE_LOWER, 'UTF-8');
echo $new_lower;


Funksjonen echo vil her skrive ut: hei på deg. hvordan er været i østfold?

Den første parameteren til mb_convert_case er tekststrengen som skal konverteres, mens den andre angir hvilken type konvertering som skal utføres, i form av en konstant. Følgende konstanter kan gis til mb_convert_case:

• MB_CASE_LOWER: konvertere til små bokstaver
• MB_CASE_UPPER: konvertere til store bokstaver
• MB_CASE_TITLE: konvertere til stor forbokstav i hvert ord

Funksjonen mb_convert_case tar også en parameter som forteller hvilket tegnsett som ønskes brukt ved konvertering. På noen forum og mailinglister foreslås det at man kan bruke funksjonen setlocale før strtolower for å sette hvilket tegnsett som skal benyttes, men dette hjalp ikke i mitt tilfelle. Funksjonen mb_convert_case tar utgangspunkt i at tekststrengen er i unicode og klarer derfor å konvertere norske spesialtegn på en utmerket måte.

Løsningen på ytelsesproblemet kom med eAccelerator, en cache-løsning for PHP som cacher de kompilerte PHP-filene, slik at PHP ikke behøver å lese og kompilere alle PHP-filene for hver sidelasting. Andre nettbaserte løsninger som for eksempel benytter Java EE (Enterprise Edition) har en server som hele tiden kjører selv om ingen brukere besøker siden. Fordelen med dette er at alle filer med tilhørende klasser og andre ressurser allerede er lastet inn i minnet på serveren, noe som sparer diskaktivitet og prosessorkraft når brukere besøker siden din.

I dette prosjektet ble versjon 0.9.5 av eAccelerator benyttet. Uten å kjøre nøyaktige benchmarktester så virket denne løsningen betraktelig raskere; sidene lastet raskere i nettleserene og serverloaden er blitt gjennomsnittlig lavere.

eAccelerator finnes ikke i pakkesystemene til Ubuntu eller FreeBSD, så denne må manuelt lastes ned og kompileres. Man trenger dev-pakkene for PHP for å kompilere eAccelerator, da man trenger verktøyet phpize. Dev-pakken på Ubuntu heter php5-dev, eller php4-dev dersom denne versjonen benyttes.

phpize
./configure --enable-eaccelerator \
--with-php-config=/usr/bin/php-config
make && make install


Deretter må den aktuelle php.ini-filen som Apache benytter seg av for mod_php oppdateres med følgende innstillinger. Bemerk at kun første linjen er påkrevd. Standard katalog for cache-filene er /tmp/eaccelerator, så denne må opprettes og det må gis skriverettigheter til brukeren som Apache kjører som. På distribusjoner hvor /tmp katalogen slettes ved booting av operativsystemet bør cache_dir settes til en annen katalog, for eksempel /var/cache/eaccelerator. Verdiene i eksempelet nedenfor er hentet fra eAccelerator – Installing from source.

extension="eaccelerator.so"
eaccelerator.shm_size="16"
eaccelerator.cache_dir="/tmp/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"


WordPress har et litt rufsete rykte, blant annet på grunn av at en WordPress-side ikke tåler trykket dersom en artikkel skrevet i en WordPress-blogg havner på forsiden av for eksempel Digg. Muligens kan en slik cache-løsning være redningen for WordPress, og forsåvidt andre PHP-applikasjoner.

Oppdatering 07.03.2007 08:38 CET
Et problem med eAccelerator er at instansvariabler deklarert med protected vil få eAccelerator til å krasje dersom en klasse som arver på denne forsøker å aksessere disse protected variablene. Løsningen på dette er å deklarere dem som public. Ikke spesielt god designmetodikk, men det fungerer…