Both CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE are not checked for non empty string

[ramon fincken]

Hardly used but they can still be in error.

This patch tests for typing and non-false string value.

Trac ticket: https://core.trac.wordpress.org/ticket/65709

## Use of AI Tools
NO LLM used at all

[apermo]

Hey @ramon-fincken

I have checked how other wp-config constants are handled.

None have a _doing_it_wrong() route if a misconfiguration occurs.

Only WP_ENVIRONMENT_TYPE, WP_DEVELOPMENT_MODE, WP_DEFAULT_THEME, WP_POST_REVISIONS and WP_AUTO_UPDATE_CORE come with a check at all. Any other will just silently fail.

It would make sense to add some kind of debug tooling for the other constants to show better error messages, this but I do not think that adding a correctness check here is the right way. Especially it would be unprecedented to use _doing_it_wrong() here. The other checks either end in a wp_die() or silently cast to a default.

On top this feature was added back in WP 1.5/2.0 by Matt back in 2005 in https://core.trac.wordpress.org/changeset/2205 and https://core.trac.wordpress.org/changeset/2632/.
According to @garyj the idea of the feature was a bridge to other systems existing user tables, or a regular WP site that needed additional columns/fields in ther wp_users tables.

Since a final Bugfix in WP 3.0, this feature is neglected and likely orphaned/deprecated. There are more modern ways not to extend the wp_users table by using dbDelta() using a join via pre_user_query action which was introduced in WP 3.1.0.

There is also not a single test covering CUSTOM_USER_META_TABLE or CUSTOM_USER_TABLE (total number of unit tests ~13,000).

While every plugin developer should use $wpdb->users to access the wp_users table, there will be some developers writing $wpdb->prefix . 'users' which will break if the users table is remapped, same on a multisite unless $wpdb->base_prefix is used. So that would be a poorly written plugin, nevertheless this feature can create friction.

Maybe @matt could give us some insight here, and explain what the feature was actually meant for.

If there is no more active use case, I would rather recommend to flag these two constants as deprecated just like VHOST, WP_ENVIRONMENT_TYPES(plural) and WP_LANG`

From src/wp-admin/options-general.php:362

<?php
// Add note about deprecated WPLANG constant.
if ( defined( 'WPLANG' ) && ( '' !== WPLANG ) && WPLANG !== $locale ) {
        _deprecated_argument(
                'define()',
                '4.0.0',
                /* translators: 1: WPLANG, 2: wp-config.php */
                sprintf( __( 'The %1$s constant in your %2$s file is no longer needed.' ), 'WPLANG', 'wp-config.php' )
        );
}

[apermo]

If we go down the deprecation path, it would be worth noting that BLOGID_CURRENT_SITE is replaced by BLOG_ID_CURRENT_SITE but is only deprecated as comment and has no deprecation warning, and TEMPLATEPATH and STYLESHEETPATH are both noted as deprecated since 6.4.0 and will silently be defined by core without a runtime notice.

It would be worth adding a proper deprecation notice for these similar to VHOST, WP_ENVIRONMENT_TYPES and WP_LANG.

[knutsp]

I have used CUSTOM_USER_META_TABLE and CUSTOM_USER_TABLE many times for development, staging and "old" sites. The need is to let two or more sites share users without setting up a full multisite. It's well documented here ​https://developer.wordpress.org/advanced-administration/wordpress/wp-config/#custom-user-and-usermeta-tables.

I see no reson to deprecate, just because claimed as "hardly used".

[wildworks]

It appears that these two constants have not had their values validated since they were first introduced.

	Changeset	WordPress version
CUSTOM_USER_TABLE	r2205	1.5
CUSTOM_USER_META_TABLE	r2632	2.0

---

The need is to let two or more sites share users without setting up a full multisite.

Perhaps, if there are other ways to achieve the same result without using CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE, we could deprecate these constants.

[ramon fincken]

I would not depricate them @wildworks if its up to me :)

I am open for code suggestions if my patch is insufficient.

[apermo]

Replying to wildworks:

Perhaps, if there are other ways to achieve the same result without using CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE, we could deprecate these constants.

1. Filtering via query
2. Using an SSO Plugin via oAuth, Active Directory, Google, etc.
3. Creating a custom login plugin that hooks into authenticate and validates the credentials against the rest API of the leading WordPress, just creating local copies of the user data.

Even if the constants would be deprecated, they won't stop working, they will just send a warning that it is an unmaintained feature.

[knutsp]

Replying to apermo:

Replying to wildworks:

Perhaps, if there are other ways to achieve the same result without using CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE, we could deprecate these constants.

1. Filtering via query
2. Using an SSO Plugin via oAuth, Active Directory, Google, etc.
3. Creating a custom login plugin that hooks into authenticate and validates the credentials against the rest API of the leading WordPress, just creating local copies of the user data.

This is not about login (authentication). It's about using the same user profile over different sites using the same database (with different table prefix), like multistite. To authenticate in this scenario, also multisite, you also need some kind of SSO.

Even if the constants would be deprecated, they won't stop working, they will just send a warning that it is an unmaintained feature.

Deprecation is also a warning that the feature is slated for removal in a future release.

[apermo]

Replying to knutsp:

Replying to apermo:

Replying to wildworks:

Perhaps, if there are other ways to achieve the same result without using CUSTOM_USER_TABLE and CUSTOM_USER_META_TABLE, we could deprecate these constants.

1. Filtering via query
2. Using an SSO Plugin via oAuth, Active Directory, Google, etc.
3. Creating a custom login plugin that hooks into authenticate and validates the credentials against the rest API of the leading WordPress, just creating local copies of the user data.

This is not about login (authentication). It's about using the same user profile over different sites using the same database (with different table prefix), like multistite. To authenticate in this scenario, also multisite, you also need some kind of SSO.

Since the User Capabilities are tied to the table prefix, you'll still need to maintain the
user role/capabilities twice. And in two separate User interfaces.
And in case you'd delete a user in site A, the posts in site B would be orphaned without further work. I understand why you use it, but following a conversation with @garyj it was never meant to be used for that.

Even if the constants would be deprecated, they won't stop working, they will just send a warning that it is an unmaintained feature.

Deprecation is also a warning that the feature is slated for removal in a future release.

BLOGID_CURRENT_SITE is just a fixed alternative spelling of BLOG_ID_CURRENT_SITE and both were added in WP3.0, BLOGID_CURRENT_SITE is deprecated since it's introduction. The precise moment is commit 809684b754, dated 2010-03-06.

"More network.php refinements. Bring wp-config and htaccess inline. Rename BLOGID_CURRENT_SITE to BLOG_ID_CURRENT_SITE for consistency with SITE_ID_CURRENT_SITE. see #11816"

So I doubt it would be removed due to the backwards compatibility mantra.