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 of your websites, set the php_value memory_limit variable in your php.ini file. For example, when importing large amounts of content, say months or years worth of blog posts, it’s likely you’ll hit this memory limit.
One amazing feature of WordPress is the built-in localizer. WordPress displays in English by default, but can easily be set to display any language that has been translated. Setting the WPLANG option triggers WordPress to load the specified language files:
The option value shown previously comprises the ISO-639 language code followed by the ISO-3166 country code. So en-GB would be English-Great Britain. This setting will reference your .mo and .po files for language translation.
You can also define the LANGDIR option. This option defines what directory will hold your language .mo files. By default, WordPress looks in wp-content/languages for the .mo file. If you would like to move this folder, just set the LANGDIR option like so:
WordPress will now look in the new location for your .mo files.
CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE are also very powerful options. They are useful if you want to have two or more individual WordPress installs use the same user accounts. Remember to set this prior to installing WordPress.
Setting these two options enables you to define the name of the default WordPress user and usermeta database tables. Doing this means both websites share user information including usernames, passwords, author bios, and so on. This is a great way to set up a new installation of WordPress but not lose sync with your current user accounts.
If you would like your users to have different roles on each WordPress install, but still share user accounts, don’t set the CUSTOM_USER_META_TABLE option. Everything stored in the user tables will stay the same, but everything else will be blog-specific (that is, user level, first and last name, and so on).
You can set multiple cookie options such as COOKIE_DOMAIN, COOKIEPATH, and SITECOOKIEPATH. These options are typically used in a WordPress Multisite installation utilizing subdomains for websites. This allows you to set the primary domain so cookies can be created and validated on all subdomains in the network.
Typically, you won’t need to use or change this option, but if you run into issues with cookies, this is the first place to check.
Since the inclusion of the automatic installer functionality for plugins and themes, as well as the automatic update process, you can set FTP settings directly in your wp-config.php file. This is only needed if your host is not configured to support the automatic install process. This is easily detectable because each time you try to install a plugin or theme you are asked for your FTP information.
To save your FTP information in WordPress, add the following options in your wp-config.php file:
Just enter your FTP username, password, and host with
