wp-config.php Generator for Stores
Store-ready memory, cron, debug and security constants, each with a plain-English explanation, plus freshly generated authentication salts.
Your details
wp-config.php snippet
<?php
// Paste these above the "/* That's all, stop editing! */" line in wp-config.php.
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
define( 'WP_DEBUG', false );
define( 'DISABLE_WP_CRON', true );
// Then add a real cron job hitting: wget -q -O /dev/null 'https://yourstore.com/wp-cron.php?doing_wp_cron' every 5-15 minutes.
define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 120 );
define( 'EMPTY_TRASH_DAYS', 30 );
define( 'DISALLOW_FILE_EDIT', true );
define( 'FORCE_SSL_ADMIN', true );
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
define( 'WP_CACHE', true );
define( 'WP_ENVIRONMENT_TYPE', 'production' );
// Authentication unique keys and salts.
define( 'AUTH_KEY', '98W0i%8t]FSXF}PN]+6>VHD>EceO8)vM5K{jJhqj2ojCA6fjyycYzIQ)*YQP>vsV' );
define( 'SECURE_AUTH_KEY', 'q3wV)YYb[d6kz]gA^j}%ujqF&y?x?RQts>BAjA[!S>VW4Bn{rw(GCek8+ov5]f+}' );
define( 'LOGGED_IN_KEY', '>8SKZR852th]I)f[[eNJZ{_~G^)=mknW]z7q^*F>IVioj4dMqbRD-wCjYM!h0JJ>' );
define( 'NONCE_KEY', '6zsIDD!jJGCQ<syUOWOb^{dmQ9ia}V]JgLORD6Nq+#[p_zaw[L3G6K48wXg8_=ng' );
define( 'AUTH_SALT', 'f80q<30+dPiHHYME}G-XkMlok_8x#pR9&OV[B67hNV60ScnEurfAG65mAFM6OyQV' );
define( 'SECURE_AUTH_SALT', '}O+LQOa81R+DMWgtPDOAAe!QN!E8j#jKfWgygmBdKGo4v5_H)2!E0}a^3onB3RX)' );
define( 'LOGGED_IN_SALT', 'c6}OQyYBiQ=rTko-s*vb[(NV!bO-RVq3iuvhvU4Q8N5lCqOifLAy]5H9Xr?#eF#R' );
define( 'NONCE_SALT', '!lHhY=c-jCB0Li6z5aCjXvl[A6z4*MW*b}VA<Q(1n(h!8>]s=1n!i9?jjLv%uE{0' );
Changing AUTH/SALT keys on a live site logs every currently signed-in user (including customers with a saved session) out at once. That's expected and safe.
Constants checked against developer.wordpress.org/apis/wp-config-php/.
These keys were generated in your browser and never sent anywhere. Re-run the generator any time you want a fresh set.
What each constant does
wp-config.php is where WordPress's own behavior gets configured before the database is even touched: memory limits, whether errors are logged or shown, how cron runs, and eight authentication keys used to sign cookies and nonces. Every constant this tool generates is checked against WordPress's own wp-config.php reference.
- WP_MEMORY_LIMIT / WP_MAX_MEMORY_LIMIT: the PHP memory ceiling for normal pages, and a higher one for admin screens (imports, plugin updates).
- DISABLE_WP_CRON: turns off WordPress's page-load-triggered cron, meant to be paired with a real system cron hitting wp-cron.php on a schedule.
- DISALLOW_FILE_EDIT / DISALLOW_FILE_MODS: turn off the wp-admin theme/plugin code editor, and optionally installs and updates from wp-admin entirely.
- AUTH_KEY and the other seven keys and salts: random strings WordPress uses to sign cookies and nonces. Changing them logs every signed-in session out at once, including customers with a saved cart session.
Using it
- 01
Generate
Set the toggles for your store, and turn on "Generate random authentication keys and salts" for a fresh set made in your browser.
- 02
Paste it in
Add the snippet above the "/* That's all, stop editing! */" line in wp-config.php.
- 03
Confirm it loaded
Check wp-admin → Tools → Site Health → Info, or
wp eval 'var_dump(WP_MEMORY_LIMIT);'over WP-CLI.
Pitfalls
- Some managed WordPress hosts define these constants themselves and don't allow overriding them; check with your host if a change doesn't seem to take effect.
- Turning on DISALLOW_FILE_MODS disables the plugin/theme update screens too, not just installs, so only use it if you deploy code another way.
- The salts generated here run entirely in your browser and are never sent anywhere, but treat wp-config.php itself like any other secret: keep it out of version control, or use environment variables if your host supports them.
Questions people ask
Why does changing the salts log everyone out?
WordPress uses those keys to sign login and session cookies. Change the keys and every previously issued cookie stops validating, which safely (if abruptly) logs out anyone currently signed in, staff and customers alike.
What memory limit does WooCommerce actually need?
WooCommerce's own documented minimum is 256 MB. Larger catalogs, more plugins or a heavy page builder often need more; see the hosting requirements calculator for an estimate based on your store.
Should I turn on WP_DEBUG on my live store?
No, leave it off on production. Turn it on temporarily (with display off and logging on) only while actively troubleshooting, then turn it back off.
What's WP_ENVIRONMENT_TYPE for?
It's a WordPress core constant plugins and themes can check to behave differently on production versus staging or local, for example skipping analytics or live payment gateways outside production.
Related tools
Want this builtinto your store?
I'm Emmanuel, a Shopify and WooCommerce developer. If this tool pointed at something you'd rather have fixed for you (a faster store, cleaner product data, a migration, a custom feature), send me a note.
Emmanuel Asika
Shopify & WooCommerce developer, Dublin
I build and fix online stores: new builds, migrations, speed, SEO and the custom bits apps can't do.
Last reviewed 30 September 2026.
Sources: WordPress Developer Resources: wp-config.php · WordPress Developer Resources: wp_get_environment_type()