Import single database from --all-databases dump

mysqldump output is just a set of SQL statements.

You can provide the desired database in the command line and skip the commands against the other databases using:

mysql -D mydatabase -o < dump.sql

This will only execute the commands when mydatabase is in use

You can add --disable-keys for avoid errors of foreign keys.

mysql -u user -D --disable-keys database -o <dump.sql

Get A List Of Registered Actions In WordPress

WordPress actions and filters is an event driven architecture that allow you to run specific code at certain times in your application. To do this WordPress uses two functions the add_action() to add new callback functions to an action, and the do_action() function which will run all the callback functions assigned to this action.

In a recent project I was testing some code that used AJAX to run an action in a WordPress plugin. The problem I was having was that this action wasn't being called when it should of been, because this was using AJAX I needed a way of finding out if the code that add the action was actually being ran.

So I needed a way of finding out if the action I add was registered with WordPress so it understood what code to run on this action.

Whenever you want to add an action to WordPress you need to use the function add_action(), the code underneath this will add a new element to an array called $wp_filter.

Then if you look at the function that runs the actions do_action() function this will search for the action in the same $wp_filter variable. Which means all the registered actions will be added to this array, so if you want to view what actions have been registered at a certain time in your code you simply have to print out the elements in this array.

global $wp_filter;

echo '<pre>';
print_r($wp_filter);
echo '</pre>';

Debugging In WordPress

Debugging your website is very important for any project, you will need to be able to debug your site in all the difference environments from local to live. But depending on the environment you will want to debug in different ways.

For example on your local environment you may want to output all PHP errors on the screen to make it easier to fix the problems, but you will not want any of these errors to be displayed on the screen in your live environment. You won't want to display these errors to the visitors of your website, but you will also want to catch these errors and store them in a place you can see what is going wrong.

The advantage of storing these errors allows you to come in at a later date and fix any errors that might be happening on your live site.

WordPress comes with a built in debugging system thats allows you to catch/display errors in any way you want, changing these settings in the wp-config.php file allows you to change how you debug in different environments.

WP_DEBUG

The WP_DEBUG is a PHP constant that allows you to put WordPress into debug mode, when WordPress is in debug mode it allows you to define if you want to output the error on the screen or into a debug log file.

If you want to turn on debug you need to add the following line in your wp-config.php file.

// Turn on wp_debug
define('WP_DEBUG', true);

// Turn off wp_debug
define('WP_DEBUG', false);

When WP_DEBUG is enabled it will override the default error_reporting settings in your php.ini file and change it to display all PHP errors, notices and warnings. Displaying errors will show problems that will break your code. Notices and warnings will display problems with the code that may not break the site but do not following correct PHP guidelines.

WP_DEBUG_LOG

If you want to log all the errors into a file so you can investigate them later then you should use the constant WP_DEBUG_LOG in your wp-config.php file. When this constant is set to true it will output all errors into a file debug.log which will be stored inside the wp-content folder.

define('WP_DEBUG_LOG', true);

WP_DEBUG_DISPLAY

By default the WordPress errors will be displayed on the screen, if you are just logging the errors in a debug.log file then you might want to turn off displaying the errors on the screen but setting the constant to false.

define('WP_DEBUG_DISPLAY', false);

SCRIPT_DEBUG

By default WordPress core will use minified versions of CSS and JS files, if you want to change this to make WordPress use the full dev version of the CSS and JS then you can set the SCRIPT_DEBUGvariable to true.

define('SCRIPT_DEBUG', true);

SAVEQUERIES

To debug database queries you can use this constant variable SAVEQUERIES, this will store each query that is made on the database and how long it takes to execute. Be aware that this can slow down your site so only make sure this is only turned on while debugging.

define('SAVEQUERIES', true);

To check on these queries you can access them in the global variable $wpdb.

echo '<pre>';
var_dump($wpdb->queries);
echo '</pre>';

Changing Debug Depending On Environment

Understanding what these different settings means that we can make sure that we only do certain things depending on the environment.

Dev In development environment you would want to turn on debugging, display them on the screen and store the errors in the debug file.

UAT In a UAT environment you would still want debug on but you won't want to display these on the screen so we can store them in the debug file.

Live In the Live environment you would of hopefully resolved all the errors in your code so you can turn off debugging.

To change this in the wp-config.php you can use the following code.

switch( $_SERVER['SERVER_NAME'])
{
    // Dev
    case 'dev.example.com':
        define('WP_DEBUG', true);
        define('WP_DEBUG_LOG', true);

        define('ENV', 'dev');
    break;
    
    // UAT
    case 'uat.example.com':
        define('WP_DEBUG', true);
        define('WP_DEBUG_LOG', true);
        define('WP_DEBUG_DISPLAY', false);

        define('ENV', 'uat');
    break;
    
    // Live
    case 'live.example.com':
        define('WP_DEBUG', false);

        define('ENV', 'live');
    break;
}