WordPress wp-cli Kung-Fu Made Simple

WordPress wp-cli Kung-Fu Made Simple

Nuno has decided that he has created a project environment by hand one time too many, and explains how this process can be automated using a few wp-cli tricks.

With every new site or project, there comes a new WordPress install, and a few steps are needed before you can start to work. They usually involve one or more of the following:

  • download / update WordPress
  • create a new database and database user
  • set up Apache vhost
  • set up vhost url on system hosts file
  • install your favorite plugins
  • install a theme

This is a fairly simple process, which takes up a few minutes every time you start on a new project. However, since I like to automate things to decrease the chance of screwing up, and saving time, I’ve started to play around to see if I could somehow streamline this process. Keep reading »

Simple Comment Editing - A Review

Simple Comment Editing – A Review

Where Ryan reviews the  Simple Comment Editing plugin and welcomes the reduction in complexity and amount of code.

There is a new plugin in town and it is simply awesome. Many of you will have used the popular AJAX Edit Comments plugin for WordPress. It was created by Ronald Huereca back in 2007 and was very popular; it was unique in giving commenters on WordPress sites the ability to edit their own comments to make corrections.

I have always loved the concept of the plugin and had huge respect for the developer. Building a plugin to handle comment editing in this way was well beyond my capabilities at the time. I could never bring myself to run it on my own sites, though: it included it’s own styling and added a lot of bloat to page loads which slowed things down. It looked out of place.

My respect for the plugin and it’s developer are actually part of the reason I ended up living in Norway. When I realised I needed a job, the first person I turned to was Ronald. He suggested I go work with him at Metronet in Norway, and a month later we were sharing a desk in the same office :)

Keep reading »

WordPress and DTAP

WordPress and DTAP

Floris discusses walking down the DTAP street and why it might be a good idea when developing professional WordPress projects.

Many companies I know use DTAP in their website development process. DTAP is an acronym for “Development, Testing, Acceptance and Production” and is used as a release management cycle in software development. If you are building complex websites – or rebuilding them – the use of a so called “DTAP street” is very useful. Over the past few years I’ve been working a lot with DTAP and WordPress, of course. Here’s my experiences and the choices I made.

A DTAP street

Using a DTAP street is all about managing the development and release of entirely new software or just for a newer release of the software already in production. When using a DTAP street in web development you are in fact using at least four environments and versions/copies of your website:
Keep reading »

WordPress Rewrite Rules, Human Made Core Style!

WordPress Rewrite Rules, Human Made Core Style!

Joe Hoyle from Human Made Ltd shares how they handle complex rewrite rules when dealing with Custom Post Types and Custom Taxonomies.

The WordPress rewrite system is an area many people struggle with when starting out. People not familiar with rewrite systems don’t necessarily understand what role they play and often developers who are used to using rewrite systems find WordPress’s implementation somewhat clunky.

When working on relatively complex WordPress projects, which have multiple custom taxonomies and combinations of post types, custom rewrite rules are likely to be needed. Keep reading »

Why you should stop your plugin from updating

Why you should stop your plugin from updating

Per Soderlind recently alerted me to a rather important security issue regarding plugins hosted outside of WordPress.org. All WordPress.org hosted plugins receive plugin updates from WordPress.org. Commercial plugins often add scripts to provide plugin updates from other sources*, but the vast majority of plugins simply go without automatic updates at all.

Now, imagine a scenario in which you create a custom plugin, but someone with malicious intent registers a plugin with the exact same name and slug as yours with the WordPress.org repository. It is conceivable that you or someone else working on the site could accidentally hit the “update” button and be immediately infected by a malicious plugin launched to attack your site from WordPress.org itself. Joost de Valk made use of this very mechanism for good back in 2010, when he forced an auto-upgrade on the BlogPress SEO plugin, but an evil person could potentially do the same thing in a more malicious way.

Thankfully there is a very easy to use work around for this problem as you can simply deactivate the auto-updates via some code kindly provided by Mark Jaquith, variants of which are posted below.

* Methods to add plugin update support from other sources include:

Debugging Tips for WordPress

Debugging Tips for WordPress

There comes a time for every developer when things break and it's time to set to debugging. Mario takes a look at different techniques you can use for plugins, themes, and servers.

Recently I’ve had several discussions with colleagues asking me for the debugging practices that I use. I try to constantly enhance my workflow, resources and improve the quality of my work by speeding up the process of narrowing down the possible reasons for a bug or a feature limitation. Speaking WordPress-wise, I’ll list a couple of things that I consider important. Some of them are more than obvious, but somehow people misuse them or forget about them at a moment of crisis (so to speak).

Before you start: always do backups. Debug your web application locally, test properly and ensure that everything is on set before deploying to the real server. Best practices teach that a local server -> staging/dev server -> production server is a good setup to prevent the obvious error of hitting the live website.

Keep reading »

Using PHP Closures in WordPress

Using PHP Closures in WordPress

There has been little discussion on the use of PHP Closures with WordPress code, how they can be used and when not to use them (< PHP 5.3 for example). The ability to create single-use callback functions can be very useful when developing in WordPress land, as it's very often one needs to run code via hooks and filters. Closures are very well suited here, as well as advancing your knowledge of PHP language features.

There has been little discussion on the use of PHP Closures with WordPress code, hopefully we will be able to spark some here! Before getting into the nitty-gritty, to make sure everyone is on the same page a quick explanation of a PHP Closure.

Anonymous functions, also known as closures, allow the creation of functions which have no specified name. They are most useful as the value of callback parameters, but they have many other uses.

php.net

Why Use Closures?

The ability to create single-use callback functions can be very useful when developing in WordPress land, as it’s very often one needs to run code via hooks and filters. At its simplest consider the following code: Keep reading »