Basic settings edit box doesn't show values from AUTH0_ENV_* constants

[Floppy]

Description

When using the configuration constants like AUTH0_ENV_CLIENT_ID, the basic settings form shows that the constant is in use via the message above the edit box, but the contents of the edit box show (I am fairly sure) the value loaded from the the database configuration, not the constant.

I've verified the value of the constants using https://wordpress.org/plugins/view-defined-constants-littlebizzy/, and they are definitely correct, but the value text on the settings page is outdated.

Does this seem possible?

Prerequisites

• Did you check the documentation?
• Did you check the Auth0 Community?
• Did you check the WP.org Support Forum?
• Are there any related or duplicate Issues or PRs in this repo?

Environment

Please provide the following:

• WP-Auth0 version: 3.7.1
• WordPress version: 4.9.8
• PHP version: 7.2.11

Reproduction

• Load an existing configuration into the plugin settings and save into the database
• Define constants for AUTH0_ENV_DOMAIN etc that use different values
• The basic settings page will show that the constant is being used, but the edit box will show the old value from the database.

Screenshots

Auth0 basic settings page:

View Constants plugin view of the relevant value:

[joshcanhelp]

@Floppy - Thank you for the very complete report here!

I'm not sure what to say here, it definitely should be showing the value that's set in the constant. We have a whole pile of unit tests to confirm that it does as well. I'm wondering if it's some kind of cache issue on your server.

If you try to get that value, what comes back?

$constant_val = AUTH0_ENV_DOMAIN;
$settings_val = WP_Auth0_Options::Instance()->get('domain');
echo $constant_val === $settings_val ? 'Yay' : 'Uh oh';

Also, what value is getting used on the site? I'm guessing it's the database one but good to test that as well.

It replaces the database value in the settings array used when the plugin loads so even if there's something in the database, that should be ignored. You can try saving the options and see what the options array is after that (it should delete the value when you save with a constant defined).

Other than that, I'm not sure where to go with this. Let me know if you need any guidance debugging where this is going wrong. Pretty much everything happens in WP_Auth0_Options_Generic. If there's a problem with what's there or an in compatibility with your setup, happy to fix it before the next release.

[Floppy]

Thanks @joshcanhelp, I'm glad I checked! I'll dig into the code; I've not verified which value is actually being used yet, I was on a bit of a deadline at the time. However, I've now backed out the change and decoupled the problem so I can investigate at my leisure.

[joshcanhelp]

@Floppy - Did you discover anything else about this? I just went through a thorough round of testing for the next release and did not see this issue crop up. If there is one, though, I'm happy to address it in 3.8.0 (coming next week).

[Floppy]

Just got chance to take another look, and tried some more things. I altered render_const_notice to the following, to print out the constant value:

	protected function render_const_notice( $input_name ) {
		printf(
			'<p><span class="description">%s <code>%s</code> (<code>%s</code>)</span></p>',
			__( 'Value is set in the constant ', 'wp-auth0' ),
			$this->options->get_constant_name( $input_name ),
			constant($this->options->get_constant_name( $input_name ))
		);
	}

The result is:

As you can see, the values are different! The value in the notice is the correct one from the environment, set in the constant, while the value in the box is the value from the database.

I'll keep poking, and try to verify exactly which is being used.

[Floppy]

So, I dropped the code from @joshcanhelp's comment above into WP_Auth0_Admin_Generic::init_option_section, and get a definite 'Uh Oh' and no 'Yay's, so I'm pretty sure it's not using the environment variable properly. 🙁

[Floppy]

Hitting "Save" on the basic admin page gave me a blank screen, then when I went back to the page, there was nothing in the domain or client ID fields (and a warning saying they can't be empty), which doesn't sound like it saved the constant data into the DB as expected.

[joshcanhelp]

@Floppy - If the constants are getting picked up and their values are available, then the issue must be in WP_Auth0_Options_Generic->get():

https://github.com/auth0/wp-auth0/blob/master/lib/WP_Auth0_Options_Generic.php#L138

Are you using the wp_auth0_get_option filter for anything?

That method uses get_options() from that same class:

https://github.com/auth0/wp-auth0/blob/master/lib/WP_Auth0_Options_Generic.php#L106

The get_options()method is where the options are pulled from the DB and replaced with constants. Is $this->constant_opts set properly?

[toddheslin]

Chiming in on this one. @joshcanhelp I had this same issue where setting constants in my functions.php were correctly being picked up in the Auth0 dashboard (thanks to @Floppy for the neat markup change to render_const_notice for debugging), however I continued to receive error messages saying that Domain, Client ID, and Client Secret need to be entered.

More of a problem is that when the shortcode was added to the page, I was getting the JavaScript that Auth0 isn't configured - even though everything was.

Is there some flag that indicates the setup is done? If so, it seems this isn't being properly triggered when the constants method is used.

[joshcanhelp]

It's all runtime, no process needs to happen to save those anywhere.

But you mentioned functions.php, I've only tested those in wp-config.php. The constant values are parsed on startup, before the theme is even taken into account.

Can you both try moving those definitions to wp-config.php and see if that helps? If that solves it, I'll call that out more explicitly in the documentation and also look into skipping that notice on the field if it's not picked up.

[toddheslin]

Ahh good point. The way our local (Docker) and production (VPS) is setup is such that we only manage the theme in our repo and never touch the wp-config.php.

It turns your that you're absolutely right. This implementation works in the wp-config.php but not the functions.php. I'd send a pull request for the docs but they aren't open source :-) Over to you!

[joshcanhelp]

@Floppy ☝️

@toddheslin - Thanks for trying that out! I'll make sure the plugin is not picking up those constants if it's not also using them. I don't think it's going to be possible to use constants in functions.php as that's too late in the load process but you could try putting them in an mu-plugin info here if you're not familiar, which will load before ours ... assuming that's something you're able to do with your setup.

Our docs are open source, here is an edit link for that page:

https://github.com/auth0/docs/edit/master/articles/cms/wordpress/configuration.md

I'll leave this issue open to track until I get this merged into master. Thanks for your help with this!

[Floppy]

Ah, interesting, I'm setting it in functions.php too. I'll move it earlier into wp-config.php and see if that helps.

[toddheslin]

Status update on this one - adding it to a mu-plugin works perfectly.

[joshcanhelp]

Great, thank you @toddheslin! I'll make sure the next version does not show the message unless it's actually using the constant as well as updating the documentation to be more clear.