How to Edit wp-config.php Safely: Changes and Mistakes to Avoid

Somebody in a forum told you to "just add a line to wp-config.php" and now you're staring at a file you've never opened, wondering which line and whether one typo is going to take the whole site down. Fair worry — a stray character in this file is one of the fastest ways to turn a working WordPress install into a blank white page. Here's what's actually safe to change, what each setting does, and how to undo it if you get it wrong.

Where wp-config.php Actually Lives

On a Getwebup cPanel account it sits in the WordPress root — usually public_html/wp-config.php, or public_html/yourdomain.com/wp-config.php if the site is in a subfolder or addon domain. Open it through File Manager → Settings → Show Hidden Files isn't needed (it's not a dotfile), or connect over SFTP and edit it with a real code editor instead of a browser textarea — you'll catch bracket and quote mistakes faster that way.

It's plain PHP, so every rule of PHP syntax applies: matching quotes, a semicolon at the end of each line, and nothing after the closing ?> tag (many default files skip that tag entirely — don't add it back).

Before You Touch Anything

Copy the file first. Seriously — this takes ten seconds and saves you a support ticket.

cp public_html/wp-config.php public_html/wp-config.php.bak

If you're in File Manager instead of SSH, right-click the file → Copy, and rename the copy. When something breaks, you restore this copy and you're back to a working site in under a minute, no matter what the actual bug was.

The Changes People Actually Make

1. Raise the PHP Memory Limit

This is the most common edit, usually triggered by "Allowed memory size exhausted" errors during imports or with heavy page builders. Add this above the line that says /* That's all, stop editing! */:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WP_MEMORY_LIMIT covers the front end, WP_MAX_MEMORY_LIMIT covers wp-admin. Neither of these overrides your hosting account's actual PHP memory cap — if cPanel's PHP settings or MultiPHP INI Editor cap you at 128M, raising the WordPress constant past that does nothing. Check MultiPHP INI Editor first.

2. Turn On Debug Mode Without Exposing Errors to Visitors

Everyone knows WP_DEBUG, fewer people know it shouldn't print errors straight onto a live page. Use this combination instead:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

This writes everything to wp-content/debug.log instead of the screen. Read the log, find the culprit, then set WP_DEBUG back to false — leaving debug mode on permanently slows the site and leaks file paths to anyone who checks the page source.

3. Force SSL on the Login and Admin Area

If your padlock is fine on the front end but wp-admin sometimes loads over plain HTTP (common after a migration or when a caching layer sits in front of the site):

define( 'FORCE_SSL_ADMIN', true );

Only add this once you've confirmed the SSL certificate is actually installed and working (check in cPanel → SSL/TLS Status). Adding it before the cert is live locks you out of wp-admin with a redirect loop.

4. Lock Down File Editing

The Appearance → Theme Editor and Plugins → Editor screens let anyone with admin access rewrite PHP files from the browser — a favorite move for attackers who've guessed a weak password. Turn it off:

define( 'DISALLOW_FILE_EDIT', true );

For a stricter setup that also blocks plugin/theme installs and updates from wp-admin (useful if you manage code through Git or SFTP only):

define( 'DISALLOW_FILE_MODS', true );

5. Fix a WP_HOME / WP_SITEURL Mismatch

If the site redirects to the wrong domain or a staging URL after a migration, and the Settings → General screen won't save because it's stuck in a loop, hardcode the correct URLs:

define( 'WP_HOME', 'https://www.yourdomain.com' );
define( 'WP_SITEURL', 'https://www.yourdomain.com' );

These override whatever is in the wp_options table, so they're a reliable way to break a redirect loop without touching the database directly.

6. Control Automatic Updates

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Use 'minor' for security-patch-only updates (the sane default), true for every core update including majors, or false to disable core auto-updates entirely — not recommended unless you're testing every release manually before it touches production.

Quick Reference

What Actually Causes the White Screen

Almost never the setting itself — it's the syntax around it. The usual suspects:

• A missing semicolon at the end of a define() line.
• Curly or "smart" quotes pasted in from a Word doc or a website instead of straight quotes (' not ’).
• Adding a new line after /* That's all, stop editing! */ instead of before it — it usually still works, but it's easy to lose track of what you added later.
• A stray closing ?> tag with a blank line or space after it, which sends invisible output before WordPress can set headers and triggers "headers already sent" warnings.
• Defining the same constant twice — PHP throws a fatal error on redeclaration.

If You've Already Broken It

Blank white page, no error visible? You've probably got a fatal syntax error and WP_DEBUG_DISPLAY was off (or the error happened before WordPress even loaded that far). Recover in this order:

1. Restore the backup. Rename wp-config.php.bak back to wp-config.php in File Manager and the site is back immediately.
2. No backup? Compare against a fresh wp-config-sample.php from the same WordPress version — download it, copy your database credentials and keys across from the broken file line by line, and rebuild it clean.
3. Check the PHP error log in cPanel → Metrics → Errors, or your app's error log path, for the exact line number PHP choked on — much faster than eyeballing the whole file.

Prevention Checklist

• Always copy the file before editing it — every time, not just the first time.
• Edit with a real text editor over SFTP, not a plain browser textarea, so you get syntax highlighting.
• Add one constant, save, reload the site, confirm it still loads — then move to the next change. Don't batch five edits and test once.
• Keep DISALLOW_FILE_EDIT on so a compromised admin account can't use the same trick against you.
• Never commit real database passwords or secret keys to a public Git repo if you're managing wp-config.php through version control — use a separate untracked config or environment variables instead.