Changing URLs in WordPress MySQL Database

UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldurl', 'http://www.newurl') WHERE option_name = 'home' OR option_name = 'siteurl';

UPDATE wp_posts SET guid = replace(guid, 'http://www.oldurl','http://www.newurl');

UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldurl', 'http://www.newurl');

UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://www.oldurl','http://www.newurl');

This is a very common task when developing WordPress sites and there are loads of sites that show this query.

The problem is, I suffer from some kind of Google search blindness and it always takes a few tries to find the right page. Much easier to put it on my own site.

Testing WordPress Plugins

Testing your code is essential – especially if you are going to publish it somewhere like the WordPress Plugin Directory. It takes no time at all for someone to find it and politely (or not so politely) point out it’s flaws.

So how do you go about testing a plugin within a WordPress installation? Easy, install WordPress locally, copy it into the plugins folder and of you go.

Hang on, what if you want to test it in another version of WordPress? Install that version and copy the plugin into that one too. How do you now merge changes between the two versions of the plugin?

Use WinMerge, or even better, subversion or GIT .. oh but my version control files are neatly organised somewhere else…

You get the picture.

The solution is to use symbolic links. A single working copy of the plugin is used and symbolic links to it are created from the plugin directory of each WordPress install you want to test it in. The only limitation is that the files need to be on the same computer.

I use a local Debian web server for development, so the first step is get into the terminal and go to the directory where I want to create the symbolic link:

cd /var/www/wp/4.5.3/wp-content/plugins

Then use the ln command to create the link to the location of the plugin files:

ln -s /var/www/wordpress-svn/dmg-text-widget/tags/1.0/ dmg-text-widget

The final part of the above command is the name of the link, which is the plugin folder name ‘dmg-text-widget’ in this case.

Then do the same in any other versions of WordPress that you need to test in, e.g:

/var/www/wp/3.1/wp-content/plugins

/var/www/wp/3.9/wp-content/plugins

/var/www/wp/4.0.1/wp-content/plugins

You can also create symbolic links on a Windows host – see this article on How to Geek for more info – but I haven’t tested it on Windows.

 

Change error reporting during the execution of a class

It’s generally not a good idea to mess about with error reporting levels – just turn them on while developing and off in production.

However, I recently came across a situation where I wanted to suppress the error notices being generated while developing a particular class.

An autoloader class was generating notices while looking for files – a useful feature as it shows the paths where it wasn’t finding the files, so I didn’t want to change the source of the error notices.

Instead, the solution was to change the error reporting levels in the class using the autoloader using PHP’s error_reporting function. This function returns the previous error reporting level when called, allowing it to be set back later on.

The code:

function __construct( \PDO $db, $p = array() )
{
	// Change error reporting level
	$this->old_error_reporting_level = error_reporting( E_ERROR | E_WARNING | E_PARSE );
}

....

function __destruct()
{
	// Change error reporting level back
	error_reporting( $this->old_error_reporting_level );
}

Maybe someone else will find this useful!