Category Archives: WordPress

WordCamp US 2017: 5 Steps to Better WordPress Performance for Non-Developers

Below is my presentation from this year’s WordCamp US in Nashville, TN. In the spirit of democratising publishing I wanted to help non-developers and individuals/small business owners to have better performing websites with minimal effort.

The slides are minimal, so once my talk is up on WordCamp.tv I’ll put that here too!

 

Late escape your WordPress plugins!

A little while ago a colleague shared this interesting article from RIPS on the state of WordPress security. It focused on an automated analysis of 44,705 plugins from the WordPress.org plugin directory (almost all of them).

They found that 68.4% of those plugins contained cross-site scripting vulnerabilities. That’s a huge number, and a huge number of vulnerable WordPress installs as a result.

If you’re a plugin developer it’s important to protect yourself and the users of your plugin from such attacks. The solution is quite simple; late escaping.

Anything that your plugin outputs to the browser (e.g. using echo, print, __ etc) should be escaped using the functions WordPress core provides. This is something I advise developers about every single day while I review code for WordPress.com VIP clients.

There’s a really insightful post on escaping within WordPress from 2014 by my colleague Nick Daugherty that I highly recommend reading to get up to speed on why and how to escape late.

Finally, this from the article is also worth pointing out:

WordPress [sic] is not as insecure as its reputation would suggest. Rather it is a top target due to its incredible prevalence.

If you were an attacker, wouldn’t you go after 27% of the web if you could?

Feeling RESTful

A month ago I took a (relatively) short train ride into the beautiful Derbyshire countryside to spend a week coding in the middle of nowhere.

I was attending A Week of REST – a training event put on by the excellent folks at WordPress agency, Human Made.

Part of a group of about 20, we descended on Darwin Lake near Matlock, a beautiful set of holiday cottages set around a lake and right next door to the Peak District National Park – one of Britain’s best destinations.

Being remote there was no mobile signal and the wifi was pretty terrible! But that didn’t matter – the course had been set up in such a way that an internet connection was more of a luxury and the disconnect allowed us to concentrate on learning and interacting with each other.

So what did I learn?

I learnt how to build a standalone React app in ES6 syntax, using NPM and Webpack for a local development environment. I learnt how to authenticate with the REST API from Javascript, send different types of request and interact with the responses within React.

Building a React app was very different to developing for WordPress. We used NPM and Webpack to create a local development environment (sitting at localhost:3000) and we were writing entirely in JS/JSX and there was even an index.html file! Crazy times.

The API endpoints were just a WordPress plugin, and creating them was much like interacting with other WordPress APIs. I’d equate it to registering new post types, so very simple for a WordPress developer to get on with.

Having done the React class at last year’s Automattic Grand Meetup everything I learnt came flooding back, so that wasn’t a big challenge. Using ES6 was weird at first but I quickly came to enjoy it – and I really don’t enjoy JS dev usually 😉 The biggest challenge was probably understanding authentication with the API. While we only used one authentication method and had a helpful library to make it easy, there are some complicated concepts to get your head around and there were a lot of questions on that topic from the group.

The teachers – Joe Hoyle, Ryan McCue and Zac Gordon – were great. We went at a good pace, no-one got left behind and we were given lots of opportunities to ask questions. I’d recommend looking out for future Human Made events, including A Day of REST and you should certainly check out Zac’s Javascript for WordPress course.

Not only were they great teachers, I had a great time hanging out with them, the other Human Made crew and the other attendees. I’m lucky that because of my awesmazing job I already knew some of the HM folks (and met some I work with but hadn’t yet met in person!) which made socialising easier, but I also got along really well with my fellow students, and really enjoyed our various games and late night shenanigans 🙂

Finally, it wouldn’t be right to spend such a long time without an internet connection and not have something to show for it. So I present to you my very first solo-built standalone React app: howmuchhuel.com.

I’ve recently started using Huel* regularly and needed a quick way to measure the mixture on my phone, so I built this neat little app. The calculations are a bit scrappy, but it works. Contributions welcome.

*get £5 off with this link,  because I love you.

WordCamp Europe 2014: Sofia, Bulgaria

All images in this post provided under the CC-BY-SA license.

WordPress security: the case for dependency management

Two things happened in the last week to spark this post; I gave the weekly “Show and Tell” at work on my favourite things about Drupal that I’d like WordPress to learn from (one of them should appear in 4.1, by the way), and yesterday a vulnerability was revealed in the still popular TimThumb library used by many WordPress themes and plugins.

Dependencies

One of my favourite things about Drupal is that it offers theme and module developers the ability to use dependencies. A few simple lines in the module.info file (Drupal’s sort-of readme.txt equivalent) can specify that the module depends on other modules and Drupal will recognise that, offering to install and/or enable those modules for you in order to meet those dependencies. E.g.;

dependencies[] = views
dependencies[] = rules
dependencies[] = features

That’s not all though, Drupal also allows module developers to specify required libraries in a similar way. Those libraries are then installed in a ‘libraries’ directory alongside the modules directory.

Duplicated Effort

By contrast, WordPress plugin and theme developers often have to bundle those libraries into their plugin or theme. The result, when a security issue like yesterday’s TimThumb exploit is revealed, is that individual plugin and theme developers need to update their projects individually and push out an update, leaving users vulnerable until the developer gets round to it.

Instead, having a system like Drupal’s dependencies means that, once the library itself is updated, all installations could pull down that library update and secure their site without the plugin/theme developer having to lift a finger. Installs are secured quicker with minimal effort.

There are other benefits to a dependency system but I believe the security angle is by far the most compelling.

My suggestions above actually go a bit further than what Drupal offers at the moment, I believe, but a system that works as close to the plugin/theme system as possible would be beneficial.

TimThumb, seriously?

Before you say it, yes, there is a better way to deal with TimThumb specifically. David Bisset put it best:

Thoughts?

Picture credit: The Colorful Library of an Interaction Designer by See-ming Lee

Could/should the WordPress Foundation do more?

Wordpress_logoGenuine question.

A couple of posts have caught my attention over the last week;

It got me thinking about the WordPress Foundation and whether it could do more to help promote WordPress. With 18.9% of the web powered by WordPress you might think there is no need! You might be right.

As John points out, efforts from the likes of the WordPress.com VIP team and the Big Media & Enterprise WordPress meetups are great, but with much of that coming from Automattic and WordPress agencies, is there a case for pooling that effort to better promote WordPress more widely, and with more independence?

Already the Foundation gives enabling support to WordCamps and it’s fantastic that we have so many. Here are some quick ideas off the top of my head of other promotional efforts the Foundation could* do;

  • WordPress sector champions who would work on promoting the use of WordPress in specific sectors, producing case studies, networking in those sectors, generating connections and leads for agencies and freelancers and so on. Target sectors might include;
    • Enterprise
    • Education
    • Government
    • Retail
    • Journalism
  • Core support staff who would help with organising IRC chats, trac tickets, helping new contributors get started, running/supporting contributor days. These could be either employed direct by the Foundation or seconded to it by agencies. (I have no idea if some of the work I’ve mentioned here is even required.)
  • Outreach people to help arrange things like Google Summer of Code and other as-yet-unspecified outreach projects aimed at getting folks engaged with WordPress.
  • A WordCamp team who would work with and support WordCamp organisers. Likely nothing/little needs to change on this point anyway.

Of course, all that would need funding, and I’m reminded here of the jQuery Foundation and it’s membership structure. Something similar for the WordPress Foundation may work, and help those involved in WordPress feel like not only are they contributing to WordPress the project, but also the WordPress ecosystem.

What do you think; does that sound like a good idea, is is necessary, is it a terrible idea, is it okay but could be done differently? Shout below!

 

* Not could as in could do now, but could do at some point, if the resource was available.

Hiding bbPress topics from logged out users

I just spent hours figuring this out so I thought I’d try and save others the bother by sharing it here.

The basic aim was to hide the contents of topics in a bbPress 2.0 forum from any users not logged in. This makes for a nice private forum.

I found suggestions about making forums hidden, private and so on but none of them really worked as they hid them for logged in users too.

My final solution was to make bbPress ‘dumb’ when it comes to logged out users. I.e., it could either be clever and say “there are topics, but you’re not allowed to see them until you login” or it could just say “there are no topics”.

The following code does the latter, dumb version by hooking into the forums, topics and replies loops.

function pj_hla_logged_in_topics($have_posts){
if (!is_user_logged_in()){
$have_posts = null;
}
return $have_posts;
}
add_filter('bbp_has_topics', 'pj_hla_logged_in_topics');
add_filter('bbp_has_forums', 'pj_hla_logged_in_topics');
add_filter('bbp_has_replies', 'pj_hla_logged_in_topics');

I simply placed this within my theme’s functions.php but you could just as easily wrap this in a plugin.