Go here to read the rest:
Advanced WordPress wp-config.php Tweaks
Shared by 小董
這個大佬寫的東西一向經典
The bottom line for this article is that I want to make WordPress as fast, secure, and easy to install, run, and manage because I am using it more and more for client production sites, I will work for days in order to solve an issue so that I never have to spend time on that issue again. Time is money in this industry and that is ultimately (time) what there is to gain by tweaking WordPress.
Note: I spent no time on readability, this is primarily a read the code and figure it out article.. This is for advanced users looking for a reference or discussion and for those of you looking to advance. Feedback would be great if you make it that far..
For a better handle on the way I like to structure web site directories, see Optimize a Website for Speed, Security, and Easy Management but note it is a bit outdated compared to what I’m doing now. I don’t have the luxury of using only one type of server, or hosting provider anymore, so I have been working towards making things even more portable in order to move from host to host from server to server without issues i.e. my portable .bash_profile.
So I’ve been basically experimenting various ways to accomplish that and thought I would share what I am currently doing for my benefit and hopefully get some input. All of my WP installs run the development version, and one main idea with my setups is that upgrading is automated. So I really keep the WordPress install clean and use plugins and wp-config.php to do all the customization.
- Portability – Hands-free upgrades and easy to move
- Security – Additional security and protection
- Speed – Less CPU and Disk I/O
- Customization – All my favorite customizations
wp-config.php
These are the main settings I use.. Seriously this is more like an interactive article, because to understand it you will need to do some code grepping. You may want to grab a jolt.
ASKAPACHE_ROOT
The ASKAPACHE_ROOT variable is just a better way for me to be able to include and access all the different files in my site tree. For instance, in my non-wp php files, I can do this:
!defined('ASKAPACHE_ROOT') && require $_SERVER'DOCUMENT_ROOT' . '/wp-config.php';
include(ASKAPACHE_ROOT . '/includes/custom-download.inc.php');
ASKAPACHE_LOCK
This is one of my all-time favorite hacks, that I think is one of the most useful methods I employ as a web developer. This allows me to use far-future-expire headers for optimum caching, while still forcing browsers to re-validate every day or so automatically, or forcing them to re-validate whenever I change the suffix. This takes advantage of the mod_rewrite trick that I use on EVERY site I run, definately worth learning. Because I practice best-practice web-standards, for every web site I create a single css file and javascript file, which I then add to the template like:
< ?php
/**
* The base configurations of the WordPress.
*
* This file has the following configurations: MySQL settings, Table Prefix,
* Secret Keys, WordPress Language, and ABSPATH. You can find more information by
* visiting @link http://codex.wordpress.org/Editing_wp-config.php Editing
* wp-config.php Codex page. You can get the MySQL settings from your web host.
*
* This file is used by the wp-config.php creation script during the
* installation. You don't have to use the web site, you can just copy this file
* to "wp-config.php" and fill in the values.
*
* @package WordPress
*/
/* http://codex.wordpress.org/Editing_wp-config.php */
/** /home/liet/askapache.com */
!defined('ASKAPACHE_ROOT') && define('ASKAPACHE_ROOT', str_replace('/public_html','', $_SERVER'DOCUMENT_ROOT'));
/** The 008 at the end is for manual tweaking. time() returns seconds since '00:00:00 1970-01-01 UTC'. */
// http://www.askapache.com/htaccess/mod_rewrite-fix-for-caching-updated-files.html
!defined('ASKAPACHE_LOCK') && define(ASKAPACHE_LOCK', substr(time(),0,5).'008'); // 12533001
/** absolute path to the WordPress directory */
!defined('ABSPATH') && define('ABSPATH', ASKAPACHE_ROOT .'/public_html/');
/**
* WP_SITEURL, defined since WordPress Version 2.2, allows the WordPress address (URL) to be defined. The valued defined is the address where your WordPress core files reside.
* It should include the http:// part too. Do not put a slash "/" at the end.
* Setting this value in wp-config.php overrides the wp_options table value for siteurl and disables the WordPress address (URL) field in the Administration > Settings > General panel.
*/
!defined('WP_SITEURL') && define('WP_SITEURL', 'http://'.$_SERVER'SERVER_NAME');
/**
* WP_HOME is another wp-config.php option added in WordPress Version 2.2. Similar to WP_SITEURL,
* WP_HOME overrides the wp_options table value for home but does not change it permanently.
* home is the address you want people to type in their browser to reach your WordPress blog. It should include the http:// part. Also, do not put a slash "/" at the end.
*/
!defined('WP_HOME') && define('WP_HOME', WP_SITEURL);
/** no trailing slash, full paths only */
!defined('WP_CONTENT_DIR') && define( 'WP_CONTENT_DIR', ABSPATH . 'wp-content' );
// full url - WP_CONTENT_DIR is defined further up
!defined('WP_CONTENT_URL') && define( 'WP_CONTENT_URL', WP_SITEURL . '/wp-content');
/** Allows for the plugins directory to be moved from the default location. @since 2.6.0 */
// full path, no trailing slash
!defined('WP_PLUGIN_DIR') && define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/plugins' );
/** Allows for the plugins directory to be moved from the default location. @since 2.6.0 */
// full url, no trailing slash
!defined('WP_PLUGIN_URL') && define( 'WP_PLUGIN_URL', WP_CONTENT_URL . '/plugins' );
/** Allows for the plugins directory to be moved from the default location. @since 2.1.0 */
// Relative to ABSPATH. For back compat.
//!defined('PLUGINDIR') && define( 'PLUGINDIR', 'wp-content/plugins' );
/** Number of autosaves to save. TRUE is default and enables post revisions, FALSE disables revisions completely. */
!defined('WP_POST_REVISIONS') && define('WP_POST_REVISIONS', 150);
/* ini_set('memory_limit', WP_MEMORY_LIMIT); */
!defined('WP_MEMORY_LIMIT') && define('WP_MEMORY_LIMIT', '64M');
/** Only check at this interval for new messages. Default is 5min */
/** @since 2.9 */
!defined('WP_MAIL_INTERVAL') && define('WP_MAIL_INTERVAL', 3600); // 1 hour
/** Saves updated post values to post from edit window every x seconds. (default 60)
* When editing a post, WordPress uses Ajax to auto-save revisions to the post as you edit. You may want to increase this setting for longer delays in between auto-saves, or decrease the setting to make sure you never lose changes.
* @since 2.5.0 */
!defined( 'AUTOSAVE_INTERVAL' ) && define( 'AUTOSAVE_INTERVAL', 60 );
/** @since 2.9.0 */
/** Permanently deletes posts, pages, attachments, and comments which have been in the trash for EMPTY_TRASH_DAYS. */
!defined( 'EMPTY_TRASH_DAYS' ) && define( 'EMPTY_TRASH_DAYS', 300 );
Debugging WordPress
One of my secrets for getting really good at this stuff is to master debugging. There is really not ever a time when I am working on a site that I don’t have color-highlighted logs scrolling automatically in an ssh window. It’s really almost impossible to fix problems with wordpress or do any kind of advanced anything without being able to view debugging info. At first I relied heavily on a custom php.ini being available on the server, but after having to deal with many hosts who don’t allow php.ini files I now rely completely on setting values using ini_set for ultimate portability. Detailed towards the end of this article and is also included in this wp-config.php
/**#@+
* DEBUGGING STUFF
*/
/** display of notices during development. if false, error_reporting is E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR otherwise E_ALL */
!defined('WP_DEBUG') && define('WP_DEBUG', false);
/** The SAVEQUERIES definition saves the database queries to a array and that array can be displayed to help analyze those queries.
* The information saves each query, what function called it, and how long that query took to execute. */
!defined('SAVE_QUERIES') && define('SAVE_QUERIES', WP_DEBUG);
!defined('ACTION_DEBUG') && define('ACTION_DEBUG', WP_DEBUG);
/** This will allow you to edit the scriptname.dev.js files in the wp-includes/js and wp-admin/js directories. */
!defined('SCRIPT_DEBUG') && define('SCRIPT_DEBUG', WP_DEBUG);
/** Add define('WP_DEBUG_LOG', true); to enable php debug logging to WP_CONTENT_DIR/debug.log */
//!defined('WP_DEBUG_LOG') && define('WP_DEBUG_LOG', true);
/** This determines whether errors should be printed to the screen as part of the output or if they should be hidden from the user.
* Add define('WP_DEBUG_DISPLAY', false); to wp-config.php to use the globally configured setting for display_errors and not force it to On */
!defined('WP_DEBUG_DISPLAY') && define('WP_DEBUG_DISPLAY', false);
Ultimate Security Tweaks
Well, ultimate for WP’s built-in keys and password functions, this is all for wp-config.php keep in mind. This is a very neccessary and recommended step, and is one of the only things I modify for each new installation.
Security KEYS
If like me you are familiar with password-cracking software like John the ripper, rainbow hash tables, l0pht-crack, etc.. then you will like to know that you can specify your own keys and salts for the encryption used by WP. They are AUTH_KEY, AUTH_SALT, SECURE_AUTH_KEY, SECURE_AUTH_SALT, LOGGED_IN_KEY, LOGGED_IN_SALT, NONCE_KEY, NONCE_SALT, SECRET_KEY and SECRET_SALT.
A random and long key gives you better encryption, and exponentially increasing that is using a random and long salt for the encryption. Encryptions with known salts are incredibly easy to decrypt compared to encryptions with secure salts, because the salt + key individually need to be guessed in order to find a matching hash, vs. just the key if the salt is known. See: Locating weak passwords.
A secret key is a hashing salt which makes your site harder to hack and access harder to crack by adding random elements to the password.
In simple terms, a secret key is a password with elements that make it harder to generate enough options to break through your security barriers. A password like “password” or “test” is simple and easily broken. A random, unpredictable password such as “88a7da62429ba6ad3cb3c76a09641fc” takes years to come up with the right combination.
For more information on the technical background and breakdown of secret keys and secure passwords, see:
- WordPress Support Forum – HOWTO: Set up secret keys in WordPress 2.6+
- Wikipedia’s explanation of Password Cracking
I like to use the WordPress.org secret-key service 4 times. That’s because for each key and salt I like to do: (1 key from api +random keyboard input+1 key from api).
/**#@+
* Authentication Unique Keys.
*
* Change these to different unique phrases!
* You can generate these using the @link https://api.wordpress.org/secret-key/1.1/ WordPress.org secret-key service
* You can change these at any point in time to invalidate all existing cookies.
* This will force all users to have to log in again.
*
* @since 2.6.0
*
* Get salt to add to hashes to help prevent attacks.
*
* The secret key is located in two places: the database in case the secret key
* isn't defined in the second place, which is in the wp-config.php file. If you
* are going to set the secret key, then you must do so in the wp-config.php
* file.
*
* The secret key in the database is randomly generated and will be appended to
* the secret key that is in wp-config.php file in some instances. It is
* important to have the secret key defined or changed in wp-config.php.
*
* If you have installed WordPress 2.5 or later, then you will have the
* SECRET_KEY defined in the wp-config.php already. You will want to change the
* value in it because hackers will know what it is. If you have upgraded to
* WordPress 2.5 or later version from a version before WordPress 2.5, then you
* should add the constant to your wp-config.php file.
*
* Below is an example of how the SECRET_KEY constant is defined with a value.
* You must not copy the below example and paste into your wp-config.php. If you
* need an example, then you can have a
* @link https://api.wordpress.org/secret-key/1.1/ secret key created for you.
*
* Salting passwords helps against tools which has stored hashed values of
* common dictionary strings. The added values makes it harder to crack if given
* salt string is not weak.
*
* @since 2.5
* @link https://api.wordpress.org/secret-key/1.1/ Create a Secret Key for wp-config.php
*
* @return string Salt value from either 'SECRET_KEY' or 'secret' option
*/
define('AUTH_KEY', 'jflkhaskljdfhkljasdhflkjashd;flkjhas;djfh;kajshdflkjashdlfkjhasdlkfhal?pBb15baar8&R-r+wm 2)bS0Pd_+1rx0brX]ND8 ^$
RewriteCond %REQUEST_URI ^/(wp-admin|wp-login.php).*$ NC,OR
RewriteCond %HTTP_COOKIE ^.*wp_li_sadfsdfasdf11b361cdsdfasdfasd=.*$ NC
RewriteRule .* - S=1
RewriteCond %HTTPS =on OR
RewriteCond %HTTP_HOST !^www.askapache.com$ NC
RewriteRule .* http://%SERVER_NAME%REQUEST_URI R=301,L
RewriteCond %THE_REQUEST ^A-Z3,9 /(wp-admin/.*|wp-login.php.*) HTTP/ NC
RewriteCond %HTTPS !=on
RewriteRule .* https://%SERVER_NAME%REQUEST_URI R=301,L
File System Permissions
You can get a basic and solid intro on file permissions by reading: Changing File Permissions, or you can check out some of my file permission research.
/** The permissions as octal number, usually 0644 for files, 0755 for dirs.
* http://codex.wordpress.org/Changing_File_Permissions
* if ( !$wp_filesystem->mkdir($remote_destination, FS_CHMOD_DIR) )
*/
!defined('FS_CHMOD_DIR') && define('FS_CHMOD_DIR', (0755 & ~ umask()));
!defined('FS_CHMOD_FILE') && define('FS_CHMOD_FILE', (0644 & ~ umask()));
/**#@-*/
/** Define the timeouts for the connections. Only available after the construct is called to allow for per-transport overriding of the default. */
//stream_set_timeout( $stream, FS_TIMEOUT );
//!defined('FS_TIMEOUT') && define('FS_TIMEOUT', 30);
//$this->link = @ftp_connect($this->options'hostname', $this->options'port', FS_CONNECT_TIMEOUT);
//!defined('FS_CONNECT_TIMEOUT') && define('FS_CONNECT_TIMEOUT', 30);
// function get_filesystem_method($args = array(), $context = false)
// $method = defined('FS_METHOD') ? FS_METHOD : false; //Please ensure that this is either 'direct', 'ssh', 'ftpext' or 'ftpsockets'
//!defined('FS_METHOD') && define('FS_METHOD', 'direct');
/** These methods for the WordPress core, plugin, and theme upgrades try to determine the WordPress path, as reported by PHP, but symlink trickery can sometimes
* 'muck this up' so if you know the paths to the various folders on the server, as seen via your FTP user, you can manually define them in the wp-config.php file.
* FS_METHOD forces the filesystem method. It should only be "direct", "ssh", "ftpext", or "ftpsockets".
* FTP_BASE is the full path to the "base" folder of the WordPress installation.
* FTP_CONTENT_DIR is the full path to the wp-content folder of the WordPress installation.
* FTP_PLUGIN_DIR is the full path to the plugins folder of the WordPress installation.
* FTP_PUBKEY is the full path to your SSH public key.
* FTP_PRIKEY is the full path to your SSH private key.
* FTP_USER is either user FTP or SSH username. Most likely these are the same, but use the appropriate one for the type of update you wish to do.
* FTP_PASS is the password for the username entered for FTP_USER. If you are using SSH public key authentication this can be omitted.
* FTP_HOST is the hostname:port combination for your SSH/FTP server. The standard FTP port is 21 and the standard SSH port is 22.
*/
//define('FS_METHOD', 'ftpext');
//define('FTP_BASE', '/path/to/wordpress/');
//define('FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/');
//define('FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/');
//define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub');
//define('FTP_PRIKEY', '/home/username/.ssh/id_rsa');
//define('FTP_USER', 'username');
//define('FTP_PASS', 'password');
//define('FTP_HOST', 'ftp.example.org:21');
/**
* Block requests through the proxy.
*
* Those who are behind a proxy and want to prevent access to certain hosts may do so. This will
* prevent plugins from working and core functionality, if you don't include api.wordpress.org.
*
* You block external URL requests by defining WP_HTTP_BLOCK_EXTERNAL in your wp-config.php file
* and this will only allow localhost and your blog to make requests.
* The constant WP_ACCESSIBLE_HOSTS will allow additional hosts to go through for requests. The format of the
* WP_ACCESSIBLE_HOSTS constant is a comma separated list of hostnames to allow.
*
* @since 2.8.0
* @link http://core.trac.wordpress.org/ticket/8927 Allow preventing external requests.
/** @since 2.9 */
//!defined('WP_HTTP_BLOCK_EXTERNAL') && define( 'WP_HTTP_BLOCK_EXTERNAL', false );
/*
* The constant WP_ACCESSIBLE_HOSTS will allow additional hosts to go through for requests. The format of the
* WP_ACCESSIBLE_HOSTS constant is a comma separated list of hostnames to allow.
*
* @since 2.8.0
* @link http://core.trac.wordpress.org/ticket/8927 Allow preventing external requests.
* $accessible_hosts = preg_split('n") ) print_r($$n);return ob_get_clean();');
foreach (array('_GET','_POST','_COOKIE','_SESSION','_ENV','_FILES','_SERVER','_REQUEST','HTTP_POST_FILES','HTTP_POST_VARS','HTTP_SERVER_VARS','HTTP_RAW_POST_DATA','HTTP_GET_VARS','HTTP_COOKIE_VARS','HTTP_ENV_VARS') as $k)echo $gv($k);
print_r(get_defined_constants());
}
Also check the WordPress Codex page: Editing wp-config.php and Perishable Press’s: Stupid WordPress Tricks
Advanced WordPress wp-config.php Tweaks originally appeared on AskApache.com
![[PHP::PDO]SQLITE Drop Columns function](http://www.taiwangeek.com/wp-content/themes/Weekly_v1.0.1/timthumb.php?src=/wp-content/themes/Weekly_v1.0.1/images/default_thumb.gif&h=40&w=40&zc=1)
