Inspired by Jonathan’s contribution anniversary post of a few days ago, I decided to look up when I received my first props in WordPress.
Coincidentally, I’m also a July props baby and received my first WordPress props thirteen years ago today, on July 11, 2011 (Australian time). It was for the second ticket I’d filed, #18018, and Andrew Nacin committed the patch I’d provided a few days later.
For WordPress site owners wishing to use real cron via a crontab job, it’s fairly common to see advice to use curl to request the site’s wp-cron.php file on a regular basis.
In the days before the WordPress CLI (WP-CLI), using the wp-cron.php file was the only technique available to site owners wishing to use real cron events.
I write quite opinionated front-end code. It’s one of the advantages of working in the industry for around twenty years, I know what does and doesn’t work. Working in a rapidly developing industry long term has taught me to be open-minded too, to listen to new ideas and to be prepared to adapt them. I’ve learnt the only constant is change.
That said, despite my opinions I dislike declaring something an anti-pattern or is considered harmful. If there was one function in WordPress I could rename, it would be doing_it_wrong.
The five common WordPress patterns that follow are five patterns I avoid when developing themes and plugins. Below I explain why I avoid them, I’d love to know which of these ideas work for others.
As detailed on the Make WordPress blog, the order of comment fields will change in WordPress 4.4, scheduled for a December 2015 release.
This may affect your theme if the comment form doesn’t use the typical layout of one field above the other.
Preparing your theme for the release of WordPress 4.4 will require your CSS allow for two version of the comment form: comment field last (current) and comment form first (future).
WordPress 4.2.3 has reminded me why being conservative with enhancements is a good thing. If a bug is committed, you lose the benefit of time to fix it.
WordPress 4.2.3 has broken some sites using shortcodes in HTML tag attributes. As part of a security fix, certain ways of doing this are no longer possible.
I had the pleasure of speaking at WordCamp Brisbane recently. The video and my slides are below, following the slides are links to the resources mentioned in my talk.
Ryan McCue has started a discussion around plugin dependencies in WordPress, Gary Pendergast has responded. Ryan thinks it needs to be solved, Gary doesn’t – but if he did, would solve it a different way.
As a user, I don’t want to be exposed to security issues in orphaned code.
Each of them go into some technical details, some of which I understand, others which go over this front-end developers head. I was going to leave the following as a comment on Gary’s post, but it strayed a little off topic so I decided to post it here:
Complaining about WordPress 4.2’s inline Emoji script is to complain about the biggest front end performance gain of the feature.
You see, that tiny script does two things:
I like a much reduced set of body classes when coding up a WordPress theme. Two template types, two main classes.
Oh, and I put it on the HTML element too. To call my coding opinionated is somewhat of an understatement.
I was discussing one click indieweb for WordPress with David Shanske on the IRC channel. The aim is to make it as easy as possible for a WordPress user – not a developer – to implement an indieweb site.
I’ve decided to put it up as a brain dump.
There are two aspects to consider: features and data attributes.
