Status

WordPress developers (especially core) should publish with their software on a daily basis.

Context: Non-technical users are generally only subconsciously aware of usability issues. Technical users know how the magic happens. When actively using their own software, they have greater visibility into usability issues, and what steps could be taken for improvement. In helping teach the Newbie workshop over the last two days, I’ve relearned just how painfully complex it is to learn how to publish with WordPress. If those who build or design with WordPress also published with WordPress on a daily basis, we’d have that much better software.

As an example: it would be awesome of all of these WordCamp San Francisco presentations were posted as WordPress galleries instead of as PDF or Slideshare.

#18362 Post timestamp creation should use whitelisted post statuses instead of blacklisted

Aside

#18362 Post timestamp creation should use whitelisted post statuses instead of blacklisted. One approach to solving a timestamp problem with Edit Flow custom statuses. Instead of blacklisting the post statuses that shouldn’t receive GMT timestamps, whitelist the ones that should.

#wcbos: Plugins Are Blueprints

Marc Lavallee (@lavallee) and Wes Lindamood (@lindamood) are half of the NPR Project Argo team. Both were relatively new to WordPress when they started; today they’ll be talking about the zen of using plugins.

“Each plugin speaks with it’s own voice,” says Wes. Sometimes they can produced cluttered and confused experiences for your users. The framework they’ve chosen as it relates to plugins is use, patch or build.

  • “Use” means they install the plugin, activate it, and it’s live. They may make minimal modifications with CSS, but it’s generally fine to go out of the box.
  • “Patch” means they may make minor modifications to the codebase, through hooks or actually changing core, and then try to push the improvements they made back upstream.
  • “Build” means they take ideas and inspiration from other options in the WordPress plugin directory, and roll their own plugin.

Example: Navis Slideshow

The Argo team decided to build a photo slideshow plugin that leveraged WordPress’ built in gallery functionality, and looked and worked as a standard slideshow.

Their functional starting point was the Slides for WordPress plugin. Wes downloaded and activated the plugin, and made basic presentation tweaks with CSS and Javascript. Unfortunately, there were other behavioral changes they wanted too. They thought about patching but then realized it would too much work. So they went around to rolling their own plugin.

Two improvements worth mentioning are conditionally loading images and Javascript. For the first, the problem to solve is reporters that like 60+ image photo galleries. If you load all of these images on page load, it increases your bandwidth costs and load time for end users. The solution is to reference the image URLs in a storage div, and then only load them when the user is getting close to viewing them. For the second, there’s a global variable on every page load for marking whether a WordPress gallery was included in the post. If so, the Javascript gets added to the footer.

Improvements included reducing the footprint of the plugin from 39k/895 lines to 8k/244 lines.

Example: Jiffy Posts

To make their content more engaging, Argo wanted it to make it easy for their reporters to embed rich media. Initially, this looked like Embedly or oEmbed but they didn’t want to cede control of what was embedded to the content provider.

Solution: A custom post type called Jiffy Posts. Reporters could create a new post with a title, short comment, link to the referenced media, and can include source attribution. Doing it this way, instead of having reporters embed rich media in the post, ensures there’s presentation consistency from post to post and content type to content type.

Ultimate takeaway: The decisions and opinions of plugin authors can directly impact the user experience of your website. Think about this more holistically, beyond just reviewing whether the code is clean.

The slides from the presentation are available on Slideshare and download as a PDF.

WP.org trac tickets you should follow

One of my goals this summer is to contribute more to WordPress, the open source project we all know and love. To kick this off, I’ve started tickets for small improvements I think will make the software significantly more usable. You should follow the tickets if you want to help make them reality.

#18031 Add a “Network Admin” link to WP Admin Bar

Currently on a multisite instance, the super admin must first navigate to the dashboard (using a link on the left in the admin bar) and then use a dropdown menu all of the way on right of the dashboard that requires a click to access the Network Admin. In short, this is frustratingly complex; there should be a way to easily access the Network Admin from the admin bar. I propose we add a “Network Admin” link for Super Admins in the account dropdown. Optionally, we could also add sub menus to the primary sections of the Network Admin.

#18082 Reset screen options button

It would be nice to have a “Reset” button in screen options to restore any given admin view back to the factory defaults.

#18160 Auto-suggest usernames on views for adding user to site

In a multisite network, it’s often difficult to try and remember usernames, or a pain to search the users table, and then copy and paste the username you’ve found into the window with the form. Furthermore, site admins have no access to a global table of users to search and add from. If we can solve the scaling issues, it would be much better to be able to auto-suggest usernames when a site admin or super admin is adding a user to a site.

#18161 Bulk action: Add user to multiple sites

Currently, to add a single user to multiple sites, the super admin has to edit each site, add the user to the site, and then go on to the next site. To improve this workflow, it would tremendously useful to be able to add a single user to multiple sites in the network admin.

#18163 Include more usermeta fields in the Network Admin’s “Add User” view

The view for adding a new user in single site instances includes many useful fields (e.g. first name, last name, a checkbox for whether the user should be emailed the password, etc.). We should replicate this in the network admin to keep the super admin from having to edit each individual profile.

P.S. If you can see this blog post, you’re reading it from a brand new server powered by Rackspace Cloud. Galleries didn’t make it in the import but I’ll fix those shortly.

5 reasons news organisations prefer in-house web publishing tools

Aside

5 reasons news organisations prefer in-house web publishing tools. Greater assurance it integrates with the rest of your stack, you ensure the content lives on permanently, aren’t subject to everchanging third-party terms of service, opportunity to build a better workflow around the tool, and, most importantly, building in-house can give you a competitive advantage.