(Ab)using an OpenX AdServer as noninvasive CMS

At work we've recently been working on and finally deploying an interesting use of an openX ad-server: we use it as a CMS system. There were two basic reasons for us to do this:

1. Requirements : Our PM required us to have a CMS system, where the content boxes could be served in a way you'd usually serve ads. Some have frequency cappings, others show up at certain times a day, some have randomly changeing contents.
2. Other CMS systems often bring a bunch of software we dont need. Many bring a complete framework (which usually consists of crap-code), require you to work with their administration to make changes to a site, prevent or countervail effective cacheing and are a boring solution anyways.

OpenX ships with an API, meets all requirements, may besides be used in they way its originally meant to work - as adserver - and can be modified building your own plugins.

what we did

1. Added openX XML-RPC API as possible Datasource in our Data-Access-Layer
2. Added roughly 10 plugins to meet our needs
3. Added Database sync and plugin installation to our build

Thanks to the plugins we didnt need to touch the also really crappy code openX is written in. Trust me, better dont risk a glimpse.
This enabled us to apply cacheing mechanisms on different levels : DataAccess may store read contents in memcache, whole site cacheing is done with varnish. OpenX plugins sometimes read from our software via simple CURL requests, these also pass varnish and memcached.

stumbled upon some problems

In openX you dispatch so called zones. These are basically spaces which may contain banners (or boxes in our case). API calls read from openX via commands similar to "zone:1", where 1 is a openX given zone id. We didnt want our beautiful software to gain knowledge of all the IDs created by an anonymous server that should remain exchangeable. Also you'd need like 40 zones for a single webpage, since you'd always want PM to freely and easily change contents.

• We solved this issue by creating a what we call ContainerBox-Plugin. This plugin does internal openX API calls and dispatches arbitrary many sub-zones. Our software only knows two container IDs per webpage, which leads to a straigforward number of zone (container) IDs, that are managed as constants in a single interface. By creating a small converter we use textual identifiers for zones all over the software, that wont need to be changed when exchanging the CMS/adserver and encapsulate all openX specific information in that single interface.

openX tries to emulate APC by "shrinking" all code needed in production for API calls. One of the silliest pratices I've ever seen and really a pain in the a**. You cannot simply require_once files in your plugins, f.e. to do the internal API calls to openX from openX, since the files included for administration and production are different ones (normal source vs. shrinked crap for the latter).

• Since plugins weren't easy to test anyway (since they consist of a component file that is roughly OOP and a delivery function that by default is not) we build some kind of own openX internal API, that checks for function_defined's and requires files based on that. Also its injected into our plugin classes, so that we could make them testable without doing actual calls to the databases.

Another thing that not to cool is openX support. The documentationis not good at all, and the source code doesn't read understandable. Also known bugs and issues aren't solved within reasonable times.