If you’re looking for the slides from my “Why Switching to WordPress Coding Standards Will Make You a Better Developer” talk that I’ve given at WordCamps and local WordPress events, you can find them here:
In November 2014, I attended my first ever web development conference that would set me on a path which would change my life. This is my love letter to FrontEndNorth, a conference that I not only hold dear, but am co-organising for 2016.
Before you, things were not so good. I wasn’t happy, I really wasn’t myself and I was longing for change.
Although I was in a stable relationship and was doing all that was expected of me, I was frustrated, without hope or any kind of excitement or challenge, clouded by doubts about myself and wondering whether D-Ream was telling the truth about things only getting better.
Then I heard about you, and I decided to see what you could do for me, whether you offered anything I’d been missing out on. Sure, our liaison on that brisk November day was a brief one in the grand scheme of things, but it had a lasting impact on my life that I’m still thankful for today.
I’d been sceptical for a while, unsure as to whether you and your sort were worth giving my time and attention to. Were you really that good, that interesting and you know, fun? I just decided to open my mind and give you a go. What was the worst that could happen?
Well, you certainly didn’t disappoint.
You opened my eyes and made me realise that I could take a new path, one that would be full of fun and new experiences, complete with plenty of exciting opportunities and interesting people along the way, not to mention hard work! A path that would challenge and reward me in equal measure. I’d just need to be hungry for it and commit myself fully, holding nothing back.
I was keen to make an impression during that day we spent together, as I’d realised quite early on that it was a perfect time to roll the dice and see what happens, to see if the old proverb “fortune favours the brave” was true.
So I did my best to impress and be noticed, and it paid off. I ended up going for a few drinks in the evening, and took a chance. And as a result of taking that chance, I’m in a new relationship now, one that has completely changed my life for the better.
I’ve grown as a person these last 18 months or so, more than I thought I could in such a short space of of time. I travel more than I have in a long time, and have met so many interesting people along the way. I’m encouraged to do and try new things, and I spend so much more time at home than I thought I’d be able to.
Most importantly, my voice is heard and my opinion counts. I feel like I make a difference and that I’m not just there to serve a purpose until the next one like me comes along, unlike in my previous relationship.
All because of that one day with you.
Granted, it’s been a lot of hard work, but what relationship isn’t? We Make and Do so much, enjoying the good times and tackling the bad times together. We have each other’s backs and want to better ourselves, and that’s what matters.
After you led me to such a fantastic opportunity back in 2014, I’m so excited to be seeing you again later this year, but this time I’m in a position to help you make a difference to other people’s lives, the same way you made a difference to mine. Sure, you can be stressful at times and it’s been a while since anyone has seen you, but a little mystery goes a long way doesn’t it?
I just hope those people with whom our paths will cross with on September 30th, when we see each other again in Sheffield, who are in a similar position to the one I was in when I met you nearly two years ago, decide to make the most of the day and fall for someone or something new, because it is absolutely worth it. If you want it enough.
P.S If you’d like £20.00 off a standard delegate rate ticket to FrontEndNorth use the code DAVEFEN when buying through EventBrite.
One of the things I love about being a WordPress developer is the ongoing discovery of core functions that make my life easier, or empower me to implement more best practice in my code
One of the things I love about being a WordPress developer is the ongoing discovery of core functions that make my life easier, or empower me to implement more best practice in my code.
At Make Do one of my chief internal responsibilities as front-end lead is managing our workflow boilerplate Kapow! which we use as a basis for all new WordPress projects.
In the theme component of Kapow! I’ve been happily adding a script to header.php the old fashioned way, which contains various poly-fills and shims to provide enhanced out-of-the-box support for legacy IE versions 7 & 8.
Normally I would rely on WordPress core’s wp_register_script() and/or wp_enqueue_script() functions when introducing JS or CSS assets into a theme to follow best practice, however in this case the need for conditional comments has meant that I’ve had to stick with the old fashioned way. Until this week…
Enter wp_script_add_data() ! This function exists for adding metadata to a script. It accepts three arguments: handle, key and value. You can find the function documentation on the Code Reference. Another gem that I had absolutely no idea about!
The handle is the unique ID you assign to the script when registering and/or enqueuing e.g. legacy_ie.
The key relates to the type of metadata you’re adding and from what I can see conditional is the only documented value available for use. This tells WordPress that the script in question should be enclosed within a conditional comment.
Finally, the value is the content (in this case at least) of the conditional itself e.g. lt IE 9 to detect all versions of IE lower than 9.
This meant I could remove the script from header.php and add the script The WordPress Way as shown in the Gist below.
As you can see we enqueue the script (no need to register unless it’s a dependency that needs to be referenced elsewhere) and then add our script meta to introduce the conditional comments before hooking into wp_enqueue_scripts to invoke the function.
The script will then be added to the header rather than the footer as the wp_enqueue_script() parameter $in_footer defaults to false if not supplied.
And there you have it, a way to introduce scripts wrapped in conditional comments into your theme without polluting your template files.
As I write this I’m sat in a cafe at Manchester Airport with m’colleague Kimb Jones before we board our flight to Vienna for WordCamp Europe 2016.
We’ve managed to find a great AirBnB in the area which means we have a great base for exploring the area and getting to the venue, plus we’re sharing the digs with Mr Steven “Stompweb” Jones who runs the WP North East meet-up and is a Proper Chap™.
The event has been looming for a while now, and I’m super excited now that it’s finally here. I had the privilege of attending WordCamp US 2015 in Philadelphia back in December and the sheer scale of that event was mind-blowing. It looks like WCEU is going to blow that right out of the water!
I missed out on last year’s WCEU due to client work (quite rightly) taking priority, but this year the event falls right at the end of what has been a really busy period for Make Do, so we can take advantage of a couple of relatively quiet weeks between projects to get onto the conference circuit once again.
For me personally it’s also an exciting WordCamp as I’ve actually signed up for my first ever Contributor Day: something i’ve always wanted to do but I just haven’t pulled my finger out to make it happen.
Hopefully I’ll be able to get onto the Accessibility team (my first choice) as WCAG compliance is something that I spend a lot of time on given my front-end responsibilities, and I’m really looking forward to learning from some of the stalwart members of the Accessibility team. It would also kick-ass if I could solve some problems and contribute some code in the process!
Speaking of accessibility, I highly recommend that you stop by Track 2 at 12:00pm to see Graham Armfield‘s demo of assistive technology. I saw a similar demo at WordCamp Edinburgh 2015 and it was a real eye-opener.
I’ve already been through the schedule and it looks like I’ll be in Tracks 1 & 2 almost exclusively depending on whether I go to the Unconference. Speaking of Unconference, I’m toying with the idea of submitting my WordPress Coding Standards lightning talk to spread the word as I have been doing at local meet-ups. We shall see!
There are so many familiar and new faces that I’m really looking forward to hanging out with at WCEU over coming days, it’s going to be a blast!
This week marked the end of support for legacy versions of Microsoft’s Internet Explorer, after it was announced that support for all but the most recent version (IE11) would be withdrawn from January 12th onwards. A patch was released on this date that will regularly nag users of these older browsers, asking them to upgrade.
Every single day since the beginning of January I’ve seen dozens of developers folk praising (and rightly so) this move by Microsoft. It’s a positive step in the right direction, no question.
It’s a sign that things are starting to change, and that one day, one day we’ll be able to liberate our front-end workflow and resulting code of all the various poly-fills, workarounds and practices that help make the websites and products we build look respectable in browsers like IE7/8/9 as well as IE10 to a much lesser degree. What it doesn’t mean is that we can down tools and forget about them.
I had something to say about this on Twitter:
If you're putting down your legacy IE browser polyfills and workarounds as of today, you really are doing it wrong.
When will our support requirements change? What should be driving this decision?
The problem is, there a lot of developers out there that are heralding the end of support for legacy versions of IE as the end of a lot of their woes: as if a Magical Front-end Unicorn has swooped in and transformed the landscape overnight. ***
In the long term the landscape will be different, but right now we (both site owners and developers alike) need to be looking not only at the wider trends that are widely reported throughout the year, but – as James alludes to in the above tweet – the actual data for the sites we own or are building for our clients to ensure that we’re not delivering a poor experience for these users.
Data published by leading authorities on browser trends (such as W3Counter, Browser Stats, StatCountern etc) and articles such as Sitepoint’s 2016 end of year review all confirm that Internet Explorer versions 6, 7, 8 and 9 still have a collective market share of approximately 3.5 – 5% of the desktop browser market. IE10 has a larger share, however this makes sense given that it’s the most recent of the browsers that are no longer supported.
Granted, 3.5 – 5% is a small percentage, but a small percentage of a whopping great number of users. These older versions of IE are still being used by millions of people, so we need to be making informed decisions based on the available data.
A note on the market share
Back on January 6th I posted something on Twitter about this which I thought summed up one of the big reasons why older IE browsers are still hanging onto this market share. Heather Burns fired back an interesting reply that is a perfect example of why the decision needs to be made based on the available data that shows exactly how users are accessing the site(s):
@davetgreen My NHS-oriented client sites are 25% 8/9/10, and until recently nearly all NHS use was 8.
Even if we, say, knock 10% off that figure to account for IE10, that’s still 15% of users that are accessing these sites via what many developers would consider to be a true legacy web browser.
The NHS is a great example of an organisation in one of the sectors I referenced in my earlier tweet that won’t be upgrading all users to IE11 overnight. Especially given the economic and bureaucratic issues they face when it comes to IT projects.
That patch I mentioned at the top of the post? It can be disabled by “enterprise” users: meaning any large organisation that has centralised control of software installed across a significant number of machines. There are hundreds of thousands (if not millions) of these organisations across the world accounting for many, many millions of users.
Make sure the pain is paid for
I, like many other web developers have become accustomed to catering for these older versions of Internet Explorer over the years. At both my former employer and at Make Do I’ve spent countless hours baking IE 7/8/9/10 support into boiler-plates that I’ve built to facilitate speedy and (relatively) hassle-free development.
As web developers we all know the pain that work to support these older browsers can cause. I’ve launched into expletive ridden, vitriolic rants about this work on more than one occasion, which is something of an understatement. We’ve all been that guy/girl on the edge, the computer programmer equivalent of Michael Douglas’ character holding the shotgun in Falling Down.
Granted, poly-fills have eased this pain a little, but it’s still painful and time consuming. Oh well, at least the client is paying for this support. Right? Right?!
Regardless of whether you’re working for an agency or as a freelancer, you should really be factoring legacy browser support into your quotes/proposals. If the client needs to support these older browsers then you need to be having a conversation about adding the required number of days at your usual day rate. Period.
Note: Don’t get me wrong, I’m still advocating that we look after these users, we just have to ensure that we as developers aren’t doing this for free.
If you or the agency you work for aren’t doing this, or you’re just throwing legacy browser support in as “part of the package” then you’re missing an opportunity to both increase your revenue and help contribute to the decline of the market share these browsers have.
Mark Wilkinson made an excellent point in response to a tweet of mine:
@davetgreen we must as developers charge for legacy support otherwise they will never go away
Quite right too. The web design/development community can help knock a few decimal points off those market share figures by making it clear that we won’t continue to offer support for free.
The increased cost of carrying out this work will (to a degree at least) lead to a decrease in support for these browsers when new websites and online products/services are launched. The result is that users of these older browsers will end up wanting the better, richer and more functional experience that comes with an upgrade and therefore a modern browser.
Furthermore, many frameworks,libraries and other resources that we include in our workflows are going to drop support in the coming weeks and months: some already have such as ReactJS dropping support for IE8 on the day support was withdrawn. This ultimately makes the task of providing support for older browsers using these kind of technologies more difficult as they continue to evolve, which is detrimental to the overall user experience.
Note: Naturally, progressive enhancement ensures we can still provide a usable, functional experience, even if that experience is considerably more “basic” than the “full fat” version.
Increased development costs combined with poorer user experiences should hopefully drive more organisations (directly) and users (indirectly) toward upgrading to the most recent version of Internet Explorer or indeed, other browsers like Firefox, Chrome, Safari or Opera.
The pace of decline in market share for these older versions of IE is going to speed up as a result of this patch and all the public relations surrounding the withdrawal of support. However, for all we know it could be another 12-18 months before it’s low enough to truly justify downing tools and abandoning practices. That said, I sincerely hope that I’m wrong and it drops off quickly!
*** The Magical Front-end Unicorn (MFU) has this power at its disposal, but chooses not to wield it. It’s the MFU Gotham deserves, but not the one it’s going to get right now.
When I attended WordCamp U.S last month, I tried to spend some time in the lightning talks track to mix things up a little bit.
One of the speakers on the second day was Morgan Estes, who gave a talk about taking the first step to becoming a WordPress contributor. I found his talk inspiring, and it really changed my personal perception of contributing.
I think it’s fair to say that there are plenty of others in the WordPress community who, like me, share the perception that contributing to WordPress as contributing code to core.
Contributing code to WordPress core is an itch I’ve been wanting to scratch properly for about the past twelve months. It’s actually in my list of development goals for 2016. That said, I have not, nor will I ever feel any pressure to make this happen. I’m content with the fact I’m doing great things with WordPress whilst working on client projects.
However, I’d really like to get more involved and share my own ideas (and code!) to help improve WordPress, so I can give back to the community of users that I’ve been a part of for nearly ten years in one way or another.
What Morgan made me realise that day was that I am giving something back, with my other contributions as an active member of the WordPress community.
For example, 2015 was the year I ventured into public speaking, delivering talks at couple of local WP meetups and two WordCamps. When I first decided to venture into speaking I had one goal: to help at least one person. From the discussions I’ve had these past nine months I know that my talks have helped at least a few dozen people, meaning I’ve already contributed something to WordPress and made a difference. Result!
I’ve now got the confidence to write and deliver more talks for the WordPress community, which is an ongoing commitment throughout 2016 and beyond. I may not be the best or the most experienced speaker in the world, but sharing my experiences and things I’ve learned is going to help others and that contribution means a lot to me.
Plugins is another area where I’m trying to give back. My first two plugins are now listed in the WordPress.org plugins directory, and I plan to continue writing plugins moving forward. This means I’m now committed to contributing code to the community. Granted, it’s not core code, but that doesn’t matter: my plugins are still going to help at least one person.
This is the best way to look at contributing. As Morgan said himself during his talk, it’s all about helping someone scratch the itch they have, or doing something that helps you scratch your own itch. The best thing is that quite a lot of the time, doing the latter also means you’re doing the former!
At Make Do (organisers of the WP Sheffield meetup), we’re really focused on increasing our contributions to WordPress in 2016. WordPress helps each of our team put dinner on the table every month as a result of our client work, so it’s important that we give back.
No matter what you’re doing: whether it’s translating WordPress, writing plugins, building themes, speaking at WordPress events, helping on the support forums, writing/updating documentation or even just dealing with WordPress questions/issues on Twitter you’re helping at least one person in the community.
And that is just as helpful and rewarding as each line of code you contribute to core. Plus, you stop people from scratching…