Når man utvikler en plugin for WordPress som stadig utvides med ny funksjonalitet kan den vokse så stor at det kan bli et uhåndterbart antall filer i pluginkatalogen eller at filene rett og slett blir så store at det er vanskelig å få oversikt over funksjonaliteten i filene. Dette går også ut over ytelsen til WordPress. Et eksempel er plugin-siden i administrasjonsgrensesnittet som søker i alle PHP-filer i alle underkataloger ett nivå under plugins-katalogen etter filer med en plugin-header.
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.