Gutenberg: [package] env Can't change the WordPress Database Table Prefix

[andygagnon]

When using wp-env, we can't change the WordPress Database Table Prefix. We are locked into the table prefix 'wp_'.

Can we control the table prefix with the Docker variable WORDPRESS_TABLE_PREFIX?
Could we set this Environment variable in .wp-env.json?

Is there a Docker command to set this Environment variable in docker-compose.yml file, via the command line?

Thanks for your time

[noahtallen]

@andygagnon you can set any wp-config value via the config option in .wp-env.json:

{
  "plugins": [ "." ],
  "config": {
    "WORDPRESS_TABLE_PREFIX": "something"
  }
}

wp-config values are set after the WordPress install. I'm not sure if that will cause issues with setting the table prefix or not; I haven't done that before.

[noahtallen]

This isn't Docker env variables, btw, but that might be interesting to expose in the future. 🤔

[andygagnon]

@noahtallen I tried changing the table prefix in via config values and it didn't work.

Tested this with,
$ wp-env run cli 'wp eval echo"".$GLOBALS["table_prefix"];'

after wp-env start and your .json config example.

In wp-config.php the table prefix is a PHP variable, $table_prefix, not a DEFINE. That may be why it doesn't work.

Another approach? Seems like Docker would give us the leverage we need here. Thanks.

[noahtallen]

cc @epiqueras, any ideas? We'd either need to A) support non-define wp-config values or B) do it through environment variables and docker. Or C) expose wp-config.php directly. (or some other thing I'm not thinking of.)

[epiqueras]

WORDPRESS_TABLE_PREFIX is an environment variable used by the WordPress image. WordPress itself does not treat it as a config variable. Supporting Docker environment variables can get sticky because there are multiple containers, and you might not want them defined in all of them.

@andygagnon I am curious as to what the use case for this is.

@noahtallen, I think we need a command that gives you the path of the WordPress installation so that you can edit wp-config.php directly for things like this. I find myself looking it up manually quite often.

[noahtallen]

If you don't specify the core source, the wp-config will only be available in the docker image. :/

[epiqueras]

People can always use mappings in those cases.

[andygagnon]

@epiqueras use case is I would like to test a custom plugin, or new version of a plugin/core on a local install of a website that is currently in production.

After building the docker install, with required plugins, I pull in the production database (via MigrateDBPro, or other tools). The production database has good security and uses a non-standard table prefix. The docker install can't see the database tables with the custom table prefix.

Thanks for your time.

[epiqueras]

Try using the mappings option to use your own custom wp-config.php.

{
    // ...
    "mappings": {
        "wp-config.php": "./path/to/wp-config.php"
    }
}

[andygagnon]

@epiqueras the mappings option almost worked. It read wp-config.php but failed with an error,
✖ Error while running docker-compose command.
No container found for wordpress_1

Solution: I used the "core" option with a local copy of WordPress. Docker then creates a wp-config.php file there, where I can change $table_prefix and restart. Works. Thanks.

[epiqueras]

Error while running docker-compose command.

@noahtallen Any idea why that could have happened? It seems to work for me.

[noahtallen]

The wordpress install step seems like the most likely candidate for an issue with mapping the wp-config file. But I'm really not sure. :/

[andygagnon]

Still trying to get mapping to work @epiqueras @noahtallen
Getting an new error,
'mysqlcheck: Got error: 1049: Unknown database 'wordpress' when selecting the database'

here are my .wp-env.json wp-config.php files
Am I missing something?
Thanks.

{
"core": null,
"plugins": [
"https://downloads.wordpress.org/plugin/insert-headers-and-footers.zip"
],
"mappings": {
"wp-config.php": "./config/wp-config.php"
}
}

/**

• The base configuration for WordPress
  *
• The wp-config.php creation script uses this file during the
• installation. You don't have to use the web site, you can
• copy this file to "wp-config.php" and fill in the values.
  *
• This file contains the following configurations:
  *
• 
  
  • MySQL settings
  
  
• 
  
  • Secret keys
  
  
• 
  
  • Database table prefix
  
  
• 
  
  • ABSPATH
    
    *
  
  
• @link https://wordpress.org/support/article/editing-wp-config-php/
  *
• @package WordPress
  */

// * MySQL settings - You can get this info from your web host * //
/** The name of the database for WordPress */
define( 'DB_NAME', 'wordpress');

/** MySQL database username */
define( 'DB_USER', 'root');

/** MySQL database password */
define( 'DB_PASSWORD', '');

/** MySQL hostname */
define( 'DB_HOST', 'mysql');

/** Database Charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '');

/**#@+

• Authentication Unique Keys and Salts.
  *
• Change these to different unique phrases!
• You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
• You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
  *
• @since 2.6.0
  */
  define( 'AUTH_KEY', '3d230970ba8e168f00bef8034c0b51e40127eca8');
  define( 'SECURE_AUTH_KEY', '48cb0f83d6d21fd285822cc3588ba1ac37ef6be0');
  define( 'LOGGED_IN_KEY', '4382e2aa28612e4f24e87b50b7ddc70df2ec1a9f');
  define( 'NONCE_KEY', 'a9175b5def8d86eb4f34fedfc952f1036fdaa1b4');
  define( 'AUTH_SALT', 'f5b285f6b93192d2395fd634922010c72a84b31a');
  define( 'SECURE_AUTH_SALT', 'caba85e38b77cfd728e244a319f8054d9893dc47');
  define( 'LOGGED_IN_SALT', '2ea794bcc0ff10fd9247b78194996a24b48a856a');
  define( 'NONCE_SALT', 'a2b778cd2db6f7ed62852bdaeaf8b5f3a4cf8251');

/*#@-/

/**

• WordPress Database Table prefix.
  *
• You can have multiple installations in one database if you give each
• a unique prefix. Only numbers, letters, and underscores please!
  */
  $table_prefix = 'wp_';

/**

• For developers: WordPress debugging mode.
  *
• Change this to true to enable the display of notices during development.
• It is strongly recommended that plugin and theme developers use WP_DEBUG
• in their development environments.
  *
• For information on other constants that can be used for debugging,
• visit the documentation.
  *
• @link https://wordpress.org/support/article/debugging-in-wordpress/
  */
  define( 'WP_DEBUG', true );

// If we're behind a proxy server and using HTTPS, we need to alert WordPress of that fact
// see also http://codex.wordpress.org/Administration_Over_SSL#Using_a_Reverse_Proxy
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}

/* That's all, stop editing! Happy publishing. */

/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', __DIR__ . '/' );
}

/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';

[Chrillaz]

Off topic perhaps.
But an interesting approach found on mysql image docs on docker hub https://hub.docker.com/_/mysql/

If an sql dump could be mounted to de sql container through perhaps a "db" mappings in .wp-env.json.

Dump.sql: /docker-entrypoint-initdb.d.

And also be able to set db env vars like MYSQL_DB_USER, MYSQL_DB_NAME, MYSQL_DB_PASSWOR, TABLEPREFIX.

As for mariadb docker-entrypoint-initdb.d. Is also referensed under "Initializing a fresh instance" in Their docs https://hub.docker.com/_/mariadb