Ad Code Manager v0.4: Easier Configuration for Google AdSense and Doubleclick For Publishers Async

Ad Code Manager is a plugin designed to help you deal with ad codes, those short snippets of Javascript used to display advertisements on your website. Yesterday, Rinat Khaziev of Doejo, Jeremy Felt of 10up, and I released version 0.4.

This release incorporates the following:

  • Streamlined configuration for Doubleclick for Publishers Async and Google AdSense. Check out the configuration guide for more details.
  • Faster, cleaner JavaScript thanks to Jeremy Felt and Carl Danley.
  • New filter ‘acm_output_html_after_tokens_processed’ for rare cases where you might want to filter html after the tokens are processed.

Ad Code Manager v0.4 is already installed on WordPress.com VIP, and available to download for WordPress.org installs. Please report any bugs, feature requests, or questions in the WordPress.org forums. Or fork the plugin on Github and follow our development blog to help with future improvements.

Co-Authors Plus v3.0: Introducing Guest Authors

Co-Authors Plus makes it possible to assign multiple bylines to posts, pages, and custom post types via a search-as-you-type meta box. Version 3.0, several months in the making, allows you to assign bylines without having to create corresponding WordPress user accounts. Simply create a guest author profile for the writer and assign the byline as you normally would.

Guest authors can have all of the same fields as normal users, including display name, biography, and avatars. In fact, you can extend the model to include your own fields too. On the frontend, guest author profiles appear as normal user accounts would.

Many thanks to Austin Smith at Alley Interactive for his assistance with much of the original architecture.

This release also includes:

  • Support for non-Latin characters in usernames and guest author names.
  • wp-cli subcommands for creating, assigning, and reassigning co-authors.
  • For themes using core template tags like the_author() or the_author_posts_link(), you enable Co-Authors Plus support with a simple filter.
  • New author terms are now automatically prefixed with ‘cap-’ to avoid collisions with global scope. You can run wp co-authors-plus migrate-author-terms to migrate and prefix existing terms.
  • Bug fix: Apply query filters to only post_types registered with the taxonomy. Props Tom Ransom.
  • Filter coauthors_posts_link_single() with ‘coauthors_posts_link’. Also adds rel=”author”. Props Amit Sannad and Gabriel Koen.
  • Filter for the context and priorities of the Co-Authors meta boxes. Props Tomáš Kapler.
  • Renamed the post meta box for selecting authors so it applies to many post types. Props John Blackbourn.

Co-Authors Plus v3.0 is already available in the VIP Shared Plugins directory for WordPress.com VIP hosted clients. Everyone else is welcome to leave feedback, bug reports, and praise in the WordPress.org forums. Get involved with development on Github.

Ad Code Manager v0.2.2: Bulk Delete and Google AdSense Provider

Ad Code Manager is a plugin designed to help you deal with ad codes, those short snippets of Javascript used to display advertisements on your website. Yesterday, Rinat Khaziev of Doejo, Jeremy Felt of 10up, and I released version 0.2.2.

This release incorporates the following:

  • New Google Ad Sense provider courtesy of Erick Hitter from Oomph
  • Bulk delete action added for the WP List Table of ad codes. Delete more ad codes in one go
  • New ‘acm_register_provider_slug’ for registering a provider that’s included outside the plugin (e.g. a theme)
  • Bug fix: Instantiate the WP List Table on the view, instead of on admin_init, to reduce conflicts with other list tables

Ad Code Manager v0.2.2 is already installed on WordPress.com VIP, and available to download for WordPress.org installs. Please report any bugs, feature requests, or questions in the WordPress.org forums. Or fork the plugin on Github and follow our development blog to help with future improvements.

New Plugin: Rewrite Rules Inspector

Rewrite Rules Inspector is a simple development tool for viewing all of the rewrite rules registered with your site. It’s been available for VIPs hosted on WordPress.com for a while — today it’s available for download from the WordPress.org repository.

Specifically, the Rewrite Rules Inspector helps you:

  • View a listing of all your rewrite rules.
  • See which rewrite rules match a given URL (and the priorites they match in).
  • Filter by different sources of rewrite rules.
  • Know when rewrite rules are missing in the database by showing an error message.

Feel free to fork the plugin in Github — pull requests are always welcome. Hit us with feedback, questions, bug reports, and feature requests in the forums.

Ad Code Manager v0.2: UI Redesign, Support for Custom Ad Networks, and a New Widget

Ad Code Manager is a plugin designed to help you deal with ad codes, those short snippets of Javascript used to display advertisements on your website. This week, Rinat Khaziev of Doejo, Jeremy Felt of 10up, and I are excited to bring you version 0.2.

It’s chock full of these new features:

  • Completely reworked user interface, one that now looks and feels like much of the rest of the WordPress admin.
  • Abstracted ad network logic, so you can integrate additional ad networks. Currently, Ad Code Manager fully supports Double Click for Publishers. Pull requests with support for other ad networks are always welcome.
  • In-plugin contextual help to get you properly configured.
  • Priorities for ad codes, which allow you to work around conflicts.
  • An [acm-tag] shortcode for placing ad codes within posts.
  • A widget for placing ad codes in widget areas. Thanks to Justin Sternburg at WebDevStudios for the contribution.

We’ve also fixed these bugs:

  • Enabled using ad codes with empty conditionals.
  • Setting the logical operator from OR to AND now results in the expected behavior.

Ad Code Manager v0.2 is already installed on WordPress.com VIP, and available to download for WordPress.org installs. Please report any bugs, feature requests, or questions in the WordPress.org forums. Or fork the plugin on Github and follow our development blog to help with future improvements.

Pando Daily and Grist.org launch on WordPress.com VIP

Last week, two new sites launched on WordPress.com VIP that we’re pretty excited about.

PandoDaily

PandoDaily is a brand new tech site started by Sarah Lacy, former senior editor at TechCrunch. From her announcement post:

We have one goal here at PandoDaily: To be the site-of-record for that startup root-system and everything that springs up from it, cycle-after-cycle. That sounds simple but it’ll be incredibly hard to pull off. It’s not something we accomplish on day one or even day 300. It’s something we accomplish by waking up every single day and writing the best stuff we can, and continually adding like-minded staffers who have the passion, drive and talent to do the same.

Grist

Grist, a non-profit environmental news publication:

Grist has been dishing out environmental news and commentary with a wry twist since 1999 — which, to be frank, was way before most people cared about such things. Now that green is in every headline and on every store shelf (bamboo hair gel, anyone?), Grist is the one site you can count on to help you make sense of it all

Welcome to the VIP family, Pando Daily & Grist! 

Ready to become a VIP Services Client? Some of the world’s biggest brands rely on WordPress.com VIP Services.

Key Differences Between Validation and Sanitization

VIP Services developer Daniel Bachhuber shares some tips on writing better code for your WordPress site:

Your code works, but is it safe? When writing code for a high-profile environment, you’ll need to be extra cautious of how you handle data coming into WordPress and how it’s presented to the end user. This commonly comes up when building a settings page for your theme, creating and manipulating shortcodes, or saving and rendering extra data associated with a post.

There’s a distinction between how input and output are managed, however.

Validation: Checking User Input

To validate is to ensure the data you’ve requested of the user matches what they’ve submitted. There are several core methods you can use for input validation; usage obviously depends on the type of fields you’d like to validate. Let’s take a look at an example.

Say we have an input area in our form like this:

<input type="text" id="my-zipcode" name="my-zipcode" maxlength="5" />

Just like that, we’ve limited my user to five characters of input, but there’s no limitation on what they can input. They could enter “11221″ or “eval(“. If we’re saving to the database, there’s no way we want to give the user unrestricted write access.

This is where validation plays a role. When processing the form, we’ll write code to check each field for its proper data type. If it’s not of the proper data type, we’ll discard it. For instance, to check “my-zipcode” field, we might do something like this:

$safe_zipcode = intval( $_POST['my-zipcode'] );
if ( ! $safe_zipcode )
$safe_zipcode = '';
update_post_meta( $post->ID, 'my_zipcode', $safe_zipcode );

The intval() function casts user input as an integer, and defaults to zero if the input was a non-numeric value. We then check to see if the value ended up as zero. If it did, we’ll save an empty value to the database. Otherwise, we’ll save the properly validated zipcode.

This style of validation most closely follows WordPress’ whitelist philosophy: only allow the user to input what you’re expecting. Luckily, there’s a number of handy helper functions you can use for most every data type.

Sanitization: Escaping Output

For security on the other end of the spectrum, we have sanitization. To sanitize is to take the data you may already have and help secure it prior to rendering it for the end user. WordPress thankfully has a few helper functions we can use for most of what we’ll commonly need to do:

esc_html() we should use anytime our HTML element encloses a section of data we’re outputting.

<h4><?php echo esc_html( $title ); ?></h4>

esc_url() should be used on all URLs, including those in the ‘src’ and ‘href’ attributes of an HTML element.

<img src="<?php echo esc_url( $great_user_picture_url ); ?>" />

esc_js() is intended for inline Javascript.

<a href="#" onclick="<?php echo esc_js( $custom_js ); ?>">Click me</a>

esc_attr() can be used on everything else that’s printed into an HTML element’s attribute.

<ul class="<?php echo esc_attr( $stored_class ); ?>">

It’s important to note that most WordPress functions properly prepare the data for output, and you don’t need to escape again.

<h4><?php the_title(); ?></h4>

Also, as there are always exceptions to the rule, there are a selection of user-submitted data that needs to be validated and sanitized. Freeform text areas would fall into this category. For this, you can run user data through sanitize_text_field() or any of the wp_kses_*() functions.

To recap: follow the whitelist philosophy with data validation, and only allow the user to input data of your expected type. If it’s not the proper type, discard it. Sanitize data as much as possible on output, and a selection needs to be sanitized on input too.

Hit us with your questions or tips in the comments.