Professional WordPress. Design and Development. Brad Williams

this option is not defined, it defaults to false and error messages are not displayed. Remember to disable or remove this option when you are done debugging because error messages might help hackers find vulnerabilities in your website.

      NOTE We recommend that you always keep WP_DEBUG enabled when developing in WordPress to address any warnings or errors that might be displayed.

Advanced wp-config.php Options

      You can set additional advanced options in your wp-config.php file. These options are not in the wp-config.php file by default so you will need to manually add them to the file.

      To set your WordPress address and blog address, use the following two options:

      The WP_SITEURL option allows you to temporarily change the WordPress site URL. This does not alter the database option value for siteurl, but instead temporarily changes the value. If this option is removed, WordPress reverts back to using the siteurl database setting. The WP_HOME option works the exact same way, letting you temporarily change the home value for WordPress. Both values should include the full URL including http://.

      NOTE This is a useful technique if you are building a WordPress website under a temporary development URL, such as new.example.com . You can simply remove these two options when you go live and WordPress will load using the production URL instead.

      WordPress version 3.7 introduced automatic background updates for WordPress. By default, only minor releases (for example, 4.1.x, 4.2.x, and so on) are updated automatically. There are currently four types of automatic background updates:

      ● Core updates

      ● Plugin updates

      ● Theme updates

      ● Translation file updates

      To completely disable all automatic updates, which includes all four types just listed, you’ll set the AUTOMATIC_UPDATER_DISABLED constant to true, as shown here:

      Alternately, you can enable automatic updates for major releases and development purposes. Using the WP_AUTO_UPDATE_CORE constant, you can define auto updates in one of three ways:

      ● true – Major, minor, and development automatic updates are all enabled.

      ● false – Major, minor, and development automatic updates are all disabled.

      ● minor – Minor updates are enabled. Major and development updates are disabled.

      As an example, let’s look at the various ways you can configure the automatic update settings:

      For more information on configuring WordPress automatic updates, visit http://codex.wordpress.org/Configuring_Automatic_Background_Updates.

      WordPress also features an option that allows you to move the wp-content directory. The two required options are:

      The WP_CONTENT_DIR option value is the full local path to your wp-content directory. The WP_CONTENT_URL is the full URI of this directory. Optionally, you can set the path to your plugins directory like so:

      WP_PLUGIN_DIR and WP_PLUGIN_URL are options used by developers to determine where your plugin folder resides. If a developer is not using these constants, there is a very good chance their code will break if you move your wp-content directory. Never move the wp-content directory on your production server without first testing in a development environment.

      As with the wp-content and plugin directories, you can also move the uploads directory in WordPress. This directory is where WordPress stores all files uploaded through the WordPress dashboard. To set a custom location for the uploads directory, you’ll use the UPLOADS constant shown here:

      The uploads directory must exist within the directory containing your WordPress core files or a subdirectory within and cannot exist outside of the WordPress folder structure.

      WordPress saves post revisions for each saved edit made to a post or page. Edits are saved by clicking either the Save or Publish button, and also by the built-in auto-save feature of WordPress. Imagine if each post you create has 10 revisions. If you had 100 posts, that would be 1,000 records in your database. This can quickly increase the size of your database and may even slow down your website because table records can take longer to fetch in larger databases. Luckily, WordPress has a built-in post revisions option called WP_POST_REVISIONS. You can set this option to false to completely disable post revisions altogether, or you can specify a maximum number of revisions to keep for each post or page. Following are examples of both scenarios:

      You can also configure the auto-save interval by setting the AUTOSAVE_INTERVAL option. WordPress uses AJAX when editing a post to auto-save revisions. By default, this interval is 60 seconds. You can set the interval in seconds for auto-save in wp-config.php. Set auto-save to 5 minutes by using this code:

      A great debugging option is SAVEQUERIES. Activating this option saves all database queries into a global array that can be displayed on your page. This can help you debug query issues, and also to see exactly what WordPress is executing on each page load. If you are working on a theme or plugin, and can’t seem to get the right set of posts back, this debug option will show you exactly what WordPress is asking for out of the database. Enable this option by setting the value to true:

      To display the query array in your theme, add the following code to any theme template file to view:

      The preceding code displays the saved query array only if the logged-in user has the ability to manage options, essentially locking it down so only site administrators will see the output. Themes and template files are covered in Chapter 9.

      You can also enable logging directly from your wp-config.php file. To enable logging, first you need to create a php_error.log file and upload it to your root WordPress directory. Then simply turn on the log_errors PHP option and point to your logging file:

      All errors will now be logged to this file. This will also log any errors produced by enabling the WP_DEBUG option discussed earlier. In the preceding example display_errors is set to Off, which is perfect for a production website because you don’t want error messages displayed. If you are debugging and want to view errors in real time, just set that option to On. Remember the error_log value is relative to the web server’s document root, not the WordPress root.

      You can also set the memory limit WordPress is allowed to use with the WP_MEMORY_LIMIT option. If your website hits the memory limit set for WordPress to run, you will see the error “Allowed memory size of xxxxx bytes exhausted.” Increasing the memory limit fixes this problem. The memory limit is set by defining the megabytes needed:

      Setting this option only works if your hosting company allows it. Some hosting companies will not allow you to dynamically change the memory limit and will have this value set very low. This problem is usually found on lower-cost hosting companies that maintain their price points by packing more web server instances onto a single physical host, creating contention for memory footprint.

      This increases the memory only for WordPress and not other applications running on your server. To increase the memory limit across all