Backup of a WordPress plugin / theme directory.

I often think: I’m just gonna do this little thing before and then I continue doing that.

The last little thing spanned a couple of days. I needed to make a patch for WordPress and cross fingers after pleading to apply it.

I could be wrong, but some years ago it was considered best practice to have users of your plugin to store their customizations into the same plugin directory. Well, maybe nobody advised me to but nobody advised me against either. The point is that it looks really neat to make users store all the stuff related to your plugin in the same place where your plugin leaves.

Years ago, however, there was no problem. Whenever you wanted to install a new plugin or update an old one, you always needed to first download it to your PC and then to upload it to your remote site, into the ´/wp-content/´ directory, possibly by means of an FTP client. The process was repetitive and cumbersome, but exactly by virtue of that you did things orderly.

Always make a backup of the stuff you are going to replace.

That was the mantra. Even on toilet walls you could read it.

Then, the update now link appeared and it all changed, for better. No more nothing, just a simple click and … magically everything happened remotely. Really really good feature. But there was a problem. A no-feature became a feature (bug?). The magic update now functionality never makes a backup of what is gonna replace. Why? I really don’t know. It is still a mantra for me!

So, the last couple of days, I made a patch for WordPress 4.1 and submitted it minutes ago. It’s quite simple: Always make a backup of the stuff you are going to replace. Then a plugin / theme developer can access a backup of their previous stuff and transparently migrate the previous custom files to the new version. For example, from an activation hooked function:

{[ .example | 1.hilite(=php=) ]}

Disable Xdebug for PHPUnit

If you do not need Xdebug when running tests with PHPUnit, then you can disable it and run your tests much faster. However, it’s not easy for me to remember to disable Xdebug, so in my TestCase class I’ve overridden ´setUpBeforeClass´ and ´tearDownAfterClass´ like this:

{[ .xdebug | 1.hilite(=php=) ]}

That only toggles the backtrace, so the speed gain is less impressive, but for me is an acceptable trade-off.


I’ve added a new class to my framework, Ando_ErrorFactory.

Here I use it to make PHP trigger an E_CORE_ERROR:

{[ .example | 1.hilite(=php=) ]}

Notice that the lines starting with “PHP” belong to STDERR (redirected to STDOUT, controlled by the ´error_reporting´ call), while the rest belong to the real STDOUT.

The take away is that we forcefully triggered an E_CORE_ERROR (fact confirmed by the STDERR portion) and our shutdown handler was able to log it (fact confirmed by the STDOUT portion). Given that such an error is a non catchable shutdown error, there is no other way to get a look at it than from inside a shutdown handler.

Here is what happens when instead we forcefully trigger an E_RECOVERABLE_ERROR:

The presence of the ´– e n d –´ line in the output confirms, as expected, that E_RECOVERABLE_ERROR is not a shutdown error. Thanks to that, we had a chance to get to the backtrace from our non shutdown error handler, while the STDERR didn’t get written to because we signaled to PHP we successfully handled the error by returning ´true´. In fact, here is what would happen if we returned ´false´:

As you see, by returning ´false´, we told PHP that we didn’t successfully handle the error and to continue its default course, which in this case, being E_RECOVERABLE_ERROR a shutdown error by default, consisted in shutting down the script. As a confirmation, notice the absence of the ´– e n d –´ line in the output.

A fun fact I discovered while programming this class is that a fatal error is not necessarily a non-catchable shutdown error. In fact, both E_RECOVERABLE_ERROR and E_USER_ERROR are catchable shutdown errors. Likewise, E_PARSE, E_CORE_WARNING and E_COMPILE_WARNING are non catchable non shutdown errors. For each of these variations ErrorFactory has a corresponding method to return that set of errors.

{[ .example2 | 1.hilite(=php=) ]}

Note that the non_shutdown_error and shutdown_error handlers are included as a proof of concept. You are supposed to program yourself proper handlers, if and how you see fit. But you can certainly use them for testing something out, like I did above.