Using real cron for WordPress with WP CLI

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.

Five common WordPress patterns I avoid

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.

Preparing for WordPress 4.4 comment form changes

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 and the benefit of time

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.

Plugin dependencies in WordPress, a user’s perspective

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:

Intuition is ?

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:

  • check if your visitors browser supports Emoji, and,
  • asynchronously load the JavaScript to polyfill Emoji if the visitor’s browser requires it.