Here are some details about items mentioned in the talk:
Ad Best Practices
Preferred GPT Mode: Single-request mode for all initial ads + Asynchronous mode for all lazy/later ads . Single request mode is used to request as many ads as as possible in the header. Asynchronous calls are used load in ads that appear after some action the user takes, such as opening a gallery, scrolling to the next post, or navigating to a new route in a single page app.
Roadblocking/Master-Companion targeting This is a targeting method to deliver a set of creatives that serve together as roadblocks These master/companion creative sets consist of a master creative and one or more companions. You can set your line item to require that all of the creatives in the set serve together, to require that the master always be accompanied by at least one companion, or just to serve as many companions as possible whenever the master is served. Companion creatives aren’t ever served without the master.
Infinite contents / lazy load: The ads are loaded asynchronously and cannot be guaranteed to follow Master/companion “roadblock” targeting.
Asynchronous Batch mode: refers to loading a new set of ads by batch: for example a page loads with three ads, all are included in the initial header ad batch request. The user scrolls to the bottom and an ajax request loads the next post in-line (lazy/infinite). A new ad batch request is made to get the three ads for the next “page”.
Rich media (OOP, 1×1): OOP stands for “Out of Page” and generally refers to ad units that pop over the page content such as a modal video overlay. A 1×1 is typically an ad unit that changes the page appearance itself, for example adding a background ad image. Best practices call for only a single OOP and 1×1 per page, and generally these units are not used for infinite content. OOP and 1×1 units are best placed immediately before the closing </body> tag or in `wp_footer`.
Single page apps: SPAs treat route changes (navigation) as a new pageview. The correlator is reset, and a new batch of ads is requested for the new view.
Targeting values: Each ad is passed name value targeting pairs that are set in the ad calls. The may include the page url, categories & tags, a ‘pos’ value that increments or a debug value. These are added to the slot definitions as required for ad targeting.
Ad unit names / zones: An ad unit is a container or folder organize ads and connect to a publisher’s page inventory. A zone is a a second level of allowing for further organization of ads.
Correlator value – A correlator value is a unique ID that represents a pageview/session. When a new page loads, the correlator value resets. The correlator value can also be reset manually with a call to `googletag.pubads().updateCorrelator();` A common correlator value is required to deliver all ads for master/companion targeting. Correlator values reset after 30 seconds.
Responsive Ads: DFP provides a method for targeting ads by viewport size. A “sizeMapping” call links each screen size (minimum) with one or more ad sizes; A default size can be provided, as well as specifying that no ad should be shown for specific sizes. Size calculations occur at load time and the developer is responsible for refreshing ads on screen resize (or mobile ‘orientation change’ events).
Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet. This includes requests, responses and the HTTP headers (which contain the cookies and caching information). It is immensely helpful when debugging ad delivery and is likely already the tool of choice for adops.
Charles runs on Mac, Windows and Unix and the $50 license fee is worth every penny when you have an ad that needs debugging.
Since ad requests are sent over SSL, they are difficult/impossible to inspect in the browser’s debug console. Charles fixes that because it can be used as a man-in-the-middle HTTPS proxy, enabling you to view in plain text the communication between the web browser and SSL ad server.
Backbone (and Underscore!) are bundled with WordPress – explore how you can leverage their power to deliver complex user experiences while keeping your code organized and maintainable.
First, we will explore why Backbone is awesome, and what it lets you create is amazing! We will look at some examples of where and how it is used to power web apps and increasingly large areas of the WordPress dashboard. Seeing these incredible user experiences built in Backbone will help get you excited about using Backbone in your next project.
Next, we will dig into Backbone fundamentals to get a crystal clear understanding of the fundamental concepts underlying Backbone applications: Models, Views and Collections. We’ll look at how these tie to templates, events and routes for rendering, interaction and state handling. We discuss using Backbone in themes and plugins: how to include Backbone, how to interact with the back end to get and put data, including using the new WP REST API. We will cover WordPress specific helper functions that help our Backbone projects.
Finally, we will explore several very simple Backbone applications that demonstrate interacting with WordPress using the Rest API.
The revisions system in WordPress has been given a complete overhaul in the new (upcoming) Version 3.6 of WordPress. The new version of revisions patches several longstanding bugs and issues with the revisions system and introduces a slick new user interface for viewing and comparing revisions.
The revisions interface focuses on two primary use cases: undoing mistakes by finding the last correct revisions, and reviewing changes as part of an editorial workflow. To improve these uses, a completely new UI was created, and numerous bugs were fixed.
Highlights of new Revisions features for WordPress 3.6
Revisions Rewrite using Backbone.js – this complete reworking of the way users interact with the stored revisions combines immediate screen updates with a scroller that makes exploring revisions quick and easy. Massive effort was put into refining, testing and improving the system – it allows rapid scrobbing through up to hundreds of revisions. Quickly locate the revision you need and restore it; also allows comparing of any two revisions – no more clicking and waiting to see a comparison, just scroll through to find the revision you need – #23497
Store a copy of the current post data as a revision – keep the revisions data current – previously only the previous save was stored as a revision, now the current save is stored as a revision. #16215
Filter to override WP_POST_REVISIONS (or define it later) – allows you to disable or set the number of revisions allowed on a per site basis setting on a multisite install – #22289
Pass post ID to post revision field filter – #19932
What’s Fixed in Revisions for WordPress version 3.6
Previous versions of WordPress had several problems with the revisions system that have been corrected in the 3.6 release. The following significant bugs were addressed in this release cycle:
Duplicate autosave/revisions clutter the database (because revisions are saved even if nothing has changed) – #9843
Extra revision created every time a new post is inserted– by the first time you published a post, there were already two revisions – #24708
Restoring post revisions does not update _edit_last– now the revisions system tracks who last restored a post revision – #20982
Post Revision history displays the incorrect author – the old system stored a revision before updating a post, yielding bad data that 3.6 corrects. #16215