views:

58

answers:

2

for a large project ive worked on (~310k uniq/day, large site, lots of templates, lots of content), we have to deal with the client selling several sections of the site (each with different layouts) for ad revenue. sometimes, its the top of the page for a 900x250, sometimes its a 952x200 under the nav, sometimes it requires a new div with custom styles. the ads are served through google's ad manager, and the ad buyers rarely (if ever) agree to customizing their implementation code for our site.

all of the code for this site is in a svn repo than we try to keep very tidy:

  1. edit the templates "online" (on the production server) (such a bad idea)
  2. make changes to local copy, push live (and risk later reverting back to old ad code and missing it/having to deal with it before going live. people miss things, dont pretend like you don't and say 'check harder'.)

neither of those options are particularly attractive. how do you guys do it?

A: 

I think the best bet is to figure out how to divide the code up into smaller pieces to separate the changing code from the static code into different files.

Dolphin
at a certain point, having potentially several include files for a single page's individual ad slots (and some of those only being required for, say, a week or a few days) seems like more of a headache than its worth. entire section takeovers could require 6 or 7 ad slots in up to 3-4 unique templates per section. thats a lot of fuss and muss, and would still require constant changes to vc'd code to manage whats in and out, or litter the code with many unnecessary file includes.
Carson
+1  A: 

Maybe you could consider taking the ad code out of your templates/source code and putting it into your database. I think of ads as more "content" for the site which can be managed by your code in the same way as other web site content. You can still set up the ads on a staging site, then copy/paste the relevant bits to your live site with this approach.

Jim OHalloran
a combination of database storage and long-term caching to prevent several trips to the database on load would definitely be workable. in my case, this is done w/ a custom django template tag.
Carson