Op http://wps.i-v-o.nl/ staat sinds vandaag een vernieuwde demo-website van WPS.  Met deze demo-website kan je lezen over wat WPS is, wat het kan, hoe het werkt en je kan spelen met het systeem.

Wat is WPS

WPS staat voor Web Publishing System. Geen spannende afkorting, maar het dekt de lading wel goed. WPS is namelijk geen klassiek Content Management Systeem (CMS) maar veel meer. Een klassiek CMS zorgt er eigenlijk alleen maar voor dat je de inhoud van je website kunt bewerken, dat doe je dan eigenlijk altijd op een aparte website (ook wel backend genoemd). Zo’n CMS is harstikke mooi, maar er moet ook een ‘voorkant’, je website, geprogrammeerd worden, en dat kan best een tijdrovende klus worden. WPS is een publicatiesysteem en zorgt dus niet alleen voor de CMS functie, maar ook voor het publiceren; de voorkant van je website.

Publicatie-systeem

Er zijn gerust wel andere publicatie-systemen, bijvoorbeeld Joomla of Wordpress, maar toch heeft I-V-O de keuze gemaakt om een heel nieuw systeem te ontwikkelen. Waarom? Flexibiliteit.
De meeste andere systemen zijn nogal rigide in functionaliteit of opmaak, en dan nog maar niet te spreken over veiligheid. WPS is extreem flexibel door het gebruik van XML. Alle gegevens die in WPS rondgaan worden omgezet in XML en komen in 1 groot document samen; het WPSDoc. XML is een speciale manier van gegevens opmaak die zich uitermate goed leent tot ‘translaties’. Stel je voor dat je een tekst hebt ingevoerd en je wilt daar een deel van dikgedrukt maken; normaliter wordt dat in html aangegeven met de b-tag. In WPS wordt dit de bold-tag, niet “b”, en bij het publiceren van de pagina kan de programmeur dit transleren/vertalen naar de standaard “b”-tag, maar ook naar iets heel anders, bijvoorbeeld “strong” of “h1″.
De taal die gebruikt wordt voor dit vertalen heet XSL-t, een soort HTML, maar dan met logica; je kan als programmeur o.a if-then-else, loops, en variabelen gebruiken. Hierdoor wordt de XML een stuk slimmer, en je site dus ook!

Bewerken en beheren

Wat WPS nog meer bijzonder maakt is de manier waarop je de teksten in je website kunt beheren; dit doe je namelijk gewoon in je site en niet op een aparte website of backend. Hierdoor zie je veel beter wat en waar je wat doet. Dit is veel gebruiksvriendelijker dan de standaard CMS’en en geeft veel beter weer wat de cohesie is tussen website en content.

Plugins

Een standaard WPS-site kan al heel veel;

• Pagina’s aanmaken, teksten maken en aanpassen
• Meta-tags (voor zoekmachines) beheren
• Linkjes in je teksten controleren of ze nog goed zijn
• Bestanden (pdf’s, Word-documenten, plaatjes) uploaden
• Een site in meerdere talen publiceren (en dat doet WPS heel slim want als je een pagina in het nederlands naar bijvoorbeeld het engels hebt vertaald dan weet WPS welke pagina’s bij elkaar horen, als een engels-sprekende op een nederlandse pagina komt kan hij/zij met 1 klik naar de engelse versie zonder de pagina opnieuw te moeten zoeken)
• Rechten instellen per pagina

Verder zijn er heel veel extra functies gemaakt in de vorm van ‘plugins’, een greep uit de collectie;

• Nieuws-plugin: zorgt voor het beheer en publicatie van nieuws-berichten (ook naar RSS!)
• Poll-plugin: maak zelf een poll en zorg dat je bezoekers kunnen stemmen
• Search-plugin : zorgt ervoor dat bezoekers kunnen zoeken in je website
• Shop-plugin: volledige webwinkel, met betalingsmodule voor IDEAL en Mollie (micropayments)
• Enquete-plugin: zeer uitgebreide plugin voor het maken van grote enquetes, compleet met uitnodigings-email-functie, toegangscodes en export-functies.
• Catalogus/Portofolio-plugin: laat je bezoekers zien wat je verkoopt of wat je hebt gemaakt.
• Download-beveiliging voor Audio: als je bijvoorbeeld muziek wilt laten horen vanaf je website via een zg. FlashPlayer dan zorgt WPS ervoor dat bezoekers niet stiekem de bestanden kunnen downloaden.
• Google-Maps-plugin: zorgt ervoor dat je bezoekers op een kaartje kunnen zien waar je bedrijf is gevestigd
• Reactie-plugin: geeft je bezoekers de mogelijkheid om korte reacties op je website te plaatsen (en ze kunnen ook op elkaar reageren)
• PDF-output; maakt automatisch PDF-bestanden van de tekst op een pagina die bezoekers kunnen downloaden
• Blog-Plugin: samenvoeging van de nieuws-plugin en de reactie-plugin
• Gallery-plugin: maakt automatisch een mooie foto-gallery van foto’s
• En in ontwikkeling; Google WAVE-integratie; een mogelijkheid om bezoekers via Google Wave te laten reageren op nieuws-berichten.

Verder maakt WPS gebruik van slimme caching; je site zal altijd rete-snel blijven omdat alle veel gebruikte informatie in het geheugen van de webserver bewaard blijven, zodat ze snel weer voor handen zijn als het nodig is.

Voor meer informatie over WPS, klikkerdeklik!

The first hurdle most developers have to take when introduced to AJAX is S.O.P.
S.O.P stands for Same Origin Policy and basically means that you can only do AJAX-requests to the (sub)-domain the client is currently on. First thing I thought when I read about AJAX couple of years ago; ‘wow! cool! I can strip content from other sites and incorporate them in my websites’ .. and immediately I started hammering away on a RSS-reader which was supposed to grab news from a RSS-feed directly. My efforts failed. The RSS-feed was on another domain and S.O.P kicked in spoiling all the fun.

There are ways to get around this, you could create a server-side script which retrieves content from another domain and proxy it to your AJAX-request. However; you will need a server that has either PHP, ASP(.net), CGI, Rails, or at least something more intelligent than a plain HTML-only environment. This is OK for most people, and proxying content from other domains to AJAX-request is used a lot. But what if you’d like to create something, like a widget, which needs to grab content from any domain, and which people can use without having a PHP/ASP/CGI or Ruby-server? You wouldn’t be able to get around S.O.P, right?
How can you bypass S.O.P, while still maintain a certain level of security?

TimeLiner
I ran into this problem when I created TimeLiner. TimeLiner retrieves and displays messages linked to a flashmovie or mp3-file. These messages are stored on one of my servers and TimeLiner could be running anywhere. Retrieving those messages should be done by AJAX-like requests but I didn’t want users to install all kinds of server-side scripts on their server for proxying the messages from my server to overcome SOP. I wanted TimeLiner to be able to run from HTML-only-websites, or as a widget from social networking websites. But with SOP this wouldn’t be possible.
With this in mind I started experimenting. I started off by creating script-tags and insert those tags into the DOM on the fly and see if variables in the referenced js file were actually available. Expecting limitations due to security measures within browsers the results actually suprised me; the variables were globally available! I started on designing a proof of concept and tried to take this idea to the next level. At the end of the day I got a working prototype and called it AJP; the Authenticated JSON Proxy.

RPC, AJAX, Objects
First a bit of history. The past few years I’ve been busy writing WPS; a publishing system much like Joomla (only much better;). It’s written in PHP5, object orientated, follows a observer-pattern(plugins) and runs entirely on XML/XSL-translations. If you’d like a shop-plugin on your WPS-driven-website you only need to include the shop-object and you’re ready to sell your stuff.

Because all data within WPS is actually XML it really doesn’t matter what you want to do with with it; you could translate it to HTML by using XSL-t and write it to the browser or you can pickup this data by using AJAX-calls. KISS at work

WPS uses its own RPC-interface for AJAX-requests. You can create a request by defining which WPS-object you’d like to call, which method within the choosen object must be executed and the arguments that need to be passed to the method. This WPSRPC-interface consists of two parts; the server-side pickup and dispatch, and a javascript-class that simplifies the actual RPC-calls.
A typical WPSRPC-request would look like this:

Javascript:

var wpsRPC = new wps.rpc;
wpsRPC.createCall('shop', this.setSaved.bind(this));
wpsRPC.call('storeItemToBasket', {id:itemID, uid:someUID});

Line 1: create a RPC-object
Line 2: define the PHP-object you’d like to call (in this example; the shop-object) and define the callback-method (in this example; the method setSaved from the same object-instance, hence the .bind(this)-statement )
Line 3 : define the method which needs to executed remotely, define the arguments that need to be passed and execute the request.

On the server-side (PHP) the request is handled by the WPS-controller. WPS uses _autoload to include the requested class, instantiates the requested object (in this case the Shop-object) executes the requested method (storeItemToBasket) and passes the arguments to that method (id & uid). The output of the requested method should be XML or JSON which will be returned to the javascript-callback (setSaved) for further handling by the browser.
This proofed to be a powerful method of remotely executing stuff; it’s clean, quick and flexible and I’ve used this structure for 5 years without any problems whatsoever.

Now; why this elaboration about WPS?
AJP uses exactly the same structure, a Javascript object that contains methods for doing RPC-calls, and a server-side RPC-interface to handle those requests, but there is a slight difference; the calls can be done across domains!

Back to AJP: how does it work?
I’ll use the example of the WPS-shop-object and explain each step; let’s assume a user is visiting your webshop and clicks “add to basket”, what will happen?

By clicking an event is triggered, this event will create an AJP-object:

var ajpObject = new ajp;
ajpObject.createCall('shop', this.setSaved.bind(this));
ajpObject.call('storeItemToBasket', {id:itemID, uid:someUID});

Internally the AJP-object creates a random ID and prepends “jsonProxy”, let’s say this variable is called jsonProxy12345. This variable is used to identify the request. Next step is to create a script-tag and insert it into the head of your HTML-document. The src-attribute of the script-tag points to the URI where a RPC-interface is waiting for requests. This is not a .js file, but a .php-file; which allows you to use http-requests ($_REQUEST in PHP) to pass along variables.
A script-tag from this example would look like this;

<script src="http://www.yourdomain.com/
rpc.php?jsonProxy=12345&object=shop&method=storeItemToBasket&id=1&uid=12" >
</script>

The server-side pretty much works the same as the WPS-example above; the $_REQUEST is mapped to an object, a method and the arguments and is executed. There’s a small difference; the output can only be JSON, and put into a variable called jsonProxy12345.

Ok, let’s assume the RPC-call executed OK and the ID of the inserted row should be returned to javascript. How does AJP know there’s output, and how does AJP actually use the output?
In ‘real’ AJAX you can use an event to notify Javascript the RPC-call returned something, but AJP is not ‘real’ AJAX… This is where the jsonProxy12345 comes in: the moment the script-tag is inserted into the DOM a timer is started which keeps checking for the variable jsonProxy12345. If the variable exists the value is picked up and passed to the callback-function, otherwise the timer keeps running until it encounters the variable (there’s a timeout to catch errors). This effectively mimics the events used in real AJAX, which we want.

Now for some security
If you use this kind of RPC you really do not want to expose your PHP-objects to the world. If you created a populair service your server would run out of resources if anyone can do RPC-calls to it. To overcome this you need to authenticate the requests, but how?
It’s really quite simple; before actually doing a request, ask the server if you may do a request!
I’ve done this before with traditional forms; before posting a form an AJAX-call retrieves a unique ID from the server (a mysql GUID), this GUID is appended to the form in a hidden field and the form is posted. The server checks if the GUID is valid, and if that’s the case the form is handled.
But how does the server know the GUID is valid? The moment the server creates the GUID it’s stored into a database, along with the originating IP-address, the browser-string and the time it’s requested. If the form is actually posted the server checks if the GUID is available, if it’s from the same IP, with the same browserstring and within 5 seconds after it’s been requested. Only if all conditions are met the form is handled and the GUID is removed from the database.

This principle can also be used to authenticate AJP-requests, and AJP can use itself to request a GUID by being clever in it’s design and inheritance-scheme.
I realize it’s quite easy to mimic the requesting of GUID’s, but it’s a barrier, and AJP does something else to tighten up security even more; whenever AJP receives a result the script-tag will be removed immediately. It removes any evidence of requests, making it harder to find out what happened.

AJP is certainly not rocket-science, I’ve seen a lot of scripts using this kind of technique. I do believe the structure of AJP itself works great and allows developers to extend upon. As a bonus; this also works great on very old browsers; i’ve tested it on MSIE 4, and AJP works fine!

I’ve compiled a small (LGPL’ed) download which contains all the files for using AJP, it’s not a full implementation, but enough to get you going.

Other features/wannahave’s:

• More/Better Help-functions, possibly integrated into WPS itself.
• Multi-language-support, not only for editMode, but also for the publishing modules themselves
• Sandbox-support out of the box, no need for a specific subdomain or VirtualHost
• New site-manager; an overview of pages/contentblocks from a grid/treeview.
• Link-checker/mover; Checks internal links to WPS-pages or renames them when a page is renamed
• More wizards for general functions (add page/block etc).
• Template-editting : access and edit XSL-stylesheets that make up the layout/design of your WPS-site
• Empty-cache-button
• Filemanager needs to be rewritten to be MUCH faster and uses less resources
• Custom-XML-tags-support in content-editors, more editing-facilities in content-editors
• Install/Configuration/Security-audit – scripts
• Version-control