On a dotcom site that uses Ad Code Manager, we’re seeing Google try to crawl ?preview= URLs (I have CSV reports from the site owner of the URLs that Google is failing to access). Not super sure how Google is finding those, but @danielbachhuber suggested it might be something like when an author is previewing a post, this triggers AdSense, AdSense reports back to Google the URL the code was triggered on, and Google tries to call it, and it errors.

If this sounds plausible, I’d like to suggest that adsense is disabled (i.e. not output) when is_preview() === true. ?

googletag.pubads().set(“page_url”, “URL”); is another option, but as page slugs/URLs may change during successive previews, invalid URLs might still occur.

I just checked some webmaster tools stats and I don’t see any crawl errors for the custom doubleclick stuff that we’re doing. Maybe DFP async related? Our workflow more than likely doesn’t include a lot of preview views though either.

Womp womp. :) I’m on a heavy deadline until the 21st, but I’m going to try to squeeze in some time between now and the 20th. Going to pause on #42 for a bit, because it’s dragging me down, but I’ll see what else I can clear up.

Looking to update the ads via ajax, and stumbled onto the fact that the do_action will not work within an ajax call. Daniel reminded me that that is because the do_action() is dependent on the context (e.g. which post is loaded or the page that the ad is on). Would be great to be able to individually call (to update, or place the ad after the page has loaded) an ad code this way. Thoughts?

But I would need the same conditionals to apply to this faux page that apply to the originating page. I.e. If I chose “is_home” as a conditional, and then reload the ads the way you’re suggesting, the same conditionals won’t apply (since a separate template is not, obviously, the home page). Am I missing something?

Well, nothing restricts you to add another conditional to home page ad tag that’ll match with this faux page. This approach is tested and works. The other way around would be calling the rendering method directly, but that probably wouldn’t work since there’s a bunch of hooks that are probably won’t get fired in AJAX context. Pull requests are always welcome :)

v0.3 is out the door. Thanks again to @jtsternberg for his great contribution. In honor, I’ve given him push and pull access to our Github repo so he can help manage the project. Remember though: it never hurts to create a pull request to get another pair of eyes on your code before committing to master.

Any support for targeting Dec. 5th for a v0.4 release? Here’s what we have on the docket right now. I’m hoping to dive into the configuration builder/scanner tomorrow and through the weekend. Feel free to pick up any unclaimed issues.