wp-config.php is one of the few WordPress files where a small edit can change how the entire application behaves before themes and most plugins have loaded. That makes it useful for debugging and environment-specific configuration, but it also makes copied snippets unusually easy to misuse.
This guide focuses on settings that are genuinely useful in normal WordPress development and troubleshooting. It also explains what I would not put into a generic online generator: database passwords, authentication salts, site-specific paths and configuration you do not understand.
If you already know which settings you need, the WordPress wp-config.php Generator creates a reviewable snippet locally in your browser without asking you to upload your existing configuration file.
First: what wp-config.php actually does
WordPress creates wp-config.php from the installation information you provide. It normally contains database connection details, the table prefix, authentication keys and optional constants that modify WordPress behavior. Because it is loaded very early, it is also the normal place for debugging, environment and memory constants.
In a standard file, custom settings belong before the familiar “That’s all, stop editing” marker. Before changing anything, keep a copy of the working file. A PHP syntax error here can prevent both the frontend and wp-admin from loading.
1. Set WP_ENVIRONMENT_TYPE deliberately
Modern WordPress recognizes four environment types: production, staging, development and local. If nothing valid is configured, WordPress treats the environment as production.
This is more than a label. Plugins and themes can use wp_get_environment_type() to alter development-sensitive behavior. WordPress also enables WP_DEBUG automatically for the development environment when that constant has not already been defined.
A useful rule is simple: label a public live store as production, an internet-accessible test copy as staging, and developer environments as development/local. Do not mark a live site “development” just to get debug output.
2. Understand the three WordPress debug constants together
WP_DEBUG is the switch that enables WordPress debug behavior. WP_DEBUG_LOG controls logging, while WP_DEBUG_DISPLAY controls whether debug messages are printed into page output. The latter two do nothing unless WP_DEBUG is enabled.
For a development environment, seeing errors on screen can be convenient. For a public site, displaying PHP notices can expose filesystem paths and implementation details to visitors. When troubleshooting a production problem, a more controlled pattern is to log errors while keeping display disabled, then remove or disable debugging after the diagnosis.
WordPress documentation also notes that the default debug log lives under wp-content/debug.log when logging is enabled. A publicly reachable log is a security risk, so do not treat that file as permanent public storage.
Once you have collected a log, the WordPress Debug Log Analyzer can group repeated messages and surface likely plugin/theme paths locally in your browser.
3. WP_MEMORY_LIMIT is a request, not unlimited memory
WP_MEMORY_LIMIT controls the memory WordPress may request for normal operations, while WP_MAX_MEMORY_LIMIT is used for memory-intensive administrative tasks in appropriate contexts. These constants are often useful on WooCommerce, Elementor and import-heavy sites.
The important limitation is outside WordPress: your PHP configuration or hosting platform can enforce a lower ceiling. Setting WP_MEMORY_LIMIT to 512M does not force a host that caps PHP at 256M to give the process 512M.
If memory is the only problem you are diagnosing, the WordPress Memory Limit Generator explains the different configuration layers and generates the relevant snippets.
4. Limit revisions for a reason, not because the database looks large
WP_POST_REVISIONS can be a Boolean or a number. Setting a number keeps a limited set of revisions per post; setting it to false disables normal revision storage.
I prefer a sensible finite number over disabling revisions on most editorial sites. Revisions are useful when a page is accidentally overwritten, and database size is rarely solved well by removing a recovery feature without first identifying what is actually consuming space.
For frequently edited builder pages, the right limit depends on the workflow. Ten revisions may be plenty for one site and too few for another team. The key is to make the decision explicit.
5. AUTOSAVE_INTERVAL changes frequency, not revision strategy
AUTOSAVE_INTERVAL is measured in seconds. Increasing it can reduce how frequently the editor attempts autosaves, while a shorter interval can reduce the amount of work lost after a browser or connection problem.
Do not use a huge autosave interval as a general “performance optimization.” Editor autosave behavior is only one small part of WordPress workload, and a slow admin area deserves proper diagnosis rather than disabling safety features.
6. EMPTY_TRASH_DAYS controls retention
WordPress normally retains trashed content for a period before permanent deletion. EMPTY_TRASH_DAYS lets you change that interval; setting it to zero effectively removes the normal trash retention behavior.
On a client or editorial site, immediate permanent deletion is usually a poor default because it removes a useful recovery window. If storage is the concern, investigate media, backups, logs and database tables before assuming the trash is the main problem.
7. DISABLE_WP_CRON needs a replacement scheduler
WordPress’s built-in cron system is traffic-driven: normal requests can trigger checks for due events. Setting DISABLE_WP_CRON to true stops that normal spawning behavior.
This can be appropriate when a host or server cron reliably calls WordPress on a fixed schedule. It is not appropriate to simply disable WP-Cron and walk away. Scheduled posts, WooCommerce tasks, backups, email jobs and plugin maintenance can depend on scheduled events.
After changing cron behavior, verify that due events are actually running rather than assuming the server scheduler is configured correctly.
8. DISALLOW_FILE_EDIT reduces an unnecessary admin capability
DISALLOW_FILE_EDIT disables WordPress’s built-in theme and plugin file editors. On sites where code is deployed through SFTP, Git or a hosting workflow, there is usually little reason to leave browser-based PHP editing available to administrators.
This is defense in depth, not a complete security system. It does not make a compromised administrator account harmless, and it does not replace updates, strong authentication, least privilege or server security.
9. Be cautious with automatic core update constants
WP_AUTO_UPDATE_CORE can influence core automatic-update behavior, but update strategy should reflect how the site is maintained. A brochure site, a heavily customized WooCommerce store and a staging environment may reasonably use different policies.
Whichever policy you choose, backups and post-update verification matter more than copying a fashionable constant from a tutorial.
Settings I would not put into a generic generator
Database credentials
DB_NAME, DB_USER, DB_PASSWORD and DB_HOST are installation secrets or infrastructure details. There is no benefit to sending them to a third-party generator merely to wrap them in PHP.
Authentication keys and salts
WordPress uses secret keys and salts as part of its authentication security. They should be strong and random. WordPress provides its own secret-key service, and WP-CLI includes a command to shuffle salts. A static tutorial example should never become your production secret.
Blind table-prefix changes
The table prefix is not just a cosmetic string after WordPress has been installed. Changing it in wp-config.php without renaming the corresponding database tables and handling related data can break the site. It is useful during installation and in specific migrations, but it is not a one-click security tweak for an existing site.
Random performance constants
Constants copied from optimization lists can change caching, concatenation, updates, filesystem access or request behavior. Add a setting because you can explain the problem it solves and how you will verify the result—not because a checklist labels it “recommended.”
A safer wp-config.php editing workflow
- Make a fresh backup of the working configuration.
- Confirm the exact problem or behavior you want to change.
- Check whether the constant is already defined; duplicate definitions create warnings and confusion.
- Add the smallest relevant change before the stop-editing marker.
- Save and immediately test the frontend and wp-admin.
- If debugging, reproduce the original problem and inspect the resulting log.
- If changing cron, verify scheduled events actually execute.
- Remove temporary troubleshooting settings after the diagnosis.
Example: production troubleshooting without showing errors to visitors
A common temporary troubleshooting setup is to enable debugging and logging while disabling on-page display. That lets you reproduce a problem and inspect the log without deliberately printing PHP warnings into normal page output. It should still be temporary on a live site, and the log must be protected.
The WPToolix wp-config.php Generator keeps the debug controls linked: if you request logging or display, it ensures WP_DEBUG is enabled in the generated snippet rather than producing a combination that WordPress will ignore.
How to verify a wp-config.php change
Verification depends on the setting. For environment type, code can read wp_get_environment_type(). For debugging, reproduce an error and inspect the configured log. For memory, compare WordPress/PHP diagnostics rather than assuming the constant won. For cron, inspect scheduled events and confirm due jobs run. For revisions and autosave, edit a test post and observe the actual workflow.
If the site fails immediately after editing the file, restore the previous copy first. Debugging a new syntax error while the original configuration problem is still unresolved only adds another variable.
Frequently asked questions
Where is wp-config.php located?
In a typical installation it is in the WordPress root directory. WordPress also supports locating it one directory above the installation in some setups.
Where should custom constants go?
Put them before WordPress’s “That’s all, stop editing” marker in a standard configuration file.
Should WP_DEBUG be enabled on a live site?
WordPress recommends debug tools for development and staging rather than normal production use. If temporary production troubleshooting is unavoidable, avoid displaying errors to visitors, protect logs and disable the temporary settings afterward.
Does changing the wp_ table prefix secure WordPress?
A custom prefix can distinguish installations and may be chosen during setup, but it is not a substitute for proper security controls. Changing an existing site’s prefix requires coordinated database changes and should not be treated as a simple hardening trick.
Can WP-CLI manage wp-config.php?
Yes. WP-CLI provides wp config commands for creating, reading, adding, setting and deleting configuration values, and it can refresh salts. That can be preferable to manual editing in scripted development workflows.