palbertini

(Ab)using an OpenX AdServer as noninvasive CMS

2011-08-09T08:29:00.002+02:00

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:

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.
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

Added openX XML-RPC API as possible Datasource in our Data-Access-Layer
Added roughly 10 plugins to meet our needs
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.

Using helpers to emulate multiple inheritance in PHP

2010-09-04T13:52:00.000+02:00

There's no multiple inheritance of classes in PHP. We all can be happy with respect to some problems, but there is others arising from that:

What we want to do is this: shared methods should be shared and not duplicated. So an action AbstractArticleAction and another one, AbstractBlogAction, both inherit from an AbstractPageAction and maybe add custom methods. And there is more special actions like ArticleDetailAction and BlogDetailAction which both do things like stripForbiddenHtmlFromText(). And here is our problem: Where should we put our shared stripForbiddenHtmlFromText method? The only class our DetailActions both inherit is the AbstractPageAction - but there's many other actions who do inherit from this one, and our method is only needed in the two special cases presented.

Now there are different approaches to a solution here:

Create a TextAction so that we gain an inheritance tree like this one:
BlogDetailAction extends AbstractBlogAction extends TextAction extends AbstractPageAction
This won't solve any problem, since tomorrow we will need a MonetarizeAction which should be used only by articles and not by blog posts.
Create Action Helpers and import/inject them into your actions when needed (plugins):
class AbstractArticleAction extends AbstractPageAction {
    function doExecute(ourRequest $request) {
       $this->loadHelpers(array(TextActionHelper,MonetarizeActionHelper));
    }
   function __call($method, $args) {
     return $this->{helpersMethods[$method]}($args);
   }
}
Then the helper methods are magically added as methods to AbstractArticleAction.
This solves our problem, but also creates new ones I'll describe later.
Make all action helper methods public static and call them statically from within your actions:
class AbstractArticleAction extends AbstractPageAction {
    function doExecute(ourRequest $request) {
       $this->article = TextActionHelper::stripForbiddenHtml(
                           $this->article,
                           $allowedHtml
                        );
    }
}
Erm. Let's go back to the procedural paradigm, okay? ... We don't want to do this.
Work with dependecy injection and inject all helpers as services:
class AbstractArticleAction extends AbstractPageAction {
    function doExecute(ourRequest $request) {
       $this->article = $this->_TextHelperService->stripForbiddenHtml(
                            $this->article,
                            $allowedHtml
                        );
    }
}
Not so nice, and leads to similar problems like 2. And: this is not quiet what a service is thought of be doing. And: you'd have public function injectStuff($stuffToInject) methods all over your actions.
Use Singletons. No.

We decided for the second solution and built view helpers and action helpers which are imported when needed. As already mentioned this does solve the problem and gives our BlogDetailAction all the methods it needs while leaving everything else untouched. Also code duplication is avoided. The AbstractPageAction has a method called load() which will import an action helper. AbstractBlogAction and AbstractNewsAction both do import the text helpers.

But there's also some problems with this solution:

Magic: neither from within the class, nor from it's parents you can directly see where a method comes from. So doesn't your IDE of choice. Forget about clickable method names, code completion and easy access to understanding. On the other hand: knowing about the action helper system might let you grasp from the method name, that It'll quiet likely be found in an action helper.
Naming conflicts: This one is classical about multiple inheritance. What happens if two or more of the view helper methods have the same name? This wouldn't be a problem within the two different helper classes, but would become one when an action imports both of them. Throwing an ActionHelperMethodNameConflictException does solve this during runtime. But one can easily imagine, that there are 12 action helper classes which are used for development for about one year (method names spread all over the project) and after the year we first stumble across a conflict because we before never had a case where two the conflicting helper classes were both imported by an action. Now we have to rename one of the methods...
Statics: To avoid loading helpers all over in every action that inherits from f.a. AbstractBlogAction one has to make helpers a static property. I am still unsure if this is a good idea.
Function arguments:Since arguments are passed to the helpers via func_get_args() in the __call() method, the helpers are really hard to handle, iff they have multiple arguments, which are predefined [f.e. cropText($text, $length = 250)] and get passed the action as third argument like this:

__call ($method, $args) {
return $this->{helpermethods[$method]}(array_merge($args,$this));
}
This is, because the helper method would, if we omit the second argument ($length), have to decide, if $length is the length or the action object.

Note, that the same problems and solution strategies apply for views and view helpers. Zend also choosed the 2nd strategy with respect to Zend view helpers.

PHP: date() versus DateTime

2010-09-01T20:53:00.000+02:00

Today I've stumbled upon an interesting bug in phps date() versus the DateTime object (since PHP 5.x). When writing unit test for an old view helper that creates parts of links from timestamps, I used DateTime::createFromFormat to create my expected values while using the view helper relied on date("d.m.Y") for it's return values.

When setting up the test, I choosed to use a data provider and just typed in long integers to represent my unix timestamps without thinking about a realistic length for them.

In the first step PHPunit confronted me with a typical result of the Y2K38 problem, since I had choosen a number (123557556123) which represents the 20th of May in the year 5885 :

1) onvLinkViewHelperTest::testCreatePortfolioChartDatesString with data set #5 (123557556123)
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-FROM=20.05.5885&TO=03.09.2010
+FROM=04.06.1938&TO=03.09.2010

I'll not describe this bug here, since it's fairly known around the blogs. I then decided to ignore the problem, because a colleague was just about to refactor the date view helpers who were responsible for the bug and doing a job twice thus having to merge both results doesn't sound too agile.

So I changed my data provider and randomliy choosed the number 12352343 as a date. Now I stumbled into another bug which in the first place made me think I've found a new bug in the DateTime object (or date() function).

1) onvLinkViewHelperTest::testCreatePortfolioChartDatesString with data set #4 (12352343)
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-FROM=23.05.1970&TO=03.09.2010
+FROM=24.05.1970&TO=03.09.2010

When inspecting the behaviour I found out, that there were 2 hours of difference in time, which - in some of the provided data - lead to that the next day was returned as FROM and TO.

This is because there is a second difference in date()s and DateTime()s behaviour: DateTime will ignore your date_default_timezone_set setting.

Working with both, date() and DateTime() really seems complicated in an unnecessary fashion. I'd stick to the latter, because of the Y2K38 bug and because I prefer objects.