The WordPress Integration Server

As I wrote in Dutch in my last post, one thing I’m thinking about is writing a WordPress integration server. And I’m thinking about the architecture of it. I’m just writing down some things:

  • It should consist of components that can run as a server themselves to scale even more when needed.
  • It should log http requests in a http request database not only for logging but also to grab meta information from to provide as services
  • It should have a request queue possible as transient, but I’m not quite sure yet how that works out with requests from the weblog that immediately needs stuff (can cause lagging), I think the service should be so smart to either say “yes I have it” or “no I will get it for you so please check in later” where a transient on the requester will pick it up later. But is a high dependency on the requester. We can also let the integration server “answer” later by then issuing either an xmlrpc request/code or db access to the requester.
  • Let’s say that it will support 100 popular social sites to start with: so weblog registers a new twitter user. Which triggers some crons to perform for that twitter user. Depending on the choice the integration server can then e.g. post new posts with twitter content from that user to the weblog.
  • Maybe a component will provide some basic mashup services.
  • I’m not sure about the history component. If it will keep all history there would not be a need to store some data in the weblog but the weblog can just take a view from the history component in the integration server. No use to have duplicate data all over the place.
  • Singe-sign on. Possibly it would be the node to talk to for single sign on requests to other applications. Would be pretty handy.

As an anti-requirement: it will run on a WordPress platform, not because it is needed, but because it is pretty cool to do so.

So why do I need it now?

Because I wrote the wp-favicons plugin which is now at version 0.5.5. While adding new versions I now have a plugin which pretty well works: it grabs favicons from websites and stores them locally with your weblog. It also has a request cache that grows enormous and caches ALL requests. It also has knowledge about every outgoing link on your weblog as well as its HTTP status (check the source code).

But… as always… I have some problems that I can not solve by just letting the code evolve further on this path. I realize that when even 1 request goes out for a favicon the website ” goes lagging ” until the favicon is retrieved. I realize that I could jquery a non blocked curl call but well.. think about it somewhat further yourself and you will realize that that path is not the correct path (it will still go doing http requests from that same server with that same cpu and that same memory so… you will see the same peeks in your stats…) (and to even answer “no I do not have that icon yet” it still takes processing time to verify the databases for existence of that icon and to then either answer or add that requests on a gigantic queue) (where after we have to check both the queue and the database). Uhm… so… a standalone server that could run on its own cloud instance with its own cpu and memory could a) re-use some code for other integration purposes b) does not bother the weblog itself c) holds then favicons which can be re-used over multiple weblogs and even non-weblogs while still holding that data on one of your own servers.

request cache database

One special component is the request cache database. It simply logs every http request. Superb for exactly knowing what happened and for further optimizing code without doing calls numerous times to the same websites. Currently, for favicons, that information lives forever. Meaning: if a website returns a 404 it will hold that 404 sign forever or until the request database is deleted.
The advantage is that you get a clear view of all outgoing links that are longer correct. Pretty handy and easy at this stage of beta. (it also support http code 418 grin)


But… obviously we will need to add some kind of transient key to this in the future. E.g. a request to the Twitter API / etc… makes the url unique but the http header and body that is returned are many times only valid for a short period. So maybe that should be a parameter for each kind of request. Where the record itself states how long the information is valid to prevent looking through all kind of code looking for the correct time-out values.

The size of that database is also a problem. In my first experiment I managed to get that data dumped to my localhost but importing it in my local MySQL database failed because of the size. Really. It can get that big that quickly. Maybe I should at forehand make some kind of taxonomy of the data and distribute that information over multiple databases. I wonder how many servers Google needs to index all URL’s of the world including their content but I noticed it grows big very fast. This weblog contains only about 31.000 valid outgoing links (and lots of misformed urls where I made mistakes) and that already made it a big pile of data (also notice that 301 leads to new requests and a request for an icon is another new request) (so yes it also contains approx. 15.000 favicons in binary format).

So to make this thing work for even larger sites I really need to move in this direction first and then re-implement the favicon plugin and other like-wise plugin to run on the WordPress integration server.


Plain simple calls that return ‘200 ok’ are simple. The world out there exists out of a hell of a lot status codes returned. And depending on the type of functionality for the specific service/plugin a status code could mean one kind of action or another kind of action. E.g. For a favicon request a ‘404’ is not the end. Since somewhere in that page a icon tag could be present that holds the reference to our needed favicon. Also difficult are redirects implemented in javascript. To build this tool correctly we will need some javascript parser that can tell us if we need to request another page or not. Suppose on of the webservices returns us a html body that contains javascript with code that, depending on the time of the day sends us to some specific page. We really need to be able to parse that javascript and then act upon it. So within our integration server we will need a component that is able to parse (the latest version) of javascript (and will probably need some amount of memory todo so).


Coming to you somewhere the coming years or … if you have some pretty good WordPress, PHP etc… knowledge… maybe we can join forces to GPL this to the world.

Omkat tijd Zomer 2011

Je zag het al: de website ziet er niet uit :) (maar geen zorgen je kunt overal bij). Het komt omdat ik ergens halverwege ben blijven steken met wat probeerseltjes en de meeste nog niet eens “aangezet” heb.  Ik moet er nog veel aan doen maar ik kom er niet aan toe. Ik was aan het spelen met de nieuwe custom post formats maar ik moet nog styles voor alle typen maken en bovendien de bestaande 10.000 postings opnieuw doorgaan om te kijken of het enigzins matcht.

Ik ben nog aan het na denken over wat zaken. Ik zit erover te denken om weer eens  een eigen thema in elkaar te gaan steken. Om eindelijk eens de complete lijst  van requirements van WordPress te gaan koppelen met de daadwerkelijke implementatie van hoe de site uit ziet.

Grofweg zit ik er aan te denken om al mijn requirements als custom post types in elkaar te gaan steken “requirement”. Als je niet weet wat requirements zijn: zie wikipedia.

Dat zou betekenen dat ik op meta niveau in mijn eigen weblog al mijn requirements (waarschijnlijk honderden of zelfs duizenden) opgeslagen heb. Normaliter zijn die die dan vrij tekst achtig zoals use cases, user stories maar ook non functional requirements. Maar deze keer wil ik ze zo implementeren dat ze een soort directe link hebben met settings in een admin screen. Het wordt dus een soort WordPress theme-language. Met die WordPress theme language kun je dan een thema “opschrijven”.

Voor mensen die WordPress gebruiken voor hun “living” (Ik was op de WordPress meetup Amersfoort (zie ,, en het was leuk om allerlei mensen te zien die met WordPress bezig waren) kan het dan betekenen dat een soort core van functionaliteit bestaat uit checklijsten die je met een klant kunt doornemen en die direct implementeerbaar zijn. Voor mensen die theme’s schrijven is er and een zeer smarte checklist waarover geen discussie kan bestaan. Het kan een soort accelerator zijn.

Bij een eerdere plugin heb ik al een laagje bovenop de settings.api  geschreven waarbij op alle functionaliteit in-gehooked kan worden. D.w.z. als je bijvoorbeeld een “gebruiker kan eigen favicon kiezen” functionaliteit hebt dan is dit 1 class: favicon. In die class zit dan zowel de admin functionaliteit als de front-end functionaliteit. bovendien zit in die class ook het help scherm in de admin als ook de validatie regels voor de form in de backend enz… Ik heb die code dus en er kunnen nog wel wat laagjes omheen. Ik geloof sterk in het toevoegen van lagen. Ik heb gemerkt dan het toevoegen van lagen heel creatief werkt. Plotseling ontstaan er weer allerlei nieuwe ideeen nadat je een laag hebt toegevoegd. Het wordt wel ingewikkelder natuurlijk. Een van die ideeen komt nu hieruit voor: als alles een plugin is. Dan kan er een taxonomie van plugins gemaakt worden die gekoppeld is aan een functionele of non functionele beschrijving van die plugin. Die beschrijving kan heel smart gemaakt worden omdat de plugin al bestaat. De complete uitdraai van die functionele smart beschrijvingen van de gehele set aan plugins leest als een boek met ja/nee checkboxen. Die zijn gekoppeld aan custom post types om te publiceren op meta niveau van wat de requirements zijn als een soort levend boek, mogelijk met code. Het wordt dus een thema met een meta thema maar dan met duidelijke taxonomie.

Ik heb geen idee hoe ver ik hier mee kom. Het wordt erg ingewikkeld omdat requirements weer genest zijn. etc.

Een ander iets is integratie. Mijn delicious perl script is gestopt omdat delicious in een build up fase is na de overname. Deed me denken om eindelijk eens een aparte server op te zetten die louter gaat dienen als integratie punt naar deze  weblog. D.w.z. deze server haalt allerlei content binnen en pompt die via of XMLRPC of via php calls of direct op de database binnen op dit weblog en mogelijk andere. Het voordeel daarvan is, is dat er geen load is op de site t.b.v. integratie en dat ik vanaf die server ook naar meerdere punten data kan verspreiden. Ik moet daar dan wat code voor schrijven. Theoretisch hoeft dat geen gui te hebben maar… als ik er ooit een mooi WordPress verhaal over wil maken zou het mooi zijn als ik dat ook een WordPress install maak. Dat maakt het eindresultaat meer buzzable.
Voor die server moet ik dus plugins schrijven die kunnen integreren met een ERG VEEL websites. Ik zat daar ook aan te denken omdat mijn favicon plugin toch een erg zware load op de CPU veroorzaakt alsmede een gigantische request database. Zou mooi zijn om die extern van een blog te laten runnen en dan mogelijk te kunnen splitten qua load. D.w.z. enkele plugins op 1 integratie server en weer andere integratie plugins op een andere integratie server. Zeker in het cloud tijdperk kun je dan snel groeien en snel een nieuwe integratie server omhoog gooien met een gedeelde memcache server.

Ook qua hosting zit ik een beetje aan mijn limiet. Ik ben nog aan het nadenken wat mijn volgende stap is voor ik ben er nog niet helemaal uit.

Daarnaast is het prive blogging concept nog wel interessant. Iemand start met louter ‘tags’ omdat hij geen idee heeft waarover hij gaat bloggen. Na een postje of 5000 zijn er trends in die tags die kunnen leiden tot verdere categorizatie of sub blogs e.d. Ik heb hier ook nog wat ideeen over. Daarnaast het enterprise blogging, ook hier is nog een hele markt open voor vertical solutions bovenop WordPress.

Gelukkig heb ik de luxe om er lekker lang over na te denken en dan pas te starten met coderen :)

Ꭺ Ꮤeblog Ꮤith ᏔordPress | Alles over het maken van een Ꮤeblog met ᏔordPress!

[screenshot url=””] Ꭺ Ꮤeblog Ꮤith ᏔordPress | Alles over het maken van een Ꮤeblog met ᏔordPress!

Voor beginnende webmasters: alles over het maken van een weblog met WordPress.

Er komen nogal eens mensen naar me toe met minder web kennis (of geen) met de vraag hoe ze een eigen weblog kunnen starten zonder de beperkingen van een SAAS blog provider.

Dus ik ben dit maar eens gestart. Ik zal er op een heel laag pitje wat artikelen publiceren met als voornaamste doel er naar te kunnen verwijzen en dan ook echt gericht op primaire kennis.

Tegelijkertijd gebruik ik het ook maar eens als testomgeving voor mijn Swift theme vertaling.

productivity tip: Have an “open threads” folder in your browser

We all know it: you have made some questions or remarks on forums, blogs, newsgroups and who knows where and after a while you just lost track where you did what.

My solution is pretty simple:

Just create a folder “open threads” in your bookmarks bar and drag the URL’s in there where you have been chatting or awaiting more answers. Whenever you have time you can go through them and update a thread or simply remove the URI when the thread is done.

Simple but effective.

De Plenty EasyPull Poll

Ik heb de afgelopen tijd de EasyPull gebuzzed.


Ik kreeg een verzoekje om te kijken wat buzzees van de Plenty EasyPull vinden. Dus… ik moet even wat mensen nalopen Smile Voor U, gebuzzde website bezoekers:

De poll duurt 5 minuten en kan hier ingevuld worden:

gebruik dan code 1169 om aan te geven dat je een van mijn buzzees bent.