Da bestemte jeg meg for å teste Perl-applikasjonen min for sikkerhetshull. Denne applikasjonen er svært enkel. Den har ett HTML-skjema med ett input-felt, og data fra dette feltet blir listet ut på forsiden. “Shout” heter det, enkelt og greit. Jeg fyrte avgårde alle testene i XSS Me mot dette skjemaet og fikk ørten sikkerhetsvarslinger i retur. Dette løste jeg riktignok med en enkel pipe igjennom html-filteret til Template Toolkit.

Vi utforsket dette videre. Kameraten min smalt opp et lite PHP-script som tok innholdet fra et textarea-felt og viste det uendret ut på HTML-sida. Vi fant fort ut at PHP gjorde noe magisk bak scenen, som PHP så gjerne ofte gjør; magic quotes heter det. Men jeg lurte jæveln…


<script>
 window.location=String.fromCharCode(104)
  + String.fromCharCode(116)
  + String.fromCharCode(116)
  + String.fromCharCode(112)
  + String.fromCharCode(58)
  + String.fromCharCode(47)
  + String.fromCharCode(47)
  + String.fromCharCode(103)
  + String.fromCharCode(111)
  + String.fromCharCode(111)
  + String.fromCharCode(103)
  + String.fromCharCode(108)
  + String.fromCharCode(101)
  + String.fromCharCode(46)
  + String.fromCharCode(99)
  + String.fromCharCode(111)
  + String.fromCharCode(109);
</script>


Denne koden dekoder tallene til tegn, setter dem sammen til en tekststreng, tilordner tekststrengen til “document.location”. Javascriptet sender deg så videre til en ny nettside, rett og slett til http://google.com.

Ironisk nok klarte jeg å redirecte meg selv til google da jeg skulle ta en titt på preview’n på dette innlegget. Glemte visst å enkode HTML-taggene, tenke seg det…

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.