Getting Started With Setup wp-config.php and add constants and define post rules
In this tutorial, you will be learning how to setup WordPress constants on the wp-config.php file.
What is constant? In PHP, a constant is a simple identifier that stands in for a value which can be defined programmatically. In all cases, Constants must remain constant and cannot change while an action or script is being executed.
Some rules before using constants:
1 – constants must begin with a letter or an underscore and by convention are capitalized.
2 – Constants are defined with the define() function which is a very simple function with two arguments. The first is the name of the constant and the second is the value.
Together it looks like this:
define( NAME_OF_CONSTANT, 'value' );
WordPress defines constants in various locations across the platform, in this tutorial we will be working with the ones defined in wp-includes/default-constants.php.
The first example is the code below the WP_DEBUG is print out on the wp-config.php has default but set to “false” which means that the WP_DEBUG constant is declared on the wp-config.php but not enabled.
Les check if the the WP_DEBUG constants is already defined.
if ( ! defined( 'WP_DEBUG' ) ) define( 'WP_DEBUG', false );
WordPress wp-config is loaded before of any WordPress core file therefore we can override the value set in the core by defining our own value.
If we set WP_DEBUG to “true” in wp-config.php, when default-constants is executed the definition in that will be skipped because
!defined( 'WP_DEBUG' )
will return false, thus overriding the default setting of false.
Setup wp-config.php and add constants and define post rules code snippet.
Changing the WordPress wp-config out of the WordPress root directory is considered a good security practise by many.
By moving wp-config.php it keeps the sensitive information, including your database login details and authentication keys away from being hackable from malware and other scripts that are looking to gain access on the wp-config.php default location.
WordPress will automatically look one level above the location of the directory WordPress itself is installed in. This means if WordPress is installed in our server’s webroot we can move wp-config up one level to a less easily accessed location.
If we move our wp-config elsewhere we can create a second wp-config file in the root directory pointing to the “real” wp-config.
define( 'ABSPATH', dirname(__FILE__) . '/' ); require_once( ABSPATH . '../path/to/wp-config.php' );
WordPress Must use plugins, as also known as “mu-plugins,” are plugins that run automatically on our site and cannot be disabled.
WordPress will look for a directory called “mu-plugins” in the content directory to load mu-plugins from.
We can change the directory for mu-plugins by defining WPMU_PLUGIN_URL, using the full URL of your custom mu-plugins folder, with a similar method to how WP_PLUGIN_URL was defined:
Getting the URL using PHP:
define( 'WPMU_PLUGIN_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/mu-plugins' );
We can also use this same method to rename the mu-plugins directory. If we want to keep it in the same location, but just rename it, we would set WPMU_PLUGIN_URLrelative to WP_CONTENT_URL
define( 'WPMU_PLUGIN_URL', WP_CONTENT_URL . '/new-name' );
Setting the default theme to that theme will save us a lot of repetitive work, whichever theme we decided to set as our default we set it by defining WP_DEFAULT_THEME to be that theme’s slug. For example, if we want to change the default theme back to Twenty Twelve:
define( 'WP_DEFAULT_THEME', 'twentytwelve' );
Keep in mind that the default theme is used as a safety fallback if the current theme is missing. Changing the default theme to another theme may remove the safety of falling back on the trusty WordPress Twenty-Something theme that you know will work.
The theme and plugin editors in the WordPress backend can be very helpful tools but they can also be a recipe for disaster.
define( 'DISALLOW_FILE_EDIT', true );
We can even take this one step further by setting DISALLOW_FILE_MODS to true to prevent not only the editing of themes and plugins but also the updating and installing plugins and themes, as well as updates to WordPress from being done via the WordPress admin area.
define( 'DISALLOW_FILE_MODS', true );
define( 'WPCOM_API_KEY','your-key' );
Please replace “your-key” with your actual Akismet key.
WordPress by default keeps a record of every change we make to a post’s content. This can be a lifesaver but if we save a lot of drafts this can create a lot of extra entries in our database.
You can limit the number of revisions to keep by setting the WP_POST_REVISIONS constant to a number. For example, to save 20 revisions you would use:
define( 'WP_POST_REVISIONS', 20 );
If you want to disable all revisions except the autosave, you can always set the WP_POST_REVISIONS constant to false, like this:
define( 'WP_POST_REVISIONS', false );
To prevent username and passwords from being intercepted when they are submitted by users while logging in to WordPress, we can require that wp-login can only be accessed via a secure connection.
We will need to have SSL cert for the site to use this option, which is enabled with FORCE_SSL_LOGIN.
define( 'FORCE_SSL_LOGIN', true );
We can take this one step further by requiring all interaction with the WordPress backend, including login, to occur via a secure connection by setting theFORCE_SSL_ADMIN constant to true.
define( 'FORCE_SSL_ADMIN', true );
Enabling debugging with the WP_DEBUG constant is one of the most common changes made to wp-config.
There are some other changes you can make in wp-config to change the behaviour of WordPress debugging mode. By default WP_DEBUG prints all error messages at the top of the screen. If we would like to suppress this behaviour you can setWP_DEBUG_DISPLAY to false.
define( 'WP_DEBUG_DISPLAY', false );
This will not prevent fatal errors from causing a white screen of death. It will, however, stop your site from broadcasting non-fatal error messages to the world, which not only looks bad but will usually expose the absolute directory path for your content directory to the world.
You can still see the errors in the error log unless of course, you set WP_DEBUG_LOG to false. When WP_DEBUG_LOG is set to true all debug messages will be logged to a file in your content directory called “debug.log”.
Thank you for seeing my tutorial and feel free to share and comment :). Do you have any interesting changes to your wp-config file that you make or some other cool use for a WordPress constant you’d like to share? Can you think of other interesting uses for constants that are not highlighted in this post? Let everyone know in the comments what cool tricks you’ve come up with or you can let me know by contacting me(here)
Read more about wp-config.php constants and rules here.