Ten Useful WordPress Constants You Might Love
A WordPress constant is simply a variable that can not be changed once it is defined. As static as a constant is, it still plays an important role in controlling how your WordPress works.
If you are asked to name some WordPress constants, it would not be a surprise if you mention ones like
WP_LANG, because they are somewhat widely used. In this article, I will list and explain other useful constants that can actually give you some extra admin power.
Most constants listed below will be defined by WordPress if you don’t do that yourself. The safest place to define them is in
wp-config.php, where the three popular constants above are also defined. You will need one line for each definition, like so:
// CONSTANT_NAME must be in upper case. define('CONSTANT_NAME', 'value');
With that in mind, let’s move on to the actual list:
(New to memory limit? Check out this article on WordPress’s memory usage.)
By default, this constant will have a value of 32M, but if you enable Multi-site1, its value will be set to 64M instead. Most of the time you won’t have to set
WP_MEMORY_LIMIT yourself, but there are cases when changing it is a good idea.
For example, if your WordPress installation expects a lot of plugins in upcoming days, or you have just run into a memory usage issue2, you can try changing the limit to 128M or 256M. Of course this is not something I would actually recommend, but sometimes it is the only option.
define('WP_MEMORY_LIMIT', '128M'); // OR (use one of them, not both) define('WP_MEMORY_LIMIT', '256M');
This is one of the few WordPress constants that truly opens up a wide variety of possibilities for any developer. What it does is relatively simple, though: it tells WordPress whether or not to load the theme you’re using, which allows you to use all WordPress’s functionality for something that doesn’t look like WordPress at all!
For example, you can create a file named
index_non_wp.php and put this snippet in:
// The next line is commented out to tell WP to not load theme //define('WP_USE_THEMES', true); /** Loads the WordPress Environment and Template */ require('./wp-blog-header.php'); // Fake a 200 OK status header status_header(200); // Get first post's title from database using $wpdb object $title = $wpdb->get_var('SELECT post_title FROM ' . $wpdb->posts . ' WHERE ID = 1'); // Print output, no theme. echo sprintf('This is a non-WordPress page, but we can use all functionality provided by WordPress. For example, this is the title of the first post: <strong>%s</strong>', esc_html($title));
Now if you pay a visit to
http://yourdomain.com/index_no_theme.php, a plain page with some WordPress’s contents will be shown, with no styles, no images, and no markups at all! Needless to say, this certainly allows us to create any kinds of fake pages, with just any kinds of contents.
/wp-includes/default-constants.php (normal WP) and in
/wp-includes/ms-default-constants.php (Multi-site WP).
Simply speaking, a cookie is a small file that is stored in your visitors’ computers and it holds certain information about that visitor. In WordPress, such cookie can include name, email, and website (if that’s a commenter) or some hashes (if that’s a registered user)3.
There are some special occasions when this constant can be very useful, one of which is to serve media files from static domain4. And for a normal WordPress installation, such use of
COOKIE_DOMAIN is explained rather well here: http://codex.wordpress.org/Editing_wp-config.php#Set_Co ... kie_Domain.
If you’re using a Multi-site WordPress, there are other things that are worth mentioning:
- For a sub-folder installation, WordPress will set
FALSE, which means the cookie will be available to all sites within your domain, so if a visitor is a registered user or a previous commenter, he or she can comment on any website he or she wishes without having to login or type anthing.
- For a sub-domain installation, WordPress set
COOKIE_DOMAINto something like
.yourdomain.com, allowing the cookie to authenticate your visitors on any sub-domain. In this case, it won’t be easy to set up a static domain to serve media files for all sites within the network as suggested by WordPress, because there can be lot of sub-domains that need cookies to be created. To work around this, you can use a completely different domain, as suggested by Google.
- If you’re using a domain mapping plugin, such as WordPress MU Domain Mapping, do NOT define this constant yourself, just let the plugin handles it for you.
Used (but not defined) in
This constant is closely related to
WP_DEBUG, and can be useful in many cases. As a programmer, hunting for bugs is simply a task none should ignore, and by setting
WP_DEBUG to true, one can track down almost any kinds of bugs.
The problem is that not all hosts enable error displaying by default, so even if you define
WP_DEBUG as true, no errors will be shown at all. In other words, you must also enable the
display_errors PHP directive5, by setting its value to 1. You must also set an appropriate level of error reporting6, which is conveniently done by WordPress if
WP_DEBUG is defined.
So, if you enable
WP_DEBUG but still see nothing (assuming that your codes do have bugs), try define
WP_DEBUG_DISPLAY as true as well:
Used (but not defined) in
WP_DEBUG related constant, eh?)
In debugging, logging errors is even more important than getting them to show up, why? The reason is there are so many kinds of errors in PHP, and errors you see on one page doesn’t necessary mean that there aren’t others lurking around somewhere. This is especially true for errors that only show up at runtime because they depend on how your application runs .
WP_DEBUG_LOG as true, you are effectively configuring two PHP directives5, namely
log_errors, which enables error logging, and
error_log, which tells PHP where to store errors, if any.
By default PHP errors are stored in the same directory where the main PHP file lives. WIth this constant defined as true, the error log will be stored in
wp-content/debug.log (unfortunately, you can’t change where it is stored with this constant.)
A cron (or cron job) is like a background process that is used to accomplish certain tasks without delaying the output of your website. In case you don’t know, WordPress itself has one, and it uses either a HTTP POST request or a HTTP redirect to call the cron job.
While cron is very useful, the fact that it is called every single time a visitor pays a visit to your website might not be ideal, especially if any cron job has to do something very intensively, such as database writing, complicated calculations, etc. Your server will have to work hard to serve cron requests, and can in turn slow down your website noticeably.
There are other cases when you want to disable WP cron, for example when you want to serve contents from a direct PHP file (
WP_USE_THEMES, anyone?), or when you want to write an AJAX plugin without using
admin-ajax.php. Of course cron should be enabled most of the time, but if you can set up a Unix cron, you should consider disabling WP cron completely.
This constant is used to get the path to where your theme files are. A template path is something like
/home/username/public_html/wp-content/themes/your-theme/, and it is set by WordPress automatically, you should never define a different value for this one (just use and love it).
This constant is useful when you want to check if certain template files exist (such as
comments.php, etc.) or carry out some tasks when they do. For example:
// If the template file exists if (file_exists(TEMPLATEPATH . '/comments.php')) // do something useful
This constant is very similar to
TEMPLATEPATH, but it refers to the child theme’s directory (i.e. where the loaded
style.css is located). So for example you are developing a child theme based on a parent theme such as Twenty Eleven, the structure of the two themes will be like this:
/themes/ /themes/twentyeleven/ /themes/my-twentyeleven/
As you might have guessed,
STYLESHEETPATH will refer to
TEMPLATEPATH will refer to
You can also use this constant to check for file existence (or run tasks based on that), but this one is actually preferred over
TEMPLATEPATH in most situations, and the reason is described quite well in a tip I wrote earlier about how to choose the correct theme path for child themes.
STYLESHEETPATH do not have a trailingslash (i.e.
/), so it is recommended that you use trailingslashit along with these two constants.
Auto-saving is actually a very cool feature of WordPress, but sometimes it is not useful as it seems. By default WordPress auto-saves your post every minute, and I personally find this interval a little too short.
The bad thing is there’s no conventional way to disable auto-saving. You can only:
- Set a very high interval so that auto-saving never happens.
- Set an appropriate interval so that you feel comfortable with it.
For people who would like to disable auto-saving completely, you can try this plugin (I’m sort of an anti-plugin user, so I will just set
AUTOSAVE_INTERVAL to something I prefer.)
Post revisions in WordPress9 can be considered one the most annoying features, not only it adds A LOT of entries to your database, but it can also be absolutely unnecessary sometimes. The post table has already been flooded with all kinds of contents (custom post types, nav menus, etc.) so why should we make it heavier by putting something that we might never actually use?
Of course post revision has its own purposes, but there should really be an option somewhere (no, a decision-based application10 is not that good) that let users conveniently choose if they want revision or not, and if they do, they can also choose how many revisions to keep.
Luckily you can set this constant to false to disable post revisions completely, or set it to a number to tell WordPress how many revisions it can keep, e.g.:
define('WP_POST_REVISIONS', false); // OR, the number of revisions of your choice define('WP_POST_REVISIONS', 2);
I understand that no one wants to fire up a code editor just to change something that is not code-related, but until there’s an option for post revisions (probably not),
WP_POST_REVISIONS is our only option (no, I don’t want to use any plugin for this task ;)).
So that’s it! I hope you guys enjoy this article, and don’t forget to check out a reference link below11 to see a full list of WordPress constants (as of 3.2.x branch). Till next time!
- http://codex.wordpress.org/Create_A_Network [↩]
- 6-wordpress-memory-usage/ [↩]
- http://codex.wordpress.org/WordPress_Cookies [↩]
- http://code.google.com/speed/page-speed/docs/request.ht ... lessDomain [↩]
- http://www.php.net/manual/en/ini.list.php [↩] [↩]
- http://www.php.net/manual/en/function.error-reporting.p ... orting.php [↩]
- http://codex.wordpress.org/Child_Themes [↩]
- wordpress-tips/correct-theme-path-for-child-themes/ [↩]
- http://codex.wordpress.org/Revision_Management [↩]
- http://wordpress.org/about/philosophy/#decisions [↩]
- http://phpxref.ftwr.co.uk/wordpress/nav.html?_constants ... index.html [↩]