Co-Authors Plus 3.1: Manage co-authors from Quick Edit, misc improvements

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. Thanks to Mike Patek at Vocativ, version 3.1 includes co-author management via Quick Edit:

2014-03-17 at 3.48 PM

Also in this release:

  • Updated Spanish translation, courtesy of sergiomajluf.
  • Now matches core behavior when displaying author archive on multisite: user of the blog, or previously published author on the blog.
  • Breaking change: “Create Profile” link is no longer shown by default on the Manage Users screen. Instead, it can be enabled with the coauthors_show_create_profile_user_link filter.
  • Guest authors work properly with Jetpack Open Graph tags. Props hibernation.
  • Guest author profile editor now supports a few different fields. Props alpha1.
  • New coauthors_count_published_post_types filter for specifying the post type(s) used when calculating the user’s number of published posts.
  • Bug fix: Ensure post_author is set to one of the co-authors assigned to a post.
  • Bug fix: Filter author feed link for guest authors on the author page. Props hibernation.
  • Packages a composer.json file for those using Composer.
  • Beginnings of unit test coverage for core features. Increased minimum required WordPress version to 3.7 because unit testing framework doesn’t work reliabilty below that.

Please leave feedback, bug reports, and praise in the forums. You can also get involved with development on Github.

Paid feature development of open source plugins

On Twitter this morning, I asked: How do you feel about having clients sponsor development of specific features? Good idea or fraught w/ problems?

Apparently this dilemma resonates with developers:

  • Rarst: “sounds better in theory than works in practice, from my limited experience”
  • Boone: “Generally a good idea, as long as the client’s needs aren’t so wacky as to make the feature awkward for general release. You might also include something in the agreement about post-contract support of the feature. Transition from ‘I’m paying you to implement my wishes’ to ‘I’m a regular user making feature requests’ is the tricky point”
  • Eric: “If you properly vet these specific features (as opposed to blindly accepting cash) I think it’s a good idea. Biggest drawback is when the sponsorship dries up and you still have to support said feature in the plugin.”
  • Brad: “great idea, not only features but full plugins. Easy to sell them on it knowing you’ll keep it up-to-date with current WP”
  • Brady: “I’d say it’s a great route if the feature makes sense for general use, otherwise an extension/add-on might be better.”
  • David: “good idea, as long as client understands the difference between customization and configuration. Oh, and proper contracts.”
  • Nick: “As long as they understand they don’t own that feature and you may need to implement it in a more general way, it can work. One approach is to make it an addon and add the necessary hooks in core plugin. Allows you to EOL the feature if needed.”
  • George: “don’t see anything bad in developing add-ons for side income, plus you might never developed for your use.”
  • Jake: “as others said, it’s all about good expectations upfront, and not compromising the rest of the plugin’s audience”
  • Travis: “Personally, I think it is a win-win, but it heavily depends on the “strings attached” mentality of the sponsor.”
  • Ryan: “I’ve done that many times before and have encouraged it. I usually gave a big discount for open source stuff. I used to provide two prices, one for open source, one for closed source. Everyone chose the cheapest option.”

My takeaways:

  • Make sure you’re explicit about the business relationship upfront (including support scope), probably in contract. If you aren’t, it can get complicated.
  • If it fits within the scope / roadmap of the plugin, it can be a nice way to bootstrap open source development. Otherwise, it probably makes sense as an add-on.
  • Pay attention to what users want as add-ons, as you can potentially turn those into premium plugins.



Idea: WordPress plugin for wp-cli so I could use the latter in the WordPress admin. Like Hopscotch, but installed on the site instead of as a browser extension. A sort of power user mode for the WordPress admin.

End of one era, on to the next

Automattic has claimed ownership of the plugins I worked on during my employment. As such, the VIP team and others will be taking responsibility for their continued development, maintenance, support, etc. Hopefully they remain independent and aren’t rolled into Jetpack. I’ll contribute as relevant to Human Made projects, but will no longer take an active role with the plugins.

These plugins include:

  • Edit Flow
  • Co-Authors Plus
  • Ad Code Manager
  • P2 Resolved Posts
  • Document Feedback
  • Rewrite Rules Inspector
  • Custom JavaScript Editor

Sometimes what appears to be a curse is actually a blessing in disguise. Human Made has pretty neat products in the works that I’m enjoying applying my creative energy towards. Stay tuned for that. And, on the open source side of things, I’ll have more time to contribute to wp-cli.

To everyone who’s used one of the above: it’s been a pleasure working with you. I’m looking forward to the opportunity to do so again in the future.