Plugin skeleton code

This afternoon, I sketched out and committed a skeleton for what this plugin can look like. There’s a few different parts I’d like to talk about at this point.

First, all “ad codes” (e.g. the script URLs to load on the front end) are registered with Ad_Code_Manager::register_ad_code(). Here’s sample usage:


$script = ';s1=%ad_zone%;s2=;pid=[unique_page_id];fold=atf;kw=;test=;ltv=ad;pos=top;dcopt=ist;tile=1;sz=300x250;ord=%page_random%?';
$where = array(
	'is_search' => true,
	'query_include' => 'apple',
$url_vars = array(
	'site_name' => 'ltv.witi.home',
	'ad_zone' => 'homepage',
Ad_Code_Manager:: register_ad_code( 'banner', $script, $where, 10, $url_vars );

These will either be registered with ad tags in your theme’s functions.php file, or in the admin interface to be put together by @rinatkhaziev. The URLs will need to be cleared against a whitelist.

On the front end, you’ll add code like the following:


do_action('acm_tag', 'banner' ); // or we might add a template tag to do essentially the same thing

The Ad_Code_Manager::action_acm_tag() method will handle all of the priority logic to determine which ad code should run in the tag if there are multiple that could fit.

Lastly, I included mention of the admin interface for managing ad codes. Basically, what we want is a spreadsheet-like interface for adding new ad codes. ‘tag’, ‘code’, ‘priority’ will be reserved columns, and all other columns will serve is expected token replacements for the URLs. If the admin interface is included, then all data in the interface will be registered as ad codes using Ad_Code_Manager::register_ad_code(). The data should probably be stored as a custom post type (so we have revision history too)

I’ll work on the registration and presentation logic over the next few days.