Languages: English • ã®ç·¨é 日本語 (Add your language)
Prosím, neupravujte túto stránku Codex s nastaveniami vášho vlastného serveru. Date tým svoje kritické údaje celému svetu a vaša inštalácia WordPress aj tak nebude fungovať. Ďakujeme.
Tento súbor, wp-config.php, neexistuje v prevzatej kopii WordPress; potrebujete ho vytvoriť. Súbor wp-config-sample.php je daný ako príklad ako by mal taký súbor vyzerať. Rozšírené nastavenia a príklady sú uvedené nižšie.
Na zmenu vášho súboru wp-config.php vašej inštalácie, budete potrebovať nasledujúce informácie:
If your hosting provider installed WordPress for you, get the information from them. If you manage your own web server or hosting account, you will have this information as a result of creating the database and user.
Important: never use a word processor like Microsoft Word for editing WordPress files!
Locate the file wp-config-sample.php in the base directory of your WordPress directory and open in a text editor.
This is an example of a default wp-config-sample.php, you will need to replace the default values in your copy of this file with your own specific database settings.
// ** MySQL settings - You can get this info from your web host ** // /** The name of the database for WordPress */ define( 'DB_NAME', 'database_name_here' ); /** MySQL database username */ define( 'DB_USER', 'username_here' ); /** MySQL database password */ define( 'DB_PASSWORD', 'password_here' ); /** MySQL hostname */ define( 'DB_HOST', 'localhost' );
Replace putyourdbnamehere, with the name of your database, e.g. MyDatabaseName.
define( 'DB_NAME', 'MyDatabaseName' ); // Example MySQL database name
Replace usernamehere, with the name of your username e.g. MyUserName.
define( 'DB_USER', 'MyUserName' ); // Example MySQL username
Replace yourpasswordhere, with the your password, e.g. MyPassWord.
define( 'DB_PASSWORD', 'MyPassWord' ); // Example MySQL password
Replace localhost, with the name of your database host, e.g. MyDatabaseHost.
define( 'DB_HOST', 'MyDatabaseHost' ); // Example MySQL Database host
Different hosting companies use different network settings for their mysql database's. If your hosting company is listed below in the left column, the value on the right is similar to the correct value for DB_HOST. Contact your tech support and/or search your hosting companies online Documentation to be sure.
Hosting Company | DB_HOST Value Guess |
---|---|
1and1 | db12345678 |
AN Hosting | localhost |
BlueHost | localhost |
DreamHost | mysql.example.com |
GoDaddy | h41mysql52.secureserver.net |
HostGator | localhost |
HostICan | localhost |
ICDSoft | localhost:/tmp/mysql5.sock |
LaughingSquid | localhost |
MediaTemple GridServer | internal-db.s44441.gridserver.com |
one.com | localhost |
pair Networks | dbnnnx.pair.com |
Yahoo | mysql |
Hosts with cPanel | localhost |
Hosts with Plesk | localhost |
Hosts with DirectAdmin | localhost |
If your host uses an alternate port number for your database you'll need to change the DB_HOST value in the wp-config.php file to reflect the alternate port provided by your host.
For localhost
define('DB_HOST', 'localhost:3307');
Other
define('DB_HOST', 'mysql.example.com:4454');
As of WordPress Version 2.2, DB_CHARSET was made available to allow designation of the database character set (e.g. tis620 for TIS620 Thai) to be used when defining the MySQL database tables.
The default value of utf8 (Unicode UTF-8) is almost always the best option. UTF-8 supports any language, so you typically want to leave DB_CHARSET at utf8 and use the DB_COLLATE value for your language instead.
This example shows utf8 which is considered the WordPress default value:
define('DB_CHARSET', 'utf8');
There usuallly should be no reason to change the default value of DB_CHARSET. If your blog needs a different character set, please read Character Sets and Collations MySQL Supports for valid DB_CHARSET values.
If DB_CHARSET and DB_COLLATE do not exist in your wp-config.php file, DO NOT add either definition to your wp-config.php file unless you read and understand Converting Database Character Sets. Adding DB_CHARSET and DB_COLLATE to the wp-config.php file, for an existing blog, can cause major problems.
As of WordPress Version 2.2, DB_COLLATE was made available to allow designation of the database collation (i.e. the sort order of the character set). In most cases, this value should be left blank (null) so the database collation will be automatically assigned by MySQL based on the database character set specified by DB_CHARSET. Set DB_COLLATE to one of the UTF-8 values defined in UTF-8 character sets for most Western European languages.
The WordPress default DB_COLLATE value:
define('DB_COLLATE', );
UTF-8 Unicode General collation
define('DB_COLLATE', 'utf8_general_ci');
UTF-8 Unicode Turkish collation
define('DB_COLLATE', 'utf8_turkish_ci');
There usually should be no reason to change the default value of DB_COLLATE. Leaving the value blank (null) will insure the collation is automatically assigned by MySQL when the database tables are created.
If DB_COLLATE and DB_CHARSET do not exist in your wp-config.php file, DO NOT add either definition to your wp-config.php file unless you read and understand Converting Database Character Sets. And you may be in need of a WordPress upgrade.
Beginning with Version 2.6, three (3) security keys, AUTH_KEY, SECURE_AUTH_KEY, and LOGGED_IN_KEY, were added to insure better encryption of information stored in the user's cookies. Beginning with Version 2.7 a fourth key, NONCE_KEY, was added to this group.
You don't have to remember the keys, just make them long and complicated or better yet, use the the online generator. You can change these at any point in time to invalidate all existing cookies this does mean that all users will have to login again.
Example:
define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YKC^Z7KKGh j>k[.Nf$y7iGKdJ3c*[Kr5Bg'); define('SECURE_AUTH_KEY', 'TufWOuA _.t>#+hA?^|3RfGTm>@*+S=8\"\'+\"}]<m#+}V)p:Qi?jXLq,<h\\`39m_('); define('LOGGED_IN_KEY', 'S~AACm4h1;T^\"qW3_8Zv!Ji=y|)~5i63JI |Al[(<YS<2V^$T])=8Xh2a:b:}U_E'); define('NONCE_KEY', 'k1+EOc-&w?hG8j84>6L9v\"6C89NH?ui{*3\\(t09mumL/fFP_!K$JCEkLuy ={x{0');
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:
The following sections may contain advanced / unsupported information, so please make sure you practice regular backups and know how to restore them before experimenting on a production installation.
The $table_prefix is the value placed in the front of your database tables. Change the value if you want to use something other than wp_ for your database prefix. Typically this is changed if you are installing multiple WordPress blogs in the same database, and also for enhanced security.
Its a safe and good idea to change this value pre-installation to add more security to your WordPress blog. Exploits attempted against your WordPress blog by malicious crackers often are built with the premise that your blog uses the prefix wp_, by changing the value you mitigate some attack vectors.
// You can have multiple installations in one database if you give each a unique prefix $table_prefix = 'r235_'; // Only numbers, letters, and underscores please!
A second blog installation using the same database can be achieved simply by using a different prefix than your other installations.
$table_prefix = 'y77_'; // Only numbers, letters, and underscores please!
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.
If WordPress is installed into a directory called "wordpress" for the domain example.com, define WP_SITEURL like this:
define('WP_SITEURL', 'http://example.com/wordpress');
Dynamically set WP_SITEURL based on $_SERVER['HTTP_HOST']
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpressp');
Dynamically set WP_SITEURL based on $_SERVER['SERVER_NAME']
define('WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/path/to/wordpressp');
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.
define('WP_HOME', 'http://example.com/wordpress');
If you are using the technique described in Giving WordPress Its Own Directory then follow the example below. Remember, you will also be placing an index.php in your web-root directory if you use a setting like this.
define('WP_HOME', 'http://example.com');
Dynamically set WP_HOME based on $_SERVER['HTTP_HOST']
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/path/to/wordpress');
Since Version 2.6, you can move the wp-content directory, which holds your themes, plugins, and uploads, outside of the WordPress application directory.
Set WP_CONTENT_DIR to the full local path of this directory (no trailing slash), e.g.
define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content' );
Set WP_CONTENT_URL to the full URI of this directory (no trailing slash), e.g.
define( 'WP_CONTENT_URL', 'http://example/blog/wp-content');
Optional
Set WP_PLUGIN_DIR to the full local path of this directory (no trailing slash), e.g.
define( 'WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins' );
Set WP_PLUGIN_URL to the full URI of this directory (no trailing slash), e.g.
define( 'WP_PLUGIN_URL', 'http://example/blog/wp-content/plugins');
If you have compability issues with plugins Set PLUGINDIR to the full local path of this directory (no trailing slash), e.g.
define( 'PLUGINDIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins' );
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. The default is 60 seconds.
define('AUTOSAVE_INTERVAL', 160 ); // seconds
WordPress, by default, will save copies of each edit made to a post or page, allowing the possibility of reverting to a previous version of that post or page. The saving of revisions can be disabled, or a maximum number of revisions per post or page can be specified.
If you do not set this value, WordPress defaults WP_POST_REVISIONS to true (enable post revisions). If you want to disable the awesome revisions feature, use this setting:
define('WP_POST_REVISIONS', false );
If you want to specify a maximum number of revisions, change false to an integer/number (e.g., 3 or 5).
define('WP_POST_REVISIONS', 3);
The domain set in the cookies for WordPress can be specified for those with unusual domain setups. One reason is if subdomains are used to serve static content. To prevent WordPress cookies from being sent with each request to static content on your subdomain you can set the cookie domain to your non-static domain only.
define('COOKIE_DOMAIN', 'www.askapache.com');
The WP_DEBUG option, added in WordPress Version 2.3.1, controls the display of some errors and warnings. If this setting is absent from wp-config.php, then the value is assumed to be false.
define('WP_DEBUG', true); define('WP_DEBUG', false);
Additionally, if you are planning on modifying some of WordPress' built-in JavaScript, you should enable the following option:
define('SCRIPT_DEBUG', true);
This will allow you to edit the scriptname.dev.js files in the wp-includes/js and wp-admin/js directories.
In Wordpress versions since 2.3.2, database errors are printed only if WP_DEBUG is set to true. In earlier versions, database errors were always printed. (Database errors are handled by the wpdb class and are not affected by PHP's error settings.)
In WordPress version 2.5, setting WP_DEBUG to true also raises the error reporting level to E_ALL and activates warnings when deprecated functions or files are used; otherwise, WordPress sets the error reporting level to E_ALL ^ E_NOTICE ^ E_USER_NOTICE.
To result in a faster administration area, all Javascript files are concatenated into one URL. If Javascript is failing to work in your administration area, you can try disabling this feature:
define('CONCATENATE_SCRIPTS', false);
Because wp-config.php is loaded for every page view not loaded from a cache file, it is an excellent location to set php ini settings that control your php installation. This is useful if you don't have access to a php.ini file, or if you just want to change some settings on the fly.
Here is an example that turns php error_logging on and logs them to a specific file. If WP_DEBUG is defined to true, the errors will also be saved to this file. Just place this above any require_once or include commands.
@ini_set('log_errors','On'); @ini_set('display_errors','Off'); @ini_set('error_log','/home/example.com/logs/php_error.log'); /* That's all, stop editing! Happy blogging. */
Also released with Version 2.5, the WP_MEMORY_LIMIT option allows you to specify the maximum amount of memory that can be consumed by PHP. This setting may be necessary in the event you receive a message such as "Allowed memory size of xxxxxx bytes exhausted".
This setting increases PHP Memory only for WordPress, not other applications. By default, WordPress will attempt to increase memory allocated to PHP to 32MB (code is at beginning of wp-settings.php), so the setting in wp-config.php should reflect something higher than 32MB.
Please note, this setting may not work if your host does not allow for increasing the PHP memory limit--in that event, contact your host to increase the PHP memory limit. Also, note that many hosts set the PHP limit at 8MB.
Increase PHP Memory to 64MB
define('WP_MEMORY_LIMIT', '64M');
Increase PHP Memory to 96MB
define('WP_MEMORY_LIMIT', '96M');
The WP_CACHE setting, if true, includes the wp-content/advanced-cache.php script, when executing wp-settings.php.
define('WP_CACHE', true);
CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE are used to designated that the user and usermeta tables normally utilized by WordPress are not used, instead these values/tables are used to store your user information.
define('CUSTOM_USER_TABLE', $table_prefix.'my_users'); define('CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta');
WPLANG defines the name of the language translation (.mo) file. LANGDIR defines what directory the WPLANG .mo file resides. If LANGDIR is not defined WordPress looks first to wp-content/languages and then wp-includes/languages for the .mo defined by WPLANG file.
define('WPLANG', 'de_DE'); define('LANGDIR', 'mylanguagedirectory');
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.
First, put this in wp-config.php:
define('SAVEQUERIES', true);
Then in the footer of your theme put this:
<?php if (current_user_can('level_10')){ global $wpdb; echo "<pre>"; print_r($wpdb->queries); echo "</pre>"; } ?>
The code above uses the level_10 capability so only the administrator will see the query results.
The FS_CHMOD_DIR and FS_CHMOD_FILE define statements allow override of default file permissions. These two variables were developed in response to the problem of the core update function failing with hosts (e.g. some Italian hosts) running under suexec. If a host uses restrictive file permissions (e.g. 400) for all user files, and refuses to access files which have group or world permissions set, these definitions could solve the problem. Note that the '0755' is an octal value and is not delineated with single quotes ('). See Also: Changing File Permissions
define('FS_CHMOD_DIR', (0755 & ~ umask())); define('FS_CHMOD_FILE', (0644 & ~ umask()));
To enable SSH2 as an upgrade option you will need to install the pecl SSH2 extension. To install this library you will need to issue a command similar to the following or talk to your web hosting provider to get this installed:
pecl install ssh2
After installing the pecl ssh2 extension you will need to modify your php configuration to automatically load this extension.
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.
The following are valid constants for FTP/SSH updates:
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');
It is recommended to use a private key that is not pass phrase protected. There have been numerous reports that pass phrase protected private keys do not work properly. If you decide to try a pass phrase protected private key you will need to enter the pass phrase for the private key as FTP_PASS.
If you're still not clear on how to use SSH for upgrading or installing WordPress/plugins, read through this tutorial.
Here are additional constants that can be defined, but probably shouldn't be. The Cookie definitions are particularly useful if you have an unusual domain setup.
define('COOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('home') . '/' ) ); define('SITECOOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('siteurl') . '/' ) ); define( 'ADMIN_COOKIE_PATH', SITECOOKIEPATH . 'wp-admin' ); define( 'PLUGINS_COOKIE_PATH', preg_replace('|https?://[^/]+|i', '', WP_PLUGIN_URL) ); define('DISABLE_WP_CRON', true);
Php has a function that returns an array of all the currently defined constants with their values.
print_r(@get_defined_constants());
Be sure to check for leading and/or trailing spaces around any of the above values you entered, and DON'T delete the single quotes!
Before you save the file, be sure to double-check that you have not accidentally deleted any of the single quotes around the parameter values. Be sure there is nothing after the closing PHP tag in the file. The last thing in the file should be ?> and nothing else. No spaces.
To save the file, choose File > Save As > wp-config.php and save the file in the root of your WordPress install. Upload the file to your web server and you're ready to install WordPress!