Jetpack: UI doesn't handle Akismet keys set via constant properly

[beaulebens]

Sites using Akismet may optionally configure their API Key via a constant (WPCOM_API_KEY, for historical reasons). This is common on hosts who have an Enterprise license for Akismet usage, and provide it for all of their users. Pressable is an example of this. It might also been seen for example on a multi-site, where the site admin sets it up for all sub-sites. In cases where Akismet is configured in this way, our UIs in both the Jetpack plugin, and Calypso/WP.com handle it poorly.

Steps to reproduce the issue

• create a WordPress site, install, activate, connect Jetpack
• get an Akismet API key
• if your site has it, delete any value stored in wp_options under the name wordpress_api_key
• add define('WPCOM_API_KEY', 'key-here'); to your wp-config.php, where 'key-here' is your Akismet API key
• go to _Jetpack > Settings >Security_ and see that the "Spam filtering" section thinks you need an API key, even though you technically have one.
• now go to wordpress.com and for that site, look under Settings > Security and see that it's pretty broken there as well.

What I expected

We should probably detect (will require a flag in the API) that the key is coming from a constant, is thus not editable, and just display a read-only message that things are configured, but they can't change it from here.

What happened instead

In Jetpack/wp-admin:

In WP.com:

[stale[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive in the past 6 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[BrookeDot]

The UI still shows a key is required, except now the settings show up in red that a key is needed:

[stale[bot]]

This issue has been marked as stale. This happened because:

• It has been inactive in the past 6 months.
• It hasn’t been labeled `[Pri] Blocker`, `[Pri] High`.

No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.

[mdmuzzie]

We encounter this issue as well, and we would love a fix. Jetpack does not recognize our Akismet Enterprise API key that is configured in our wp-config.php file.

[desnum]

A user hopped into chat to ask about this: Akismet is already activated but the text "Your site needs an Antispam key." is confusing.

12641715-hc

[JessBoctor]

I had another user confused by this in chat. This was especially confusing for them because they have multiple sites and wasn't sure if they needed an API key for each of their sites, or only one, and if they needed to create more accounts for their API keys.

18906850-HC

[eeeeevon13]

Let me know if I'm understanding the problem correctly here. It seems as though there are a few parts to this issue:

1) Users confused if they need multiple API keys for multiple sites
2) Jetpack is not recognizing the enterprise API key set if set in wp-config file (or other sources?)

@beaulebens

if your site has it, delete any value stored in wp_options under the name wordpress_api_key
add define('WPCOM_API_KEY', 'key-here'); to your wp-config.php, where 'key-here' is your Akismet API key

Couple of questions:

1. @beaulebens I see you've given directions on how to recreate from a technical perspective, can you explain how a user might actually get into this state? When/how might they recreate this condition via the UI?
2. I've added a mock that is geared toward this idea that the API key was set directly in wp-config, are there other places a user can set the API key that might also create this state?
3. Does a user need multiple API keys? @JessBoctor

Suggested action items:

1. Add a flag in order to understand that API is valid and coming from a different source
2. Add a user state to explain this to me including "locked field" state and messaging
   

[BrookeDot]

Often when a key is set in wp-config.php it is done so as the provider, often the host, has set an Enterprise key.

I like your mockup, but I think it may be wise to hide the actual key. "A valid key has been set in wp-config.php" and that message can then be hookable in Jetpack allowing hosts to change that as they see fit.

[beaulebens]

Yep I think I agree with @BrookeDot's suggestion about hiding the key -- maybe just a big checkmark/"Your antispam protection is enabled" type message, rather than showing them the key as well.

The specific problem here is when a key is already set in a config file, or via some other code-based approach, so it's not really something that a normal user can do to themselves _purely via the UI_.

It sounds like there's maybe some (understandable) confusion around multiple keys -- you can only easily use one Akismet API key at a time (all Akismet API requests require a key). For strange legacy reasons, that key is named WPCOM_API_KEY when configured via code (but it's actually an Akismet key).

So -- if a key is configured via code, you don't need/shouldn't be able to set one via the UI, and the key being used should probably be hidden from view.

[BrookeDot]

if a key is configured via code, you don't need/shouldn't be able to set one via the UI, and the key being used should probably be hidden from view.

I don't know what it would look like, but perhaps changing the field type to password might also work to keep with the original mockup.

[eeeeevon13]

Have a look:

[BrookeDot]

Looks good! my one bit of minor feedback is since WPCOM_API_KEY could be set outside of wp-config.php (although not common) I'd suggest we don't put too much emphasis on the location itself.

What about:

It looks like your API key has been set globally

A key has been set in your site's configuration.

[mattgawarecki]

I'm working on a fix for this. Slow going so far, but going nonetheless 😉

[mattgawarecki]

I've got a potential fix in #16542, as GitHub indicates above. All reviews welcome, but I definitely want to make sure we're happy with the design since there was a little iteration going on back in June. 🙂

cc @BrookeDot @eeeeevon13