Practical - WP Realm

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!

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

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

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

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 »

Yes, You Can: Plugin Auto-Updates From Github

It's been a question that has puzzled WordPress plugin developers from centuries - can you auto-update plugins from Github? The answer is in: yes, you can. Nuno takes a look at how it's done.

One of the things I love about WordPress is the plugin architecture, as it allows users to contribute and extend WordPress without compromising the sanity and clarity of its core.

Whenever I write a plugin I tend to submit it to the official plugin repo, where it can quickly be downloaded and used by thousands of savvy users. I also often host my plugins on GitHub too; either because I’m still developing them and I’m not quite ready to release them to the world or simply because it might be a client-specific or commercial plugin. In those cases I always feel shorthanded when I see other plugins receive new update notifications and the ones on GitHub have to be updated manually. Keep reading »

WordPress in Your Audience’s Language: Why?

Our very first guest author, Milan Dinić, argues in favor of not just installing WordPress in English and leave it at that. There are many reasons to tend to your audience's language, beyond the translation of strings.

In today’s software, the default language is usually English, which in turn encourages people outside English speaking countries to start using that software as-is, even when localized versions exist. They simply stick with the English version, since they themselves have grown used to it and the localized version ends up feeling “strange” to them. It comes as no surprise that this applies to WordPress as well. Many site administrators, even though English is not their native language nor do they publish in English, still use the default, English version.

However, a localized version of WordPress has a lot more than meets the eye, i.e. the translation of strings, such as local settings and formatting, a few of which I will present here: