The wp-config.php file is the most powerful configuration file in WordPress, but most developers only use it for database credentials and debug mode. Buried in the WordPress core are dozens of constants and settings that control everything from memory allocation to automatic updates, cookie behavior, and trash management.
This guide covers 15 wp-config.php settings that go beyond the basics. These are the tweaks that experienced WordPress developers use to harden security, improve performance, and control site behavior at the lowest level.
How wp-config.php Works
WordPress loads wp-config.php before anything else. It runs before plugins, before the theme, before the database connection is even established. This makes it the earliest intervention point in the WordPress boot process. Constants defined here cannot be overridden by plugins or themes, which is what makes them so useful for enforcing site-wide settings.
The file sits in the WordPress root directory by default, but WordPress also checks one directory above the root. Moving wp-config.php above the web root is a common security practice that prevents direct access via URL.
Performance Settings
1. Increase PHP Memory Limit
WP_MEMORY_LIMIT controls the maximum memory available to PHP during frontend page loads. WP_MAX_MEMORY_LIMIT controls the memory limit for admin-side operations like media uploads, plugin installations, and bulk actions.
The default is 40MB for the frontend and 256MB for admin. If you are running WooCommerce, BuddyPress, or any plugin that processes large datasets, increase both values. Your hosting environment must also allow these limits at the server level for the constants to take effect.
2. Control Post Revisions
WordPress stores every saved version of every post and page by default. On a site with 500 posts and an average of 20 revisions each, that is 10,000 extra rows in the database. Setting this constant limits revisions to a fixed number per post.
Set it to false to disable revisions entirely, or to a specific number like 3 or 5 to keep a reasonable history without database bloat. For a deep dive into managing revisions, see our guide on how to limit and clean up WordPress post revisions.
3. Change the Autosave Interval
The WordPress editor autosaves content every 60 seconds by default. Each autosave triggers an AJAX request to the server and creates a revision. On sites with many concurrent editors, this generates significant database and server load.
Setting the interval to 120 or 180 seconds reduces the frequency without sacrificing too much safety. For high-traffic editorial sites, this small change can noticeably reduce admin-ajax.php load.
4. Empty the Trash Automatically
WordPress keeps trashed posts for 30 days before permanent deletion. On content-heavy sites where editors delete drafts frequently, the trash accumulates and adds to database queries. Setting this to 7 days keeps the database cleaner. Set it to 0 to disable the trash entirely and delete posts immediately, but be careful because there is no recovery from an immediate delete.
Security Settings
5. Disable the File Editor
The built-in theme and plugin editor in wp-admin is a security liability. If an attacker gains admin access, they can inject malicious code directly through the editor without needing FTP or SSH access. This constant removes the editor entirely from the admin interface.
Every production site should have this set to true. There is no legitimate reason to edit theme or plugin files through the browser on a live site.
6. Disable Plugin and Theme Installation
This goes further than DISALLOW_FILE_EDIT. It prevents all file modifications through the WordPress admin, including plugin and theme installations, updates, and deletions. This is appropriate for production environments where deployments happen through Git, CI/CD, or manual file transfers.
Be aware that this also disables automatic security updates. If you use this constant, you need a separate process for applying updates.
7. Force SSL on Admin and Logins
This constant forces HTTPS on all admin pages and the login screen. Even if the rest of your site runs on HTTP (which it should not in 2026), this ensures that admin credentials and session cookies are always transmitted over encrypted connections.
With most hosts providing free SSL certificates through Let’s Encrypt, there is no reason not to run the entire site on HTTPS. But this constant acts as a safety net for the most sensitive pages.
8. Set Custom Authentication Keys and Salts
These eight constants encrypt the data stored in user cookies. If they are set to the default “put your unique phrase here” or left empty, your authentication cookies are weakened significantly.
Generate unique values using the WordPress salt generator API at https://api.wordpress.org/secret-key/1.1/salt/. Changing these values invalidates all existing login sessions, which is useful if you suspect a security breach and need to force all users to re-authenticate.
9. Block External HTTP Requests
WP_HTTP_BLOCK_EXTERNAL prevents WordPress from making any outbound HTTP requests. This stops plugins from phoning home, blocks update checks for unlicensed plugins, and prevents data leakage to third-party services.
Use WP_ACCESSIBLE_HOSTS to whitelist specific domains that WordPress needs to contact, like the WordPress.org API for core updates. This is a powerful security measure for sites that need strict outbound traffic control.
Database and Content Settings
10. Change the Database Table Prefix
The default wp_ prefix makes your database tables a predictable target for SQL injection attacks. Changing the prefix to something unique adds a layer of obscurity. This is not security by itself, but it eliminates one of the first things automated attack scripts look for.
Set this before installing WordPress. Changing it on an existing site requires updating every table name and several rows in the options and usermeta tables. For existing sites, use WP-CLI search-replace to handle the migration safely.
11. Control the WordPress Cron System
WordPress runs its cron system on every page load. A visitor hits your site, and WordPress checks if any scheduled tasks need to run. On high-traffic sites, this means the cron check happens thousands of times per hour, wasting resources.
Disabling the built-in cron and replacing it with a real server cron job is a standard performance optimization. Set up a system cron that hits wp-cron.php every 5 or 15 minutes:
This gives you predictable task execution without the overhead of checking on every page load.
12. Set the Autosave and Recovery Timeout
This constant sets the minimum interval between cron executions in seconds. The default is 60 seconds. On sites where cron tasks are heavy (email queues, scheduled posts, import jobs), increasing this prevents overlapping cron runs that can cause duplicate processing or database locks.
Development and Debugging Settings
13. Configure Debug Logging Without Display
This combination enables full debugging on production or staging without exposing errors to visitors. Errors are written to wp-content/debug.log instead of being displayed on screen. SCRIPT_DEBUG forces WordPress to load unminified JavaScript and CSS files, which is essential for debugging frontend issues.
For a complete walkthrough of debug logging, including custom log functions and log rotation, see our WordPress debug log guide.
14. Control Automatic Updates
AUTOMATIC_UPDATER_DISABLED turns off all automatic updates: core, plugins, themes, and translations. This gives you complete control over when updates happen.
The more nuanced approach is WP_AUTO_UPDATE_CORE, which accepts three values: true (all core updates), false (no core updates), or 'minor' (only security and minor updates). The 'minor' setting is the recommended approach for most production sites because it allows critical security patches while preventing major version upgrades that could break compatibility.
15. Set a Custom Content Directory
Renaming the wp-content directory breaks assumptions that automated attack tools and malware scanners rely on. Instead of the standard /wp-content/ path, your themes, plugins, and uploads live under a custom directory name.
This requires that all themes and plugins use WP_CONTENT_DIR and content_url() instead of hardcoded paths. Well-coded plugins handle this correctly, but test thoroughly before deploying this change. It also complicates server-level rules that reference wp-content specifically.
The wp-config.php file runs before plugins, before the theme, before the database connection is even established. This makes it the earliest intervention point in the WordPress boot process, and constants defined here cannot be overridden.
Best Practices for wp-config.php Management
- Keep wp-config.php out of version control. Add it to your
.gitignoreand use environment-specific configs. Database credentials and salts should never be committed to a repository. - Use environment variables for sensitive data. Instead of hardcoding database passwords, pull them from environment variables:
define( 'DB_PASSWORD', getenv( 'WP_DB_PASSWORD' ) ); - Move it above the web root. WordPress automatically checks one directory above the installation root for wp-config.php. Moving it there prevents direct URL access to the file.
- Set restrictive file permissions. The file should be readable by the web server but not writable. Set permissions to
440or400on Linux servers. - Document your changes. Add comments explaining why each non-default constant is set. Future developers (including yourself) will thank you when debugging an issue months later.
For related performance tuning at the database level, see our guide on fixing wp_options autoload bloat, which covers another common source of WordPress slowdowns.
Quick Reference Table
| Constant | Purpose | Recommended Value |
|---|---|---|
WP_MEMORY_LIMIT | Frontend memory limit | 256M |
WP_MAX_MEMORY_LIMIT | Admin memory limit | 512M |
WP_POST_REVISIONS | Limit stored revisions | 5 |
AUTOSAVE_INTERVAL | Editor autosave frequency | 120 |
EMPTY_TRASH_DAYS | Trash auto-empty period | 7 |
DISALLOW_FILE_EDIT | Disable code editor | true |
DISALLOW_FILE_MODS | Block all file changes | true (production) |
FORCE_SSL_ADMIN | Force HTTPS on admin | true |
WP_HTTP_BLOCK_EXTERNAL | Block outbound requests | true (with whitelist) |
DISABLE_WP_CRON | Disable page-load cron | true (use server cron) |
WP_DEBUG | Enable debug mode | true (staging only) |
WP_DEBUG_LOG | Log errors to file | true |
WP_DEBUG_DISPLAY | Show errors on screen | false |
WP_AUTO_UPDATE_CORE | Control core updates | minor |
WP_CONTENT_DIR | Custom content directory | Site-specific |
Frequently Asked Questions
Where is wp-config.php located?
By default, wp-config.php is in the WordPress root directory (the same directory as wp-admin and wp-includes). WordPress also checks one directory above the root, so you can move it there for added security. If wp-config.php exists in both locations, WordPress uses the one in the root directory.
Can I break my site by editing wp-config.php?
Yes. A syntax error in wp-config.php will take down the entire site because it loads before everything else. Always keep a backup of the file before making changes, and test on a staging environment first. If you do break it, fix the syntax error via FTP or SSH to restore the site.
Do these constants work with all hosting providers?
Most constants work everywhere. However, managed WordPress hosts may override certain settings at the server level. Memory limits, file modification restrictions, and cron settings are commonly managed by the host. Check with your hosting provider if a constant does not seem to take effect.
Should I use all 15 of these settings?
No. Use the ones that apply to your situation. Every production site should have DISALLOW_FILE_EDIT, FORCE_SSL_ADMIN, and unique authentication keys. Performance settings like revision limits and cron configuration depend on your site’s size and traffic. Debug settings should only be active on staging or development environments.
How do I reset wp-config.php to default?
Download a fresh copy of WordPress from wordpress.org. The wp-config-sample.php file in the download contains the default template. Copy it, add your database credentials and authentication keys, and upload it as wp-config.php. Your site will revert to all default WordPress settings.
The wp-config.php file is the most direct way to control WordPress behavior. Every constant listed here is documented in the WordPress developer handbook, but few developers take the time to review what is available. Start with the security settings on every production site, then add performance tweaks based on your specific needs.
Security Hardening WordPress configuration WordPress developer tips WordPress Performance wp-config.php
Last modified: February 24, 2026
