THE PENDING DRAFT

Automatic Updates for WordPress Plugins and Themes

March 16, 2015

Last week, a security vulnerability in Yoast’s WordPress SEO Plugin was discovered and fixed. It was responsibly disclosed and a bugfix was released promptly.

So far so good. But i – as well as many others – was surprised (to say the least), when i found out that the plugin was already updated without me or my clients doing anything.

It turns out that the WordPress.org Security Team decided that this vulnerability was severe enough to justify an automatic rollout for all sites which have the plugin installed.

By default, automatic background updates only happen for plugins and themes in special cases, as determined by the WordPress.org API response, which is controlled by the WordPress security team for patching critical vulnerabilities.

In principle i appreciate the possibility to push out important security related updates to all WordPress Installs around the world and i’m aware that we already do something similar with minor core updates, but the way this happens needs some refinement.

Notifications

It needs to be clear when something has been updated automatically. Period. Admins need to get an email (like they do for automatic core updates) and maybe there should also be a notification in the admin area / dashboard on next login.

Documentation

The whole process of automatic Updates for Core and Plugins needs proper documentation in the Codex so everyone is on the same page what happens, when it happens and why it happens, when it happens. This alone would have calmed down the whole confusion a lot last week. I know there are people working on this and the according Codex has already been updated since last week, which made it a lot more clear. The quoted description on top of this post was added after last weeks Update.

An Option to disable automatic updates?

It should be easily possible to disable automatic updates altogether and it should be crystal clear which auto-updates (core/plugins/themes) are affected. I’m ok with this being opt-out, but it needs to be possible in an easy way. Right now you could disable auto-updates by setting a filter like this:

add_filter( 'auto_update_plugin', '__return_false' );

Maybe even a UI-Option to opt-out should be considered.

(This, as said above, has also been updated in the Codex to better explain how to disable certain updates)

Idea: Opt-In Auto-Updates, but different / better Notifications for Admins

I think automatic plugin updates should be a last resort. First of all, i just don’t like the idea of messing around with someone else’s site without their consent. What if something goes wrong with their site during the update? What if they edited some lines in said plugin and the update overwrites their changes? What if a site doesn’t have any kind of backup in place? I know, i know, that’s all awful bad stuff and no one would ever do such terrible things. And yet those things happen! They happen all the time, whether we like it or not.

So, why don’t we implement a better way for admins to distinguish severe plugin updates from normal updates. The only thing it would need would be some kind of a “severe” flag which states that this update is really, really important and then we could add a prominent notification to the Dashboard. Of course, this should also send an email to admins to notify them that they should login and update this particular plugin.

Maybe a combination of this and Auto-Updates could also be done: A notification sent out to admins to let them know that in 48 hours plugin X will be updated automatically if no action is taken and an explanation why this update is important and so on.

This way the admin still has full control of his site, as he should, and would still get notified to take some action if needed.

Another Idea: Auto-Disabling?

Basically the same idea as the last, but instead of updating, the plugin would get disabled, instead of updated, after a certain period of time (e.g. 48h) when no action is taken.

I’m not yet sure what the best solution will be. But what i’m sure is we will have to find a better way than messing around with anyone’s site without letting them know.

Nick Haskins – On Automatic WordPress Updates

grunt-respimg

March 10, 2015

One thing that i haven’t implemented into my grunt workflow up until now is automatic image optimization. grunt-respimg looks like a pretty neat plugin that does just that.

What do you use to optimize your images?

npmjs.com – grunt-respimg

Check for Plugins that are no longer in the Plugin Directory

February 4, 2015

If a plugin gets pulled from the official plugin directory on WordPress.org there could be several reasons for that. Could be that it just became obsolete when a new version of WordPress introduced the features it provided, could be that the developer just stopped developing it, but it could have also been deleted because serious security issues were detected with the plugin. No matter what the reason was, it means you no longer get update notifications and could potentially run into security risks later on.

Today i discovered this little plugin which checks for plugins no longer in the directory and tested it on a local copy of a client site. In addition to removed plugins it also displays if a plugin wasn’t updated in more than two years, which is also nice to know. Keep in mind that this doesn’t give you perfect safety, a plugin can still be in the directory and be outdated or insecure. But if it was removed it’s definitely a good idea to investigate further and to check for alternatives.

WP Plugin – No Longer in Directory

Solve almost no one’s problem

February 1, 2015

The chances that everyone is going to applaud you, never mind even become aware you exist, are virtually nil. Most brands and organizations and individuals that fail fall into the chasm of trying to be all things in order to please everyone, and end up reaching no one.

(Seth Godin)

It’s easy to fall into this trap. We had a similar discussion when we started working on picu some time ago and at first it felt intriguing to try and build The one and only tool for photographers™ but we quickly realized why that’s going to be a bad idea.

What really helped us to figure out what exactly we want to build, and what not, was writing down imaginary user stories of potential clients who could use our product when its finished. What problem should it solve for them, how would they use it and so on. But maybe even more important than that, we wrote down what we called “anti-userstories“. Use cases we deliberately said no to, problems that we don’t want to be able to solve, photographers workflows who will be better served with other tools.

While this seemed silly at first and was a funny exercise, it actually helped us a lot to stay focused and made a lot of our decisions along the way easier.

We are completely aware that our plugin won’t serve every photographer out there, maybe, not even most. But we hope that almost no one will be amazed.

Seth Godin – Almost no one

picu

January 28, 2015

picu - Client Proofing for PhotographersWe finally announced our upcoming WordPress plugin “picu” today. It’s a client proofing solution for photographers, which intends to bridge the gap between the photo shooting and the following selection process with a client. The idea initially came up during the development of a photography website, when the client told me that he was searching for something like this for a very long time and wasn’t satisfied with any of the options available. After a bit of back an forth, Florian and I decided to give it a try and started with the development soon after.

Right now we just started with a closed alpha phase in which we will gather some further feedback from a broader range of photographers in different fields and soon we will launch a public beta. Everything’s still a bit rough around the edges and we have tons of ideas how we can improve and make this thing even more useful for photographers. But as Reid Hoffman, the founder of LinkedIn, once famously said:

If you are not embarrassed by the first version of your product, you’ve launched too late.

Let’s see how embarrassing it will be. Exciting times, stay tuned!

picu.io

Style Guides Podcast

January 22, 2015

Styleguides.io provides a ton of useful resources on Website Style Guides. You find pretty much everything from Articles to Books, Talks, Tools or Examples. If you’re building Style Guides and didn’t know it yet, you should check it out.

Today Brad Frost announced a new Podcast, where he and Anna Debenham will interview folks making Style Guides. In the first episode they talked with Jina Bolton, Senior Product Designer at the Salesforce UX Team and although i’m usually not that much into audio podcasts i gave it a try and really enjoyed it.

Style Guides with Jina Bolton

An Introduction to wp.media by Eric Andrew Lewis

January 14, 2015

Eric Andrew Lewis, one of the core developers behind the “new” (v3.5+) WP Media Workflow gave a talk at the WordCamp Philly about wp.media. While the video has terrible Audio quality which makes it a bit hard to understand, he gives some solid insights into how things work behind the scenes and how we can (at least somewhat) customize a Media Frame or create custom ones.

During the talk he shares a graphical representation of all the Backbone Views and Models that wp.media utilizes, which can be found here:

If you want to understand how wp.media works, you should check out Eric’s Plugin WordPress Media Javascript Guide and he also started the WordPress Media Core Developer Documentation, which i really hope he finds some time to carry on.

Zero

January 13, 2015

It’s always a good thing to have a basic starting point at hand when starting with a new project so you don’t have to write the same things over and over again. While there’s plenty of frameworks, starter themes and templates etc. i thought it would be a good idea to have my own little thingy with exactly the things i need, the way i like to write and structure things. So here it is, maybe it’s of any use for you, too.

A starting point to “jumpstart” a project which contains some of the things i wrote over and over again for each project.

Doesn’t contain any styling, html structure or other project-related stuff. Its basically just my preferred document-structure and a pre-configured Gruntfile.js and package.json.

Nothing fancy, but still very useful for new projects.

Check it out on GitHub and feel free to fork, use or do whatever you like to do with it.