You can build and install that single module from the source while keeping the rest of the PHP installation intact, but the documentation of building shared PHP modules is poor.

In my case I needed the tidy extension, and here’s how to do it

 $ # extract the PHP source code and enter the directory
 $ ./configure --with-tidy=shared
 $ find . -name tidy.so

Then copy the tidy.so file to the modules directory of the PHP installation.

The important part here is the shared keyword, which is poorly documented. I had to inspect a RPM spec file to figure it out.

Med andre ord så blir tomme strenger (“”) behandlet som NULL. Dermed rapporterer MySQL med en feilmelding dersom du forsøker å sette en tom streng i et “NOT NULL”-felt. Hurra!

Heldigvis går det an å skru av kompatibilitetslagene i MDB2.

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…

I have worked with Catalyst the last two months, and I have become very comfortable with its MVC implementation. Almost everything is based on components, and Catalyst presents convenient methods for accessing controllers, models and views. Plugins can extend the core functionality of Catalyst by providing methods for easy access, for example to localize strings or assemble HTML widgets and forms. Methods imported from plugins are directly accessible from the context object to all components in your system. You can also create your own plugins, for example to access a cache solution.

Symfony is based on many of the same principles as Catalyst, to separate views, controllers and models from each other. Plugins can be used to extend the functionality, but not only for the core. If you want to integrate with a database using an ORM-solution (object relational mapping), as many do when using a web framework, you have to include a plugin for that. You don’t have to, but there are already plugins for this functionality, and you don’t want to reinvent the wheel, do you?

The most obvious difference between Catalyst and Symfony are that they are written in different languages, Perl and PHP respectively. URL mapping in Catalyst is handled in each controller by defining the dispatch type in the method signature. The default is to map URLs to controller names, and because of the namespace support in Perl known as packages, this makes it easier to create hierarchical structures in Catalyst. This means that you can create controllers with deeply nested actions in a clean and logical way. An example of this can be taken from the Bifrost project where the URL “http://example.com/admin/cards/lastswipe/create” is mapped to the package “Controller::Admin::Cards::Lastswipe::Create”.

PHP has no knowledge of namespace, and Symfony does therefore only support two levels in the controller view; modules with one or more actions. It does however map URLs to actions using a configuration file, so it is possible to get multilevel URLs in Symfony too. Because of the mapping configuration it is not always given that the example URL above maps to a class named “AdminCardsLastswipe”, it could just as well be mapped to something like “fooBar”. This gives flexibility to the applications, because URLs can stay the same even if the files are move. This is also achievable in Catalyst as well, but would be an exception of the normal rules, and can be spotted when starting up the application server in debug mode. As long as only you are working on the project this is not a big problem, but it might be harder for others to understand it. You might even get problems yourself if the application grows very large.

When it comes to the model layer, a common practice with Catalyst is to implement a small model class, used to invoke a model class or sub system with configuration parameters, user session attributes or request attributes. To retrieve a model you call $c->model(“MyModel”). This is also true for the view layer where you access the view sub system by calling something like $c->view(“TT”). Normally you won’t have to explicitly call on the view, because it will automatically use the one available, or the one configured as the default view if you use multiple views.

In Symfony, the view and model layers are included as plugins to extend the core. This locks you in to use only one view and one model implementation for each application. You can of course implement new methods to return what ever you want, but then you go outside the scope of Symfony. In fact, an ORM called Propel is already integrated in Symfony, and you need to use a plugin to override this behaviour. From what I can see from configuration files, you can only use model in your application. You can probably configure each module to use different models, but you are still stuck if you want to search in two databases from a single action. This brings me over to the next part; flow control.

Actions in Catalyst are methods in controller modules. You can forward to other actions, and the original flow of execution is resumed when the actions end. This gives you flexibility to gather data from multiple actions without being cut off. If you detach to other actions, the chain will break off and won’t resume to the original action. If an action you forward or detach to throws an exception, the exception is thrown back through the action stack, which. This makes it easier to catch and handle exceptions because the exception will always end up in the first action method.

In Symfony, actions are methods in modules. When forwarding you get the same effect as detach in Catalyst. You can use filters in Symfony to achieve some of the same effect as forwarding in Catalyst. The difference is that you have not reached your action yet when running through your pre-filters, which means you can not handle exceptions in your action class. Filters are often used for caching, authentication and authorization.

Perl has a template framework called Template Toolkit which separates application logic from presentation. What I like about Template Toolkit is that there is no need for any Perl syntax inside the template files, which I believe is important when graphical designers are working on the templates. There are also other template systems for Perl, for example HTML Template.

Symfony uses a template system which depends on PHP to print variables, handle flow control and to call view helpers, but using PHP in the template files can result in unpleasant results if used to handle too much of the flow control. A thumb rule might be to never let PHP code exceed more than one line at a time in the template files. It is possible to use Smarty, a template system with many of the same features as Template Toolkit. It is also possible to use XML and XSLT in the view layer, but traversing XML files can be a tough experience for most people.

Now, lets focus back on MVC frameworks and Ruby on Rails. Of the two web frameworks I have discussed above, Symfony is the one that looks most like Ruby on Rails, but that doesn’t mean it’s perfect. Catalyst has a stronger separation between the layers, which provides more flexibility, and I like that. When working on Bifrost we had to integrate with multiple sources of information, such as LDAP for data storage, ARP for looking up MAC addresses and CUPS for listing printers and printing documents from web forms. This was all done in models. If this had been done in Symfony, we had to implement those features directly into the controller layer or create a lot of plugins.

The world of web frameworks is large, and it is definitely worth learning to use some of them. It didn’t take long before I was able to understand Catalyst and use it effectively. It has taken a little longer with Symfony, probably because I find PHP harder to use, because of inconsistent function and configuration names and the lack of namespaces. Symfony focuses a lot on caching to optimize for speed, and this is of course needed because the entire framework gets loaded on each page request. I find Catalyst more elegant than Symfony, not only because of the programming language, but also because Catalyst focuses more on good software design and that it pre-loads the framework and components once, and then forks to multiple daemon processes to share memory and save resources.

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…