Dave Jesch

WordPress makes use of a number of constants to control its behavior. Below, I’ve listed a number of these and how they are used within the WordPress system – along with reasons why you might changes their values to customize how your web site behaves.

What are Constants?

Many programming languages have the concept of a constant. This is like a variable, but once set it’s value never changes — making it a constant. You can go here for more information on defining Constants in PHP.

Where are They Used?

Constants can be used almost anywhere. However, they are most often declared early on in the processing of a PHP script. The reason for this is that if they’re not you may need to check to make sure if the constant exists before using it. This is easily done using the defined() function. An example of this can be found below.

WordPress declares most of its constants in the wp-config.php file. You can declare a constant in a plugin, which is loaded much later on in the WordPress bootstrap process, but if you do that you should definitely check to see if the constant has already been declared. Once declared, you cannot change the value of a constant — this is what makes them constant.

Why Would You Use Constants?

Using constants, you can reduce your plugin footprint. Since many parts of the WordPress core code make use of these, it can reduce the amount of code you need to write for some operations.

Constants are great for optimization. They can significantly increase speed as well as security.

Cautions

Only use constants if you have a good idea of what you’re doing and can properly keep track of changes to the Codex with new releases of WordPress.

Some constants may change when new major version upgrades are made.

WordPress Constants

Here are some of the constants and how they are used. There are probably a few that I missed. I’ll add to this as I find more.

Security Constants

These constants are declared in wp-config.php and are required for the normal operation of WordPress. All of these constants are 64 character random strings and are used for hashes, nonces and other security purposes. Each installation of WordPress should use different strings to ensure that your site is harder to “hack.” If you haven’t already changed your security keys, you can use WordPress’s online security key generator.

• AUTH_KEY — Used for authenticating a user and setting cookies.
• SECURE_AUTH_KEY — Used for authenticating a user and setting cookies under the https protocol.
• LOGGED_IN_KEY — Used for marking a user’s cookie data as logged in.
• NONCE_KEY — Used for creating Nonces, which are used as one-time values to ensure that humans are entering data in forms.
• AUTH_SALT — Used to “salt” the authentication data. Salts are random data added to passwords, keys and other data to make them harder to guess.
• SECURE_AUTH_SALT — Used to “salt” the secure authentication data.
• LOGGED_IN_SALT — Used to “salt” the logged in cookie data.
• NONCE_SALT — Used to “salt” the nonce data.

Database Constants

These are used to declare your database connection information. If you ever need to change your database password or location, you can effect this by editing your wp-config.php file and change these values:

• DB_NAME — The name of your database.
• DB_USER — The user name for your database connection.
• DB_PASSWORD — The password for your database connection.
• DB_HOST — The host name, or computer name where your database server is located.
• DB_CHARSET — The character set used when creating tables in your database. Unless you have a specific requirement for something else, this should have a value of ‘utf8′.
• DB_COLLATE — The collation (sorting) type to use for indexed data in your tables. This should be left empty unless you have a specific requirement otherwise.

Other wp-config.php Constants

These are the last few constants that are normally declared in wp-config.php:

• COOKIE_DOMAIN — Specifies the domain set in cookies for those with unusual domain configurations. This can help to prevent cookies being sent with requests for static content. Example: define(‘COOKIE_DOMAIN’, ‘www.staticdomain.com’);.
• WP_DEBUG — Sets WordPress’s “debug” mode on or off. Normally, this is set to false. Changing it to define(‘WP_DEBUG’, true); will turn on debug mode. This can be useful if you need to track down errors.
• WP_HOME — This overrides the configuration setting for the home url, but doesn’t change it permanently. This should include the http:// prefix, as in: define(‘WP_HOME’, ‘http://domain.com/optionalsubdirectory’);.
• WP_SITEURL — Declares the site’s URL. This defines the address where your WordPress code files reside. It should include the http:// prefix. An example would be: define(‘WP_SITEURL’, ‘http://mydomain.com’);.
• WPLANG — Used to localize your WordPress install. This should be left empty for a default language of American English. If you need to localize your WordPress installation, you need to change this and install a corresponding MO file for your language. For example, changing this to: define (‘WPLANG’, ‘de_DE’); will set your language to German.

Default Constants

These values are declared in the wp-includes/default-constants.php file. You to change these settings, add them to your wp-config.php file so they are declared before the wp-includes/default-constants.php file is loaded.

• ADMIN_COOKIE_PATH — Sets the cookie path for admin-based cookies. If not already defined, this will take the value: define(‘ADMIN_COOKIE_PATH’, SITECOOKIEPATH . ‘wp-admin’);
• FORCE_SSL_ADMIN — Enforces the use of SSL for Admin access. Normally, this is disabled. To force SSL for all Admin pages, you can: define(‘FORCE_SSL_ADMIN’, true);
• FORCE_SSL_LOGIN — Enforces the use of SSL for site logins. Normally, this is disabled. To force SSL for login requests, you can: define(‘FORCE_SSL_LOGIN’, true);
• SITECOOKIEPATH — Sets the cookie path for normal site cookies. If not set, this will take the value define(‘SITECOOKIEPATH’, preg_replace(‘|https?://[^/]+|i’, ”, get_option(‘siteurl’) . ‘/’ ) );
• WP_CONTENT_DIR — Sets the name of the content directory. Normally, this is ‘wp-content’. To change this, you can: define(‘WP_CONTENT_DIR’, ‘mycontentdirectory’); This can also be obtained by using plugin_dir_path()
• WP_CONTENT_URL — Sets the URL for the content directory references. if you change the WP_CONTENT_DIR, you will also need to change this to match the directory name for http requests.
• WP_DEBUG_DISPLAY — Controls display of errors. The default is to use the display_errors setting and not force errors to be displayed. To force errors to display, you can: define(‘WP_DEBUG_DISPLAY’, true);
• WP_DEBUG_LOG — Controls error logging to the file wp-content/debug.log. The default is no logging. To change this, you can: define(‘WP_DEBUG_LOG’, true);
• WP_DEFAULT_THEME — Sets the default theme. The current version of WordPress assumes a default theme of ‘twentyeleven’. If you want to change this, you can: define(‘WP_DEFAULT_THEME’, ‘mydefaulttheme’);
• WP_PLUGIN_DIR — Sets the directory for plugin files. The default is ‘plugins’. To change this, you can: define(‘WP_PLUGIN_DIR’, ‘/newplugindir’);
• WP_PLUGIN_URL — Sets the URL for the plugin directory. If you change the WP_PLUGIN_DIR, you will also need to change this to match the directory name for http requests. If you have compatibility issues with some plugins, you can set an additional value, as in: define(‘PLUGINDIR’, ‘/wpdir/wp-content/plugins’);.
• WPMU_PLUGIN_DIR — Sets the directory to store the Must Use plugins. The default location is /mu-plugins. To change this, you can: define(‘WPMU_PLUGIN_DIR’, ‘/requiredplugins’);
• WPMU_PLUGIN_URL — Sets the URL for the Must Use plugin directory. If you change the WPMU_PLUGIN_DIR, you will also need to change this to match the directory name for http requests.

Capability Settings

These can be used to control certain behaviors that users are allowed to perform. Some of these are confusing because you are turning “on” the ability to “disallow” a feature. So be careful on how you’re declaring these values. Most of these are used in the wp-includes/capabilities.php file, but if you want to change the settings, you should add your settings to your wp-config.php file.

• ALLOW_UNFILTERED_UPLOADS — Allows unfiltered uploads. You can: define(‘ALLOW_UNFILTERED_UPLOADS’, true); to enable users to upload files without filtering. Be careful: this is a potential security risk.
• DISALLOW_FILE_EDIT — Allows users to edit theme and plugin files. If you do not want your users to be able to edit these files, you can change this: define(‘DISALLOW_FILE_EDIT’, true);
• DISALLOW_FILE_MODS — Allows users to update theme and plugin files via the WordPress Repository. If you do not want your users to be able to update their WordPress install, you can change this: define(‘DISALLOW_FILE_MODS’, true);
• DISALLOW_UNFILTERED_HTML — Disables the ability to allow unfiltered HTML. Using define(‘DISALLOW_UNFILTERED_HTML’, false); will turn off the ability to allow unfiltered HTML.
• WP_CACHE — Enables the built-in WordPress caching capability. If you want to enable this caching, you can: define(‘WP_CACHE’, true);
• WP_USE_THEMES — Declared in /index.php. Tells WordPress whether or not use load it’s template engine. If you want access to WordPress APIs but don’t want or need the overhead of the template engine, define this to false: define(‘WP_USE_THEMES’, false);

Script Control

These settings control how scripts (Javascript and CSS) are handled by the system.

• COMPRESS_CSS — Compresses CSS. To enable CSS compression, you can: define(‘COMPRESS_CSS’, true);
• COMPRESS_SCRIPTS — Compresses scripts. To enable compression, you can: define(‘COMPRESS_SCRIPTS’, true);
• CONCATENATE_SCRIPTS — Concatenates Javascript and CSS files. To enable, you can define(‘CONCATENATE_SCRIPTS’, true);
• ENFORCE_GZIP — Forces gzip for compressoin of data sent to browsers. The default setting is to use the mod_deflate Apache module. If your host does not have this installed, you can: SCRIPT_DEBUG — Include the development (or non-minified) versions of all Javascript and CSS files. It also disabled compression and concatenation. To enable, you can: define(‘SCRIPT_DEBUG’, true);

Optimization Settings

These values can be used to control and optimize your WordPress install.

• AUTOSAVE_INTERVAL — Sets the interval for saving revisions while editing posts.
• CORE_UPGRADE_SKIP_NEW_BUNDLED — Enables skipping of theme and plugin updates when upgrading WordPress.
• DOING_AJAX — Set to TRUE when processing an AJAX request.
• EMPTY_TRASH_DAYS — Sets the number of days before trashed items are removed.
• IMAGE_EDIT_OVERWRITE — Allows overwriting images when editing them.
• MEDIA_TRASH — Enables the trash function for Media files.
• WP_MEMORY_LIMIT — Sets the memory limit used.
• WP_MAX_MEMORY_LIMIT — Controls the maximum memory size used. Some WordPress processes require more memory. This setting controls the upper limit used by these high memory use procedures.
• SHORTINIT — Turns on only the core WordPress functions. Often used when interfacing to other platforms.
• WP_POST_REVISIONS — Sets the maximum number of revisions to save. If set to FALSE it will be unlimited, an integer set the maximum number of revisions to save.

MultiSite Settings

These values control how WordPress MultiSite behaves.

• NOBLOGREDIRECT — Sets the URL to redirect visitors to when they request a non-existent MultiSite blog. The default is ‘%siteurl%’, which is the default site. If you wish to use a different location, you can: define(‘NOBLOGREDIRECT’, ‘mynewdomain.com’);
• WP_ALLOW_MULTISITE — Turns on MultiSite. Just enabling this using define(‘WP_ALLOW_MULTISITE’, true); does not by itself make your WordPress install a MultiSite install. It just starts the process. When you add this to your wp-config.php file, it turns on the Network menu in the Admin. This allows you to make certain choices and continue the setup process for your MultiSite install.
• WPMU_ACCEL_REDIRECT — When using Apache X-Sendfile for quicker loading, this helps you turn it on natively in WordPress for MultiSites. To enable, you can: define(‘WPMU_ACCEL_REDIRECT’, true);

Updated: May 4, 2012

To display the number of post views, you can add the following code to your functions.php file, or create a plugin add add it to your plugin source file.

define('DJ_POST_VIEW_COUNT', 'dj_post_view_count_meta');
function getPostViews($nPostId)
{
  $nCount = intval(get_post_meta($nPostId, DJ_POST_VIEW_COUNT, true));
  if ($nCount == 0)
  {
    delete_post_meta($nPostId, DJ_POST_VIEW_COUNT);
    add_post_meta($nPostId, DJ_POST_VIEW_COUNT, '0');
  }
  return ($nCount . ' View' . (($nCount == 1 ? '' : 's'));
}
function incrementPostViews($nPostId)
{
  $nCount = intval(get_post_meta($nPostId, DJ_POST_VIEW_COUNT, true));
  if ($nCount == 0)
  {
    delete_post_meta($nPostId, DJ_POST_VIEW_COUNT);
    add_post_meta($nPostId, DJ_POST_VIEW_COUNT, '1');
  } else {
    update_post_meta($nPostId, DJ_POST_VIEW_COUNT, ++$nCount);
  }
}

Then, in your single.php template file, add the following inside “the loop:”

// this adds to the post view count
incrementPostViews(get_the_ID());

Finally, wherever you want to display the counts, add this code:

// this displays the number of views for the current post
echo getPostViews(get_the_ID());

For the most part, I would say that code like this should be written into a WordPress plugin, rather than added to the functions.php file. However, since counting and displaying the number of views of a post is usually tightly integrated into the display of a post — which is the job of the theme, in this case it arguable as to whether or not it belongs in the functions.php file or a plugin. This is one of those situations where it just doesn’t matter all that much.

With just a little work, this could be turned into a plugin that would automatically add and display the post counts — without any changes to the theme files. Something like this could be added using the hooks provided in popular theme frameworks, such as Genesis or Thematic very easily. In that case, implementing this as a plugin would be the easier solution from a user perspective because there would be no changes to the theme files required at all.