Back to Top

Ten Useful WordPress Constants You Might Love

Previous Post:

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_DEBUG, ABSPATH, or 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:

  1. // CONSTANT_NAME must be in upper case.
  2. define('CONSTANT_NAME', 'value');
// CONSTANT_NAME must be in upper case.
define('CONSTANT_NAME', 'value');

With that in mind, let’s move on to the actual list:

#1 WP_MEMORY_LIMIT

Defined in /wp-includes/default-constants.php.

(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.

Example codes:

  1. define('WP_MEMORY_LIMIT', '128M');
  2. // OR (use one of them, not both)
  3. define('WP_MEMORY_LIMIT', '256M');
define('WP_MEMORY_LIMIT', '128M');
// OR (use one of them, not both)
define('WP_MEMORY_LIMIT', '256M');

#2 WP_USE_THEMES

Defined in /index.php.

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:

  1. // The next line is commented out to tell WP to not load theme
  2. //define('WP_USE_THEMES', true);
  3. /** Loads the WordPress Environment and Template */
  4. require('./wp-blog-header.php');
  5. // Fake a 200 OK status header
  6. status_header(200);
  7. // Get first post's title from database using $wpdb object
  8. $title = $wpdb->get_var('SELECT post_title FROM ' . $wpdb->posts . ' WHERE ID = 1');
  9. // Print output, no theme.
  10. 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));
// 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.

#3 COOKIE_DOMAIN

Defined in /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 COOKIE_DOMAIN to 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_DOMAIN to 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.

#4 WP_DEBUG_DISPLAY

Used (but not defined) in /wp-includes/load.php.

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:

  1. define('WP_DEBUG_DISPLAY', true);
define('WP_DEBUG_DISPLAY', true);

#5 WP_DEBUG_LOG

Used (but not defined) in /wp-includes/default-constants.php.

(Yet another 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 .

By defining 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.)

#6 DISABLE_WP_CRON

Defined in /wp-cron.php.

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.

Example codes:

  1. define('DISABLE_WP_CRON', true);
define('DISABLE_WP_CRON', true);

#7 TEMPLATEPATH

Defined in /wp-includes/default-constants.php.

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 custom.css, comments.php, etc.) or carry out some tasks when they do. For example:

  1. // If the template file exists
  2. if (file_exists(TEMPLATEPATH . '/comments.php'))
  3. // do something useful
// If the template file exists
if (file_exists(TEMPLATEPATH . '/comments.php'))
// do something useful

Note that TEMPLATEPATH refers to the parent theme’s directory7. In case you’re developing a child theme, you should use STYLESHEETPATH (described below) instead8.

#8 STYLESHEETPATH

Defined in /wp-includes/default-constants.php.

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 themes/my-twentyeleven, while TEMPLATEPATH will refer to themes/twentyeleven.

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.

Notes: TEMPLATEPATH and STYLESHEETPATH do not have a trailingslash (i.e. /), so it is recommended that you use trailingslashit along with these two constants.

#9 AUTOSAVE_INTERVAL

Defined in /wp-includes/default-constants.php.

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.)

Example codes:

  1. define('AUTOSAVE_INTERVAL', 120);
define('AUTOSAVE_INTERVAL', 120);

#10 WP_POST_REVISIONS

Defined in /wp-includes/default-constants.php.

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.:

  1. define('WP_POST_REVISIONS', false);
  2. // OR, the number of revisions of your choice
  3. define('WP_POST_REVISIONS', 2);
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!

References

  1. http://codex.wordpress.org/Create_A_Network []
  2. 6-wordpress-memory-usage/ []
  3. http://codex.wordpress.org/WordPress_Cookies []
  4. http://code.google.com/speed/page-speed/docs/request.ht ... lessDomain []
  5. http://www.php.net/manual/en/ini.list.php [] []
  6. http://www.php.net/manual/en/function.error-reporting.p ... orting.php []
  7. http://codex.wordpress.org/Child_Themes []
  8. wordpress-tips/correct-theme-path-for-child-themes/ []
  9. http://codex.wordpress.org/Revision_Management []
  10. http://wordpress.org/about/philosophy/#decisions []
  11. http://phpxref.ftwr.co.uk/wordpress/nav.html?_constants ... index.html []
Elegant Themes - Designed with Modest Elegance
Print Article Trackback Trackback to this Article   Subscribe to Comments RSS Subscribe to Comments RSS

9 Opinions for Ten Useful WordPress Constants You Might Love (4 Trackbacks)

  1. User's Gravatar
    1
    IWT July 28, 2011 at 5:06 pm – Permalink

    Multipurpose collection shared..I am very happy to read this article..thanks for giving us nice information . Fantastic walk-through. I appreciate this post.
    And also the 10 WordPress variable are very helpful.

  2. User's Gravatar
    2
    Bob Miller November 5, 2011 at 12:26 am – Permalink

    I love this list, and every component in it. Having said that, my favourite thing about WP is Akismet. Anything that battles spam has to be awesome, right?

  3. User's Gravatar
    3
    Swashata July 9, 2012 at 2:22 am – Permalink

    Very nice article :)
    One thing I would like to say “A WordPress constant is simply a variable that…” is kinda wrong in literal meaning. Constants can not be a variable ;) Better if we address it like “constant is simply an identifier or name…”

    Also don’t you think WP_MEMORY_LIMIT is deprecated? As it does it automatically now!

  4. User's Gravatar
    8
    Rudd March 24, 2013 at 3:34 am – Permalink

    Thanks for sharing this. I only familiar or have heard some of these. I believe not so many blogs have explained more about this topics.

  5. User's Gravatar
    9
    Raso January 7, 2014 at 6:08 pm – Permalink

    Nice compilation. I have got list of constants from http://www.techflirt.com/blog/wordpress/wordpress-constants-list.html and got here more description.

  1. My Favorite wp-config.php Tips and Tricks - ManageWP

    [...] BetterWP.net’s “Ten Useful WordPress Constants You Might Love” [...]

  2. My Favorite wp-config.php Tips and Tricks | Talking Wordpress

    [...] BetterWP.net’s “Ten Useful WordPress Constants You Might Love” [...]

  3. My Favorite wp-config.php Tips and Tricks – ManageWP : Atom Wire

    [...] BetterWP.net’s “Ten Useful WordPress Constants You Might Love” [...]

  4. wp-config tip and trick

    [...] BetterWP.net’s “Ten Useful WordPress Constants You Might Love” [...]

Speak Up Your Mind!

An asterisk (*) indicates a required field and must be filled.




  • Web page and e-mail addresses turn into links automatically.
  • Wrap codes in: <code lang=""></code> or <pre lang="" extra="">
  • Lines and paragraphs break automatically.

Next Post: