Setting conditionals on a code by code basis was deployed to wpcom.
Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts
Merged Justin’s pull request to set the logical operator on an ad code by ad code basis, and restored the previous behavior of the logical operator filter.
The class-level logical operator will set the default value of the dropdown. If you change the dropdown, your change will be stored in the database and be the logical operator used for the ad code.
Considering the following case though: I create three ad codes with OR as the logical operator because I don’t touch the dropdown, and then implement the filter to change the default to AND. Is it a usability issue not to change the first three ad codes too?
I’m going to drop this on wpcom Wednesday and maybe we can ship v0.3 Thursday or Friday.
Collapsed the develop branch onto master, and deleted it on Github. Create a feature branch please if the code you’re committing isn’t stable between commits.
I’ve created an #adcodemanager channel on Freenode if you guys would like to join. I also added a text widget to the sidebar with some details about the project.
While I was working on mobile theme for localtv I hit a bump with the following use case:
Ad server returns a chunk of HTML instead of injecting script into DOM, I also couldn’t make it as iframe source, since it’s just a chunk instead of full HTML documents. This led to a hack that @batmoo qualified as “pretty lame”: I make an ajax request that passes constructed URL to ajax action, that fetches remote URL and returns this piece of HTML.
Not sure of the best solution, perhaps, adding another hook like “acm_output_callback” or something like this.
Posting @batmoo’s idea because I don’t think he’ll ever get around to it: it would be neat if Ad Code Manager could support more than one ad provider.
Trying to make it easier to understand how ACM could apply to various DFP (JS API) setups. I think I’ve wrapped my mind around a few ways to target things via DFP and I’m building up some sample scripts for each scenario. Is anything in this list crazy?
1) The ad unit in the header template will always be ‘header_728x90’ (*sitewide*) and all targeting will be done via orders created in DFP based on unit/time/etc.
2) The ad unit in the header template is more dynamic and could be called as ‘header_728x90’ or ‘header_alt_728x90’ or …, it is targeted via orders in DFP but needs to change depending on the view – home, category, single, etc…
3) The ad unit in the header will always be ‘header_728x90’ (*sitewide*), but key/value pairs will be targeted via orders in DFP that should be included with the ad call depending on the page view – home, category, single, etc….
4) Combo of 2 & 3
I’ve started a gist here – https://gist.github.com/3441995 – that I’m building out some more.
One of the things that’s come up during this exploration is wondering how useful ACM is to somebody that is using scenario 1 above. Also, scenario 4 just scares me… 🙂
The 0.2 branch is looking good, so let’s talk 0.3. I recalled some ideas that were floating around since 0.1, but were never actualized:
- Configuration scanner: verify configuration checklist ( provider file is present, ACM_WP_List_Table columns are properly defined, ad code args are set correctly, there’s at least one tag id, etc)
- Ad Code Preview: This should be probably a row action which either pops an overlay with previews or displays them inline
- Configuration builder: this one might be an overkill( aka punt candidate or fuggedaboutit), but it would be nice to have some tool that would generate configuration filters. Basic worklow would look like: user chooses one of existing ad providers, and modify some of default settings. For an average user, who downloaded plugin and who doesn’t know much about PHP coding, an ability to visually configure stuff would come in handy.
What do you think on these points? Do you have any other ideas/solutions? I personally appreciate the idea of keeping things contained and not over-bloated, but users get confused over configuration. I mean, one have to define 5-10 filters to get things up and running. This could be a deal-breaker for some folks.
Just tagged v0.2.3 on WPORG. Thanks y’all!
Synced over the extent of this commit to WordPress.com VIP (except the unit tests).
If you could commit against an issue when you’re making improvements, it would be much appreciated. It’s much easier to refer to a series of commits this way 🙂