wp-config-sample.php is not usable as a live config without filling placeholders

[alijah06]

This is the standard WordPress wp-config.php template, mostly unmodified — but there are a few real issues:

1. Placeholder credentials never filled in

   define( 'DB_NAME', 'database_name_here' );
   define( 'DB_USER', 'username_here' );
   define( 'DB_PASSWORD', 'password_here' );
   

These are still the sample values. As-is, this file will fail to connect to any real database. This needs to be replaced with actual credentials before the site will work.

2. Placeholder secret keys/salts — a real security problem

   define( 'AUTH_KEY',         'put your unique phrase here' );
   ...
   define( 'NONCE_SALT',       'put your unique phrase here' );
   

These are meant to be long, random, unique strings. Leaving them as literal placeholder text means:

• Session/auth cookies are far more predictable/forgeable.
• If this exact file is ever reused across sites (or checked into a public repo), all sites share the same "secret," making cookie forgery trivial.

Generate real values from the ​WordPress.org secret-key service or via wp config shuffle-salts (WP-CLI).

3. CONCATENATE_SCRIPTS defined too early, and questionable value

   define( 'CONCATENATE_SCRIPTS', false );
   

This is placed *before* the file's docblock/header and before ABSPATH is even set up — it works functionally since define() doesn't care about surrounding comments, but it's an unusual/fragile spot to put a custom constant (normally these go in the "Add any custom values" section below). Setting it to false also disables JS/CSS concatenation in the admin, which hurts admin dashboard performance — this is usually a temporary debugging aid, not something you want permanently in production.

4. WP_DEBUG is false with no companion debug-logging setup

Not a bug per se, but worth noting: if this is a dev/staging environment, you'd typically want:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

so errors are logged to a file instead of either being silently swallowed or (worse) displayed on a live site.

5. No DISALLOW_FILE_EDIT / hardening constants

Not a "bug," but commonly paired with this file for production security (e.g., disabling the plugin/theme file editor, forcing SSL for admin/login).

Summary: The file is structurally correct WordPress boilerplate, but it is not safe to deploy as-is — the unfilled DB_* credentials will break the DB connection, and the unfilled AUTH_KEY/*_SALT placeholders are a genuine security weakness, not just a style nit.