晓闻心雨

本文转载自WordPress啦！

WordPress用户都知道，wp-config.php 文件是WordPress数据库的关键。数据库名、用户名、密码、位置都是在此设置。

但是很多用户并不知道通过wp-config.php文件可以更改很多设置，提高WordPress站点的功能、性能、安全度。在这里，这里跟大家分享下使用wp-config.php的技巧。

数据库信息

WordPress链接数据库需设定以下四个值:

define(‘DB_NAME’, ‘database-name’);
define(‘DB_USER’, ‘database-username’);
define(‘DB_PASSWORD’, ‘database-password’);
define(‘DB_HOST’, ‘localhost’);

在创建数据库前就需准备好数据库名称、用户名、密码，最后一个DB_HOST值可能比较难获得，最常见的是直接用“localhost”， 甚至你可以给数据库服务器指定一个备用端口。例如：

define(‘DB_HOST’, ‘localhost:1234′);

define(‘DB_HOST’, ‘mysql.domain.tld:1234′);

还有一种更好的方法就是自动检测数据库服务器值：

define(‘DB_HOST’, $_ENV{DATABASE_SERVER});

如果上面所有方法都行不通，求助你的服务器提供商。

数据库字符集和整理(collation)

截至WordPress 2.2版，你可以给MySQL数据库指定字符集。一般来说，不需要修改默认字符集UTF-8，因为它支持所有的语言。注意，如果wp- config.php文件里，这一字符集已经存在，你只能使用此字符集。下面是默认的设置，也是我推荐大家使用的设置：

define(‘DB_CHARSET’, ‘utf8′);

WordPress 2.2 版本还可以指定collation（校勘/整理），对你的数据库字符集排序。Collation的设置通常由MySQL依据字符集自动处理的，在默认设置里的collation值保留空白就可以。默认的设置：

define(‘DB_COLLATE’, ”);

安全密匙

截至WordPress 2.7后有四个安全密匙来加密cookies。这些密匙只需让它默默无闻地工作就好，并尽可能随意和复杂（你无需记住）。生成这些密匙的最简单方法就是通 过WordPress官方密匙服务来自动生成。只要点击这个服务，复制并粘贴生成的结果到wp-config.php 文件中即可。注意，这些密匙可随时更改，这样一来，用户之前的cookies会被清除需要重新登陆你的网站。

define(‘AUTH_KEY’, ‘:dr+%/5V4sAUG-gg%aS*v;&xGhd%{YV)p:Qi?jXLq,<h\\`39′);
define(‘SECURE_AUTH_KEY’, ‘@*+S=8\”\’+\”}]<m#+}V)p:Qi?jXLq,<h\\`39m_(‘);
define(‘LOGGED_IN_KEY’, ‘S~AACm4h1;T^\”qW3_8Zv!Ji=y|)~5i63JI |Al[(<YS');
define('NONCE_KEY', 'k1+EOc-&w?hG8j84>6L9v\"6C89NH?ui{*3\\(t09mumL/fF');

数据库前缀

数据库前缀的设置对提高你的站点安全以及在同一数据库中安装多个WordPress站点都非常有用，通过改变默认值“wp_” 为随机独一的值，可减轻站点受攻击的可能性，总体上提高你的网站安全性。下面是默认值：

$table_prefix = 'wp_';

有很多攻击者就是对准这些默认前缀的数据库进行攻击。稍微修改为如： “x777_”之类的可避免此类攻击。

你还可以使用此设置实现在一个数据库中安装多个WordPress站点，只要给每一个WordPress指定一个单独的数据库前缀即可：

$table_prefix = 'wp1_'; // 第一个博客
$table_prefix = 'wp2_'; // 第二个博客
$table_prefix = 'wp3_'; // 第三个博客

语言设置

WordPress可指定一个语言翻译文件及其相关的目录。语言翻译文件属于 “.mo” 这一类别，其默认位置是 (如果没有明确指定的路径) wp-content/languages (第一)和wp-includes/languages (第二)。下面是默认设置：

define('WPLANG', '');
define('LANGDIR', '');

目录设置

技术上来说，你不太需要关注它。默认的wp-config.php 文件里有几行指定绝对路径并且包含设置文件。我这里提出来，只是为了使这篇文章更完整些：

/** WordPress absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

博客地址和网站地址

默认的p-config.php中不包含这两个定义，不过为了改善WordPress的性能，还是需要添加的。这两个设置是在2.2版本引进来的。 在wp-config.php 中添加者两个定义可降低数据库查询数，提高网站的运行。这些设置需与你的WordPress Admin中的设置一致。下面是一个例子 (所有URL地址不以斜线结尾):

define('WP_HOME', 'http://digwp.com');
define('WP_SITEURL', 'http://digwp.com');

可以使用全局变量动态地设置这些值：

define('WP_HOME', 'http://'.$_SERVER['HTTP_HOST'].’/path/to/wordpress’);
define(‘WP_SITEURL’, ‘http://’.$_SERVER['HTTP_HOST'].’/path/to/wordpress’);

模板路径和样式表路径

设定好博客地址和网站地址后，你还可以通过剔除对模板路径和样式表路径的数据库查询，这样可提高站点的性能。下面是默认的值:

define(‘TEMPLATEPATH’, get_template_directory());
define(‘STYLESHEETPATH’, get_stylesheet_directory());

尽管数据库查询还存在，但我们可以减少多余的查询:

define(‘TEMPLATEPATH’, ‘/absolute/path/to/wp-content/themes/active-theme’);
define(‘STYLESHEETPATH’, ‘/absolute/path/to/wp-content/themes/active-theme’);

禁用缓存和缓存有效期

这两个都是针对旧版本的WordPress，还在使用默认的基于对象的缓存机制。第一个选项是启用或禁用缓存。第二个定义让你指定缓存的到期时间。
启用缓存

define(‘WP_CACHE’, true); // 启用缓存
define(‘ENABLE_CACHE’, true); // 启用缓存
define(‘CACHE_EXPIRATION_TIME’, 3600); // 单位秒

禁用缓存

define(‘WP_CACHE’, false); //禁用缓存
define(‘DISABLE_CACHE’, true); // 禁用缓存

指定cookies域

会由于很多原因你需要给站点指定cookies域。比较常见的就是阻止子域名上请求静态内容的cookies不必要的传输。这种情况下，你就可以使 用此定义告知WordPress只向非静态域发送cookies，这将会大大提高网站的性能。下面是设置各种cookies路径和域的信息：

define(‘COOKIE_DOMAIN’, ‘.digwp.com’); // 别漏了前面的’.'。
define(‘COOKIEPATH’, preg_replace(‘|https?://[^/]+|i’, ”, get_option(‘home’).’/'));
define(‘SITECOOKIEPATH’, preg_replace(‘|https?://[^/]+|i’, ”, get_option(‘siteurl’).’/'));
define(‘PLUGINS_COOKIE_PATH’, preg_replace(‘|https?://[^/]+|i’, ”, WP_PLUGIN_URL));
define(‘ADMIN_COOKIE_PATH’, SITECOOKIEPATH.’wp-admin’);

覆盖文件权限

如果你的虚拟主机默认文件权限非常严格，在WordPress配置文件里添加这些定义就可以解决这个问题。注意，数值不需要用引号引起来。下面是例子：

define(‘FS_CHMOD_FILE’, 0755);
define(‘FS_CHMOD_DIR’, 0755);

查看所有已定义的常量

需要查看所有已定义的常量吗？用下面的PHP函数就会得到一个所有当前一定义常数的数组：

print_r(@get_defined_constants());

自定义用户和usermeta 表

你也可以通过下面的定义自定义用户和usermeta表：

define(‘CUSTOM_USER_TABLE’, $table_prefix.’my_users’);
define(‘CUSTOM_USER_META_TABLE’, $table_prefix.’my_usermeta’);

FTP/SSH常量

这类定义是用于帮助用户定位和实现FTP/SSH连接。下面是例子:

define(‘FS_METHOD’, ‘ftpext’); // 文件系统的方式，包括： “direct”、”ssh”、”ftpext”和”ftpsockets”
define(‘FTP_BASE’, ‘/path/to/wordpress/’); // 安装根目录的绝对路径
define(‘FTP_CONTENT_DIR’, ‘/path/to/wordpress/wp-content/’); // 到”wp-content” 目录的绝对路径
define(‘FTP_PLUGIN_DIR ‘, ‘/path/to/wordpress/wp-content/plugins/’); // 到”wp-plugins” 目录的绝对路径
define(‘FTP_PUBKEY’, ‘/home/username/.ssh/id_rsa.pub’); // 到SSH公匙的绝对路径
define(‘FTP_PRIVKEY’, ‘/home/username/.ssh/id_rsa’); //到SSH密匙的绝对路径
define(‘FTP_USER’, ‘username’); // FTP 或SSH用户名
define(‘FTP_PASS’, ‘password’); // FTP用户密码
define(‘FTP_HOST’, ‘ftp.domain.tld:21′); //主机名:你的SSH/FTP服务器端口

移动wp-content 目录

从2.6版本开始，你可以修改wp-content目录的位置。这么做有几个理由，包括可提高网站的安全性，以及便于FTP更新。下面是例子：

// 当前目录的完全本地路径(结尾不包括斜杠)
define(‘WP_CONTENT_DIR’, $_SERVER['DOCUMENT_ROOT'].’/path/wp-content’);

// 当前目录的完整URL(结尾不包括斜杠)
define(‘WP_CONTENT_URL’, ‘http://domain.tld/path/wp-content’);

你也可以另外给wp-content 目录指定一个自定义路径。可以解决一些插件的兼容性问题：

//当前目录的完全本地路径(结尾不包括斜杠)
define(‘WP_PLUGIN_DIR’, $_SERVER['DOCUMENT_ROOT'].’/path/wp-content/plugins’);

//当前目录的完整URL(结尾不包括斜杠)
define(‘WP_PLUGIN_URL’, ‘http://domain.tld/path/wp-content/plugins’);

日志修订版的处理

Worepress最新版本提供了一个发布后修改系统，用户可保存不同的博客版本，甚至，如果有需要的话，还可以恢复到先前保存的博客版本。不管你喜欢还是不喜欢这个功能，下面的设置可能都对你有帮助。

限制保存博客版本的数量

define(‘WP_POST_REVISIONS’, 3); // 任意整数，不过不要太夸张。

禁用修订版功能

define(‘WP_POST_REVISIONS’, false);

指定自动保存间隔

跟发布版本功能类似，WordPress其实使用了自动保存功能。默认情况下，WordPress每一分钟自动保存你的作品，不过你完全可以根据需要改变这个数值。不过也注意不要太夸张，以免破坏了你的服务器。

define(‘AUTOSAVE_INTERVAL’, 160); // 单位秒

调试WordPress

自从2.3.1版本以来，有一些错误和警告提示帮助用户调试网站。截止2.5版本， 报错等级提高到E_ALL并有激活对一些函数的警告功能。默认(即，没有在wp-config.php文件中指定任何定义)，错误报告被禁用。

define(‘WP_DEBUG’, true); // 启用调试模式
define(‘WP_DEBUG’, false); // 禁用调试模式（默认）

错误日志配置

下面是启用WordPress站点错误日志的一种简单方法。创建一个名为“php_error.log”的文件，使其对服务器可写，并将其放置在你选择的目录下。接着在下面代码中第三行编辑路径，并加入wp-config.php 中：

@ini_set(‘log_errors’,'On’);
@ini_set(‘display_errors’,'Off’);
@ini_set(‘error_log’,'/home/path/domain/logs/php_error.log’);

增加PHP内存

如果你收到错误提示“允许的内存xxx字节已用尽” ，这个设置就对你有帮助了。截至WordPress的2.5版，WP_MEMORY_LIMIT定义，你可以指定PHP使用的最大内存。默认情况下，最大 PHP内存是32兆，因此只有要求大于32兆是菜需要更改此设置。注意，有些虚拟主机禁止你提高PHP 内存，所以你得请求他们帮忙。下面是例子：

define(‘WP_MEMORY_LIMIT’, ’64M’);
define(‘WP_MEMORY_LIMIT’, ’96M’);
define(‘WP_MEMORY_LIMIT’, ’128M’);

保存并显示数据库查询以供分析

这个技术可实现保存并显示数据库查询的信息以备后面分析。这个过程保存了每一次查询、相关的函数以及总的执行时间。这些信息都保存为一个数组的形式，并可显示在任何模板页上。不过，首先得在你的wp-config.php 文件添加下面的指令：

define(‘SAVEQUERIES’, true);

然后，在主题的footer上加上下面的代码：

// 只对admin显示查询数组
if (current_user_can(‘level_10′)) {
global $wpdb;
echo “<pre>”;
print_r($wpdb->queries);
echo “</pre>”;
}

下面是此函数的单行版本:

<?php if (current_user_can(‘level_10′)) { global $wpdb; echo “<pre>”; print_r($wpdb->queries); echo “</pre>”; } ?>

限制代理访问

WordPress 2.8及以上版本，可用配置文件定义一些常量，包括封锁、允许、过滤从一个代理服务器访问特定主机。例如，如果你的WordPress站点是联网的， 你需要阻止访问任何外部主机，只允许本地主机访问，使用下面第一个定义。如果你允许特定主机访问，用逗号分隔主机名称即可，像下面第三个定义一样。 注意，请允许api.wordpress.org访问，确保一些核心文件和插件能起到恰当的作用。

define(‘WP_HTTP_BLOCK_EXTERNAL’, true); // 阻止外部请求
define(‘WP_HTTP_BLOCK_EXTERNAL’, false); // 允许外部请求
define(‘WP_ACCESSIBLE_HOSTS’, ‘api.wordpress.org’); // 白名单主机

附原文：

WordPress Configuration Tricks

Many WordPress users know the wp-config.php file as the key to the WordPress database. It is where you set the database name, username, password, and location. You know the one:

The wp-config.php file contains the information required for WordPress to connect to the database

But what many users don’t know is that the wp-config.php file may be used to specify a wide variety of configurational settings, enabling you to improve the functionality, performance, and security of your WordPress-powered site. In this article, I share as many of these configurational tricks as I have been able to collect over the years. This guide covers everything in the WordPress Codex, as well some additional tricks that you probably haven’t seen before. If you know of any other WordPress configuration tricks, share them in the comments and I will add them to the post.

Database Credentials *

This set of four configurational definitions are required for WordPress to connect to the database:

define('DB_NAME', 'database-name');
define('DB_USER', 'database-username');
define('DB_PASSWORD', 'database-password');
define('DB_HOST', 'localhost');

Database name, username, and password should be readily available to you during database creation, but the DB_HOST value may be more difficult to acquire. Most commonly, this value is simply “localhost”, but if that doesn’t work, here are a few other values to try:

• 1and1 Hosting — db12345678
• DreamHost — mysql.example.com
• GoDaddy — h41mysql52.secureserver.net
• ICDSoft — localhost:/tmp/mysql5.sock
• MediaTemple (GS) — internal-db.s44441.gridserver.com
• Pair Networks — dbnnnx.pair.com
• Yahoo — mysql

You can even specify an alternate port for your database server. Here are two examples:

define('DB_HOST', 'localhost:1234');
define('DB_HOST', 'mysql.domain.tld:1234');

Another cool trick is to detect the database server value automatically:

define('DB_HOST', $_ENV{DATABASE_SERVER});

If all of these fail, or if you are still having problems, consult your hosting provider for assistance.

Database Character Set and Collation *

As of WordPress version 2.2, you may specify a character set for your MySQL database tables. Generally, there is no reason to change the default character-set value of UTF-8, which is usually perfect because it supports all languages. Note that you should only use this definition if it already exists in your wp-config.php file. Here is the default (and recommended) setting:

define('DB_CHARSET', 'utf8');

WordPress version 2.2 also enables you to specify the collation, which is the sort order of your database character set. Setting the collation is generally handled automatically by MySQL according to the character set, which is enabled by leaving the collation value blank as done in the default setting for this definition. Note that you should only use this definition if it already exists in your wp-config.php file. Here is the default (and recommended) setting:

define('DB_COLLATE', '');

Security Keys *

As of WordPress 2.7, there are four security keys available that are designed to insure better cookie encryption. These keys work silently in the background and should be as random and complicated as possible (no, you will never need to remember them). The easiest way to generate these keys is to do it automatically at the WordPress.org secret-key service. Simply visit that link and copy/paste the results into your wp-config.php file. Note that these keys may be changed anytime, and doing so will invalidate all of your users’ existing cookies so that they will have to re-login to your site.

define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YV)p:Qi?jXLq,<h\\`39');
define('SECURE_AUTH_KEY', '@*+S=8\"\'+\"}]<m#+}V)p:Qi?jXLq,<h\\`39m_(');
define('LOGGED_IN_KEY', 'S~AACm4h1;T^\"qW3_8Zv!Ji=y|)~5i63JI |Al[(<YS');
define('NONCE_KEY', 'k1+EOc-&w?hG8j84>6L9v\"6C89NH?ui{*3\\(t09mumL/fF');

Database Prefix *

The database prefix setting is particularly useful for increasing the security of your site and for housing multiple WordPress installations in a single database. By changing the default value of “wp_” to something randomly unique, you mitigate commonly targeted attack vectors and improve the overall security of your site. Here is the default setting:

$table_prefix  = 'wp_';

There are tons of crackers out there probing sites for this default database prefix. Changing it to something like “x777_” is a good way to avoid these types of targeted attacks.

You can also use this setting to install multiple instances of WordPress using the same database. Simply specify a unique database prefix for each installation:

$table_prefix  = 'wp1_'; // first blog
$table_prefix  = 'wp2_'; // second blog
$table_prefix  = 'wp3_'; // third blog

Language Settings *

WordPress makes it possible to specify a language-translation file and its associated directory. The language translation file is assumed to be of the “.mo” variety, and its default location (if no explicit path is specified) is assumed to be wp-content/languages (first) and then wp-includes/languages (second). Here is the default setting:

define('WPLANG', '');
define('LANGDIR', '');

Directory Settings *

Technically not something that you should need to mess with, the default wp-config.php file contains a few lines that specify the absolute path and include the settings file. I include them here for the sake of completeness:

/** WordPress absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Blog Address and Site Address

Now we’re getting to some of the cool stuff. By default, these two configurational definitions are not included in the wp-config.php file, but they should be added to improve performance. These two settings were introduced in WordPress version 2.2 and override the database value without actually changing them. Adding these two definitions in your site’s wp-config.php file reduces the number of database queries and thus improves site performance. These settings should match those specified in your WordPress Admin. Here is an example (note that you should not include a trailing slash at the end of either URL):

define('WP_HOME', 'http://digwp.com');
define('WP_SITEURL', 'http://digwp.com');

A cool trick is to set these values dynamically by using the global server variable:

define('WP_HOME', 'http://'.$_SERVER['HTTP_HOST'].'/path/to/wordpress');
define('WP_SITEURL', 'http://'.$_SERVER['HTTP_HOST'].'/path/to/wordpress');

Template Path and Stylesheet Path

As with the predefined constants for blog address and site address (see previous section), you can also boost performance by eliminating database queries for the template path and stylesheet path for your site. Here are the default values for these two definitions:

define('TEMPLATEPATH', get_template_directory());
define('STYLESHEETPATH', get_stylesheet_directory());

As is, these two definitions are still querying the database, but we can eliminate these extraneous queries by hardcoding the values into place:

define('TEMPLATEPATH', '/absolute/path/to/wp-content/themes/active-theme');
define('STYLESHEETPATH', '/absolute/path/to/wp-content/themes/active-theme');

Disable Cache and Cache Expiration

These two options apply to older versions of WordPress that are still using the default object-based caching mechanism. The first definition enables you to enable or disable the cache, while the second definition enables you to specify the cache expiration time.

Enable the cache

define('WP_CACHE', true);      // enable the cache
define('ENABLE_CACHE', true);  // enable the cache
define('CACHE_EXPIRATION_TIME', 3600); // in seconds

Disable the cache

define('WP_CACHE', false);     // disable the cache
define('DISABLE_CACHE', true); // disable the cache

Specify Cookie Domain

There are several reasons why you want to specify a cookie domain for your site. A common example involves preventing cookies from being sent with requests for static content on subdomains. In this case, you would use this definition to tell WordPress to send cookies only to your non-static domain. This could be a significant performance boost. Here are some examples of setting various cookie path and cookie domain information:

define('COOKIE_DOMAIN', '.digwp.com'); // don't omit the leading '.'
define('COOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('home').'/'));
define('SITECOOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('siteurl').'/'));
define('PLUGINS_COOKIE_PATH', preg_replace('|https?://[^/]+|i', '', WP_PLUGIN_URL));
define('ADMIN_COOKIE_PATH', SITECOOKIEPATH.'wp-admin');

Override File Permissions

If your web host’s default file permissions are too restrictive, adding these definitions to your WordPress configuration file may help resolve the issue. Note that you don’t need the quotes around the permission values. Here is an example:

define('FS_CHMOD_FILE', 0755);
define('FS_CHMOD_DIR', 0755);

View All Defined Constants

Need to view all predefined constants? Good news, this PHP function will return an array of all currently defined constants:

print_r(@get_defined_constants());

Custom User and Usermeta Tables

What about custom user and usermeta tables? Yep, you can do that too, with the following definitions:

define('CUSTOM_USER_TABLE', $table_prefix.'my_users');
define('CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta');

FTP/SSH Constants

This set of configurational definitions is designed to help users locate and utilize FTP/SSH connections. Here is a example set of predefined constants for FTP/SSH updates:

define('FS_METHOD', 'ftpext'); // forces the filesystem method: "direct", "ssh", "ftpext", or "ftpsockets"
define('FTP_BASE', '/path/to/wordpress/'); // absolute path to root installation directory
define('FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/'); // absolute path to "wp-content" directory
define('FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/'); // absolute path to "wp-plugins" directory
define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub'); // absolute path to your SSH public key
define('FTP_PRIVKEY', '/home/username/.ssh/id_rsa'); // absolute path to your SSH private key
define('FTP_USER', 'username'); // either your FTP or SSH username
define('FTP_PASS', 'password'); // password for FTP_USER username
define('FTP_HOST', 'ftp.domain.tld:21'); // hostname:port combo for your SSH/FTP server

Moving Your wp-content directory

As of WordPress version 2.6, you may change the default location of the wp-content directory. There are several good reasons for doing this, including enhancement of site security and facilitation of FTP updates. Here are some examples:

// full local path of current directory (no trailing slash)
define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'].'/path/wp-content'); 

// full URI of current directory (no trailing slash)
define('WP_CONTENT_URL', 'http://domain.tld/path/wp-content');

You may also further specify a custom path for your wp-content directory. This may help with compatibility issues with certain plugins:

// full local path of current directory (no trailing slash)
define('WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'].'/path/wp-content/plugins'); 

// full URI of current directory (no trailing slash)
define('WP_PLUGIN_URL', 'http://domain.tld/path/wp-content/plugins');

Dealing with Post Revisions

Recent versions of WordPress provides a post-revisioning system that enables users to save different versions of their blog posts and even revert to previously saved versions if necessary. Regardless of how much you do or do not despise this amazingly awesome feature, here are a couple of configurational definitions that may prove useful for you ;)

Limit the number of saved revisions

define('WP_POST_REVISIONS', 3); // any integer, but don't get too crazy

Disable the post-revisioning feature

define('WP_POST_REVISIONS', false);

Specify the Autosave Interval

In a similar vein as the post-revisioning feature is WordPress’ actually useful Autosave functionality. By default, WordPress saves your work every 60 seconds, but you can totally modify this setting to whatever you want. Don’t get too crazy though, unless you want to stress-out your server ;)

define('AUTOSAVE_INTERVAL', 160); // in seconds

Debugging WordPress

Since WordPress version 2.3.1, users have been able to display certain errors and warnings to help with the debugging of their site. As of WordPress version 2.5, enabling error reporting raises the reporting level to E_ALL and activates warnings for deprecated functions. By default (i.e., if no definition is specified in the wp-config.php file), error reporting is disabled.

define('WP_DEBUG', true); // enable debugging mode
define('WP_DEBUG', false); // disable debugging mode (default)

Error Log Configuration

Here is an easy way to enable basic error logging for your WordPress-powered site. Create a file called “php_error.log”, make it server-writable, and place it in the directory of your choice. Then edit the path in the third line of the following code and place into your wp-config.php file:

@ini_set('log_errors','On');
@ini_set('display_errors','Off');
@ini_set('error_log','/home/path/domain/logs/php_error.log');

Increase PHP Memory

If you are receiving error messages telling you that your “Allowed memory size of xxx bytes exhausted,” this setting may help resolve the issue. AS of WordPress version 2.5, the WP_MEMORY_LIMIT definition enables you to specify the maximum amount of memory that may be used by PHP. By default, WordPress will automatically attempt to increase PHP memory up to 32MB, so this setting is only needed for values higher than 32MB. Note that some web hosts disable your ability to increase PHP memory, so you may need to beg for them to do it. Here are some examples:

define('WP_MEMORY_LIMIT', '64M');
define('WP_MEMORY_LIMIT', '96M');
define('WP_MEMORY_LIMIT', '128M');

Save and Display Database Queries for Analysis

This technique is perfect for saving database queries and displaying the information for subsequent analysis. The process saves each query, its associated function, and its total execution time. This information is saved as an array and may be displayed on any theme template page. To do this, first add the following directive to your wp-config.php file:

define('SAVEQUERIES', true);

Then, in the footer of your active theme, place the following code:

// display the query array for admin only
if (current_user_can('level_10')) {
	global $wpdb;
	echo "<pre>";
	print_r($wpdb->queries);
	echo "</pre>";
}

Here is a single-line version of this function:

<?php if (current_user_can('level_10')) { global $wpdb; echo "<pre>"; print_r($wpdb->queries); echo "</pre>"; } ?>

Control Proxy Access

Since WordPress 2.8, the configuration file may be used to define constants involved with blocking, allowing and filtering access to specific hosts from behind a proxy server. For example, if you host your WordPress site on an intranet network, you may prevent access to all external hosts and only allow requests from localhost and your blog using the first definition below. You may also allow specific hosts access with a comma-separated list of allowed hostnames, as demonstrated in the third definition below. Note that you should allow api.wordpress.org access to ensure proper functionality of core files and plugins.

define('WP_HTTP_BLOCK_EXTERNAL', true);  // block external requests
define('WP_HTTP_BLOCK_EXTERNAL', false); // allow external requests
define('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org'); // whitelist hosts