129

Short answer: yes The answer to this question is an unequivocal yes, and to say otherwise is completely irresponsible. Long answer: a real-world example Allow me to provide a very real example, from my very real server, where moving wp-config.php outside the web root specifically prevented its contents from being captured. The bug: Take a look at this ...


45

Here is how I do it and I haven't come across anything better than this. I keep a different version of wp-config.php file under version control and then keep a file one directory above which holds all the database credentials and salts/keys. Also this way, I am able to distinguish between the type of setup I am running and do things differently on basis of ...


39

The biggest thing is the wp-config.php contains some sensitive information: your database username/password, etc. So the idea: move it outside the document root, and you don't have to worry about anything. An attacker will never be able to access that file from an external source. Here's the rub, however: wp-config.php never actually prints anything to the ...


33

This is just, how I understood the idea of the WordPress File API. If it is wrong, please downvote :) Okay. If you upload a file, this file has an owner. If you upload your file with FTP, you login and the file will be owned by the FTP user. Since you have the credentials, you can alter these files through FTP. The owner can usually execute, delete, alter ...


25

I think Max's is a knowledgeable answer, and that's one side of the story. The WordPress Codex has more advise: Also, make sure that only you (and the web server) can read this file (it generally means a 400 or 440 permission). If you use a server with .htaccess, you can put this in that file (at the very top) to deny access to anyone surfing for ...


18

I don't think there is a universal URL hook. There are a lot of hooks and I may have missed it, but I don't think there is one. You can look through the hooks at adambrown.info. There are a lot of URL hooks, but not a universal one. If I may suggest another solution: Log the errors to a files. /** * This will log all errors notices and warnings to a file ...


18

It turns out that all WP_DEBUG_LOG does is: ini_set( 'log_errors', 1 ); ini_set( 'error_log', WP_CONTENT_DIR . '/debug.log' ); So, if you want to change the log location for WP_DEBUG_LOG in a plugin or theme, webaware's answer is best. If you just want to have it changed within wp-config.php you can replace define( 'WP_DEBUG_LOG', true ); with the above 2 ...


17

Someone asked us to shine in, and I will reply here. Yes, there are security benefits from isolating your wp-config.php from the root directory of your site. 1- If your PHP handler gets broken or modified in some way, your DB information will not be exposed. And yes, I saw this happen a few times on shared hosts during server updates. Yes, the site will be ...


15

Definitely YES. When you move wp-config.php outside public directory you protect it from reading using browser when php handler gets maliciously (or accidentally!) changed. Reading your DB login/password is possible when server is hardly infected through a fault of lame administrator. Charge the administrator a fine and get a better-tended and more ...


15

What's the risk? On a poorly configured shared host, every customer's PHP will execute as the same user (let's say apache for discussion). This setup is surprisingly common. If you're on such a host and use WordPress to install the plugin using direct file access, all of your plugin files will belong to apache. A legitimate user on the same server would ...


14

The "Hardening WordPress" page of the Codex contains a section on "Securing wp-config.php". It includes changing the permissions to 440 or 400. You can also move the wp-config file one directory up from the root if your server configuration allows for that. Of course there is some danger to having a file with the password like this if someone gets access to ...


14

You have probably added the definitions too late. If in fact you added that "to the end" of wp-config.php then you added it after these lines: /** Sets up WordPress vars and included files. */ require_once(ABSPATH . 'wp-settings.php'); If so, then those constants are already defined (wp_initial_constants) and you cannot redefine a constant after it is ...


13

It's not clear from your question what you are changing in each of these files, but I presume in each case it is the upload_max_filesize PHP setting. In general, settings will be applied in this order, each over-riding the previous value: php.ini Apache directives in .htaccess calls to ini_set() However, this setting is defined as PHP_INI_PERDIR, which as ...


11

There is, as far as I know, no way to hook into wp-config.php from a Theme. For one, wp-config.php shouldn't be writeable; for another, wp-config.php is executed well-before a Theme's functions.php file is parsed. For a great overview of how WordPress boots, have a look at this two-part post by Theme.FM (part 1, part 2) or this Explanation with a flowchart ...


11

There are two defines in wp-config.php of WordPress website: define('DB_CHARSET', 'utf8'); define('DB_COLLATE', ''); There are several things which are most commonly misunderstood. Names of constants in those defines, might suggest that they are related to the database itself. They are not. They are related to tables within the database. ...


10

Using the defines the user sets in wp-config: mysql_connect(DB_HOST, DB_USER, DB_PASSWORD); EDIT: Since your script is outside the Wordpress environment, what you want to do is initiate it before using the defines in wp-config. require_once('./path/to/the/wp-config.php'); mysql_connect(DB_HOST, DB_USER, DB_PASSWORD);


10

try to use get_temp_dir() to see if wordpress is using your WP_TEMP_DIR constant. i've tried this code in wp-config.php and it works define('WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/'); but you have to put it before the /* That's all, stop editing! Happy blogging. */ in your wp-config.php file.


9

To make a case for keeping your config file one level up from the web root (as mrwweb suggested): a few months ago, an automatic update on a production server of ours killed php but left apache running. So everyone coming to the homepage was being offered index.php as a download. In theory, anybody who knew it was a WordPress site could have requested wp-...


9

How can I do this without exposing my passwords to git, in case this repository ever becomes public? If your wp-config.php file is in version control, then any passwords it contains will also be in version control. The only way to avoid that is to not put the file in version control. Is this too much trouble and should I just leave wp-config.php ...


9

Even though my first approach was for the garbage bin and s_ha_dums answer is a clean, and probably the best, way of going about it, let me offer one more working scenario: The following sets a cookie that is valid for the next 24 hours (86400 seconds) when an administrator logs into the system. In wp-config.php, the constant WP_DEBUG is conditionally ...


9

localhost refers to the machine it's running on. For example on my own site tomjn.com localhost is 127.0.0.1 as it always is. This doesn't mean the hacker doesn't know where to connect, it means the hacker replaces localhost with tomjn.com. Of course if I have a proxy sitting in front this won't work, but keep in mind that if the attacker has access to my ...


8

I just want to clarify, for the sake of argument, that moving your wp_config.php file does not necessarily mean you have to move it only to the parent directory. Let's say you have a structure like /root/html, where html contains the WP installation and all of your HTML content. Instead of moving wp_config.php to /root, you could move it to something like /...


8

Why do you need this? In wp-config you can set defines. They will be accesible everywhere without needing to use globals. Define something: define('MY_DEFINE_NAME', 'THE_VALUE');. Then in your templates you can show the value like this: echo MY_DEFINE_NAME; Or set the value to a variable: $var = MY_DEFINE_NAME;.


8

The best way is to not do that. There's no need for a plugin file to ever include the wp-config.php. You're doing it backwards. WordPress loads plugins. Plugins don't load WordPress.


7

I know it's old but I fixed it! i installed WP MU in a subfolder. htaccess: RewriteEngine On RewriteBase /YOUR_SUBFOLDER RewriteRule ^index\.php$ - [L] # add a trailing slash to /wp-admin RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L] RewriteCond %{REQUEST_FILENAME} -f [OR] RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^ - [L] RewriteRule ...


7

The best way to do it is to use URL Rewrites. This way you'll not have to do any change before uploading CODE to your server back again. Try the following CODE in your .htaccess file: <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / # custom rules for loading server images or any other uploaded media files RewriteCond %{REQUEST_FILENAME} !-f ...


6

You'll want to add these to your wp-config.php file: define( 'NOBLOGREDIRECT', '' ); define( 'WP_HOME', 'http://dev.domain.com' ); define( 'WP_SITEURL', 'http://dev.domain.com' ); So in its entirety, you'll have: $base = '/'; /** Multisite / Wordpress Network **/ define( 'WP_HOME', 'http://dev.domain.com' ); define( 'WP_SITEURL', 'http:...


6

For me it was changing old domain entries in database tables wp_blogs and wp_site to the new domain of the multisite's main domain. I haven't done this after the migration to a new domain.


6

This error is generated in wp-login.php , it happens if server is unable to set cookies, this can happen due to several reasons, one of the common issue is: output being sent before setting up of cookies. Try out following options: Update WordPress core, if it is not up to date change theme, if you are using custom theme, just ftp into server and delete ...


6

Check your wp-config.php file for lines like: define( 'WP_SITEURL', 'https://example.com' ); define( 'WP_HOME', 'https://example.com' ); Also check your database's {prefix}_options table: SELECT * FROM wp_options WHERE option_name='siteurl' OR option_name='home'; ...assuming that your database's prefix is wp_.


Only top voted, non community-wiki answers of a minimum length are eligible