Opened 7 weeks ago
Closed 11 days ago
#65012 closed feature request (fixed)
Fix: Register Akismet Anti-Spam as a connector
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 7.0 | Priority: | normal |
| Severity: | normal | Version: | |
| Component: | Plugins | Keywords: | has-patch has-unit-tests commit dev-reviewed |
| Focuses: | Cc: |
Description
Akismet comes with core but the connectors screen was not showing akismet even if akismet was on the file system. This PR fixes the issue.
Registers Akismet Anti-Spam as a built-in non-AI connector with spam_filtering type on the Connectors screen.
Core PR: #11399.
What This Changes
Registers Akismet Anti-Spam as a default connector in _wp_connectors_register_defaults():
$registry->register(
'akismet',
array(
'name' => __( 'Akismet Anti-spam' ),
'description' => __( 'Protect your site from spam.' ),
'type' => 'spam_filtering',
'plugin' => array(
'file' => 'akismet/akismet.php',
),
'authentication' => array(
'method' => 'api_key',
'credentials_url' => 'https://akismet.com/get/',
'setting_name' => 'wordpress_api_key',
'constant_name' => 'WPCOM_API_KEY',
),
)
);
Key details:
- Uses the existing
wordpress_api_keyWordPress option for API key storage (shared with Akismet's own settings). - Checks the
WPCOM_API_KEYPHP constant for sites that define the key inwp-config.php. - Introduces the
spam_filteringconnector type alongside the existingai_providertype. - References the plugin file as
akismet/akismet.phpfor activate flows.
Testing Instructions
- Visit Settings → Connectors and verify the Akismet card appears when akismet is on the file system.
- Test the default activation flow.
- Set an Akismet key and verify it shows as connected on both the Connectors screen and the Akismet settings page.
- Set a key on the Akismet settings page and verify it is reflected on the Connectors screen.
- Set a key using
wp-config.phpviadefine( 'WPCOM_API_KEY', 'your-key' );and verify the Connectors screen reflects the key was set via constant.
Attachments (1)
Change History (62)
#2
@
7 weeks ago
- Keywords dev-reviewed added; 2nd-opinion removed
- Milestone changed from 7.0 to Awaiting Review
I reviewed the changes.
@matveb, this will show the Akimset card on the Connectors screen on every WP instance for now. However, we will follow up with the removing in the UI the card when the WP instance doesn't have the Akimset plugin bundled, or the user decides to remove it. In effect, when someone downloads a new WP instance at https://wordpress.org/download/, they will see the Akismet card with the activation button because it's bundled.
@westonruter, based on the earlier 7.0 planning, it should ship with the current release.
#4
follow-up:
↓ 7
@
7 weeks ago
I reviewed the changes.
What changes? There is no PR attached to this ticket.
Checks the WPCOM_API_KEY PHP constant for sites that define the key in wp-config.php.
As this is wordpress.org, I'm a bit concerned about introducing a WPCOM prefixed constant.
This ticket was mentioned in PR #11399 on WordPress/wordpress-develop by @jorgefilipecosta.
7 weeks ago
#5
- Keywords has-unit-tests added
## Summary
Akismet comes with core but the connectors screen was not showing akismet even if akismet was on the file system. This PR fixes the issue.
Register Akismet Anti-Spam as a built-in non-AI connector with spam_filtering type.
- Uses the existing
wordpress_api_keyWordPress option for API key storage - Checks the
WPCOM_API_KEYPHP constant
Ticket: https://core.trac.wordpress.org/ticket/65012
## Testing
Verify the akismet connector works as expected:
- Test the default activation flow.
- Delete Akismet and test the installation flow. Set an Akismet key verify it shows as connected, on the connectors and on the Akismet own settings page.
- Set a key on Akismet settings page verify it is reflected on the connectors screen.
- Set a key using wp-config define( 'WPCOM_API_KEY', 'your-key' ); verify the connectors reflect the key was set on wp-config.
See also: https://github.com/WordPress/gutenberg/pull/76828
#6
@
7 weeks ago
- Owner set to jorgefilipecosta
- Resolution set to fixed
- Status changed from new to closed
In 62193:
#7
in reply to:
↑ 4
@
7 weeks ago
I reviewed the changes.
What changes? There is no PR attached to this ticket.
The PR in question was https://github.com/WordPress/wordpress-develop/pull/11399, it was being referenced on the description.
Checks the WPCOM_API_KEY PHP constant for sites that define the key in wp-config.php.
As this is wordpress.org, I'm a bit concerned about introducing a WPCOM prefixed constant.
The plugin was already using WPCOM_API_KEY as the constant it is not different that the fact that you can use define( 'ANTHROPIC_API_KEY', '...' ) to define ANTHROPIC key, or define( 'GOOGLE_API_KEY', '...' ) to define a key for google.
#8
follow-up:
↓ 9
@
7 weeks ago
- Resolution fixed deleted
- Status changed from closed to reopened
@jorgefilipecosta For the setting_name, it doesn't seem 'wordpress_api_key' is correct. Shouldn't it be 'akismet_api_key'? Or at least, 'wpcom_api_key'/'wordpresscom_api_key'?
#9
in reply to:
↑ 8
@
7 weeks ago
Replying to westonruter:
@jorgefilipecosta For the
setting_name, it doesn't seem'wordpress_api_key'is correct. Shouldn't it be'akismet_api_key'? Or at least,'wpcom_api_key'/'wordpresscom_api_key'?
It is correct, wordpress_api_key, is what akismet uses to store the key as the option name.
#11
@
7 weeks ago
https://github.com/WordPress/gutenberg/pull/76962 – related UI changes to hide the Akismet card when the plugin is not present in the plugins directory (not bundled / removed case).
#12
follow-up:
↓ 48
@
7 weeks ago
- Keywords close added
I think Akismet API registration belongs in the plugin, per Matt's comment on the AI client merbe proposal:
Akismet (and other plugins) should register their keys to be on this page, so instead of users having to go around a bunch of different menu areas there is one place for all of this. A single page where you can see all the things your WordPress is connected to. Premium plugins could also register on this screen.
Akismet can easily be removed from an install and replaced by another anti-spam solution. Some of which also require an API key.
If the requirement is for other plugins to register their own key, the same should apply for Akismet.
r62193 should be reverted asap.
This ticket was mentioned in Slack in #core by peterwilsoncc. View the logs.
7 weeks ago
This ticket was mentioned in PR #11428 on WordPress/wordpress-develop by @peterwilsoncc.
7 weeks ago
#15
This reverts commit c5627a124998b20ee492e922edbf4d75d5fd927c.
Reverts Akismet connector registration from WordPress Core in favor of requiring the plugin register the connector.
Trac ticket: https://core.trac.wordpress.org/ticket/65012#comment:12
## Use of AI Tools
Nil
This ticket was mentioned in PR #11428 on WordPress/wordpress-develop by @peterwilsoncc.
7 weeks ago
#14
This reverts commit c5627a124998b20ee492e922edbf4d75d5fd927c.
Reverts Akismet connector registration from WordPress Core in favor of requiring the plugin register the connector.
Trac ticket: https://core.trac.wordpress.org/ticket/65012#comment:12
## Use of AI Tools
Nil
#15
@
7 weeks ago
- Keywords dev-reviewed has-unit-tests close removed
Removing keywords, including the one I accidentally added myself.
#16
@
7 weeks ago
I agree with reverting though I think it might only need to be temporary. Before any additional connectors are added, I think there is a need to have some guidelines that are agreed up and published on make/core for what connectors need in order to ship with core.
#17
@
7 weeks ago
Agree that this should be reverted. Akismet should register its connector via wp_connectors_init.
#18
follow-up:
↓ 20
@
7 weeks ago
For now, Akismet cannot register its own connector that appears on the connectors screen before the plugin is activated. This commit includes the required metadata so the connector appears before activation, just like OpenAI, Anthropic, and Google. For OpenAI, Anthropic, and Google they even appear before installation which is not the case for Akismet. Showing Akismet before activation was discussed with the release lead @matveb.
#19
follow-up:
↓ 22
@
7 weeks ago
The long-term ideal solution is making sure all plugins in the filesystem that have connectors appear on the connectors screen even when not active and allow their activation from there, but that is something that needs additional thought and will require bigger changes. Meanwhile, this solution works and it is not different from what we do for the AI providers.
#20
in reply to:
↑ 18
;
follow-up:
↓ 25
@
7 weeks ago
Replying to jorgefilipecosta:
For now, Akismet cannot register its own connector that appears on the connectors screen before the plugin is activated. This commit includes the required metadata so the connector appears before activation, just like OpenAI, Anthropic, and Google.For OpenAI, Anthropic, and Google they even appear before installation which is not the case for Akismet.
That's my point, without the plugin being active the Akismet key does not serve a purpose. The AI connectors are designed to be shared between various plugins. The Akismet API key serves a purpose exclusively for a single plugin.
The OpenGraph.xyz, Magic API Email and TransLeti Connector plugins all require API keys, are there plans to go through the plugin directory and add connectors for all plugins that require a key?
This change was discussed with the release lead @matveb.
Where was this discussed? Like the AI client connectors, the wider contributor group should have had a chance to discuss this.
@desrosj commented on PR #11428:
7 weeks ago
#21
Showing Akismet before activation was discussed with the release lead @mtias.
@jorgefilipecosta Can you share a link to where this discussion took place for others to read through so that the goals of this can be better understood? I apologize if I'm missing it, but it's difficult to support a change within an open project when there is no public record of the rationale or how it was tested within the community.
For now, Akismet cannot register its own connector that appear on the connectors screen before the plugin is activated. PR #11399 includes the required metadata so the connector appears before activation, just like OpenAI, Anthropic, and Google. For OpenAI, Anthropic, and Google, they even appear before installation, which is not the case for Akismet.
I'm not clear on why it's desirable for Akismet to be visible as an available connection _before_ being activated. How does this scale? Is the expectation that any installed plugin can add their connection details to this page when they are deactivated? I'm not sure how that scales and I think that will certainly be abused.
It's true that the OpenAI, Anthropic, and Google connectors appear before being installed and/or activated, but these are accompanied by a specific call to action educating the user about the AI plugin and the supported models. Yes, the page is meant to house all API keys, but in my opinion, there should be two types of connections: AI connector plugins and everything else.
As the page sits before r62193, the bottom of the list has a link to "search the plugin directory to see if a connector is available" which searches the connector tag on the directory. Akismet does not show up there because it's not (and should not be) tagged as a connector, which makes it feel even more out of place for me.
#22
in reply to:
↑ 19
;
follow-up:
↓ 27
@
7 weeks ago
I commented on the PR already because I saw that discussion first. But just to respond to a few points I did not see specifically called out on the PR's discussion.
Replying to jorgefilipecosta:
The long-term ideal solution is making sure all plugins in the filesystem that have connectors appear on the connectors screen even when not active and allow their activation from there, but that is something that needs additional thought and will require bigger changes.
I strongly disagree that this is the ideal solution here. This will be not only be abused by plugins rendering the Connectors page essentially useless (all you need is to be installed, and you can bug the site owner to reactivate and renew forever on this page). It will most certainly also be a vulnerability gold mine.
Meanwhile, this solution works and it is not different from what we do for the AI providers.
I am of the opinion that it should be different. The AI connectors have a specific purpose that the project is trying to champion by empowering users with the tools they need to be successful in an increasingly AI world. If it were up to me, the two groups would be AI connectors, and API Keys or Everything Else.
#23
@
7 weeks ago
Looking in to this further, I've noticed that the plugin's development version already includes a connector, as posted in Slack last month, so this definitely needs to be reverted in order that WordPress users don't end up with two Akismet connectors in the settings.
#25
in reply to:
↑ 20
;
follow-up:
↓ 36
@
7 weeks ago
Replying to peterwilsoncc:
That's my point, without the plugin being active the Akismet key does not serve a purpose. As the AI connectors are designed to be shared between various plugins. The Akismet API key serves a purpose exclusively for a single plugin.
That's a good point that is worth addressing. The UI doesn't actually allow setting a key without activating the plugin first. What it does is let users activate the plugin directly from the connectors screen, without needing to navigate to the plugins screen, and then provide the key right away without any page reloads. So by the time the key is set, the plugin is already active.
The connectors screen serves as a place to configure connections to third parties that enhance the WordPress experience. Showing Akismet there provides an easy and intuitive way to activate the plugin, and it also reinforces the idea that the connectors screen is not exclusively for AI providers. And, though connectors really shine when they can be shared between plugins, connectors with a tighter relationship with a single plugin still have a place in this new central screen.
Where was this discussed? Like the AI client connectors, the wider contributor group should have had a chance to discuss this.
We are discussing this publicly here both on Trac and GitHub and @gziolo also raised awareness for this discussion on the release leads slack channel. Everyone is welcome to share their thoughts and feedback. And I'm open to other alternatives/possibilities that achieve the goal of showing Akismet on the connectors screen before activation and that are feasible during the 7.0 release cycle.
Looking in to this further, I've noticed that the plugin's development version already includes a connector, as posted in Slack last month, so this definitely needs to be reverted in order that WordPress users don't end up with two Akismet connectors in the settings.
It is fine and expected that plugins can define their register connectors. For instance, AI providers can overwrite the core UI to include token information; or akismet can overwrite the UI to show plan information. The connector will not appear two times. The same connector does not appear multiple times when registered, provided the IDs used are the same. I'm in touch with Akismet developers so that we're in sync. For example, @bluefuton had a look into related changes in the Gutenberg repo and left some comments; if there is any plugin incompatibility it will be addressed in Akismet before the 7.0 release.
This ticket was mentioned in Slack in #core by elrae. View the logs.
7 weeks ago
#27
in reply to:
↑ 22
;
follow-up:
↓ 30
@
7 weeks ago
Replying to desrosj:
I commented on the PR already because I saw that discussion first. But just to respond to a few points I did not see specifically called out on the PR's discussion.
Replying to jorgefilipecosta:
The long-term ideal solution is making sure all plugins in the filesystem that have connectors appear on the connectors screen even when not active and allow their activation from there, but that is something that needs additional thought and will require bigger changes.
I strongly disagree that this is the ideal solution here. This will be not only be abused by plugins rendering the Connectors page essentially useless (all you need is to be installed, and you can bug the site owner to reactivate and renew forever on this page). It will most certainly also be a vulnerability gold mine.
That's a fair concern, but it's not quite what I had in mind. Inactive plugins wouldn't be able to execute arbitrary code to register a connector. We're considering a few options, for example a special syntax in the plugin definition header or a dedicated connectors.json file. Either approach would also allow the WP.org API to expose connectors that core can use to render the default connectors list, removing the need for any hardcoding. That said, I think we need more time to land on the right path forward here, and I appreciate the thoughtfulness around security.
I am of the opinion that it should be different. The AI connectors have a specific purpose that the project is trying to champion by empowering users with the tools they need to be successful in an increasingly AI world. If it were up to me, the two groups would be
AI connectors, andAPI KeysorEverything Else.
I hear you, and I agree that the AI connectors serve an important purpose in empowering users. At the same time, Akismet also play a meaningful role in helping users succeed, in this case by saving them from spending significant time dealing with spam. Given the existing decision to include Akismet with core, I think it's natural for its connector to appear on the Connectors screen before activation, with an easy path to activate it from there. If we're already showing connectors for AI services whose files aren't even included in the installation, it seems reasonable to do the same for something that's already bundled.
#28
@
7 weeks ago
Thank you @jorbin, @westonruter, @peterwilsoncc, @davidbaumwald, and @gziolo for the thoughts and insights shared on this issue. The need for a decision has been raised in the release leads Core Slack channel, and I'll be waiting on public direction from the release/product leadership regarding next steps.
@jorgefilipecosta commented on PR #11428:
7 weeks ago
#29
Hi @aaronjorbin, @desrosj, @peterwilsoncc, thank you for all the points raised and preparing a revert. I left some comments on the Trac ticket https://core.trac.wordpress.org/ticket/65012 answering some of the points being discussed here. I think it would be best to continue the conversation there so it's not split across two places.
#30
in reply to:
↑ 27
@
6 weeks ago
Replying to jorgefilipecosta:
Given the existing decision to include Akismet with core
The need for a decision has been raised in the release leads Core Slack channel, and I'll be waiting on public direction from the release/product leadership regarding next steps.
I'm concerned about the ability for the public to weigh in on a broader discussion about preferential treatment for specific plugins without derailing this ticket.
#31
follow-up:
↓ 32
@
6 weeks ago
- Keywords commit added
@matveb weighed in on slack:
So i think Akismet should show up if it’s installed.
As the code currently does the opposite, I think we are good to go with the revert.
#32
in reply to:
↑ 31
;
follow-up:
↓ 38
@
6 weeks ago
Replying to jorbin:
@matveb weighed in on slack:
So i think Akismet should show up if it’s installed.
As the code currently does the opposite, I think we are good to go with the revert.
Hi @jorbin the code does not makes the opposite, the connector only appear on the UI if Akismet is installed.
#33
@
6 weeks ago
To properly test this patch, the Gutenberg ref needs to be updated to the latest one (for now, cd9192803f5b1262cc2f9beefc52bc500545813f). Normally, the ref is only updated before releases. Once Akismet is deleted from the file system, it no longer shows up in the UI, which matches exactly what was shared in the Release Leads Slack channel
#34
follow-up:
↓ 35
@
6 weeks ago
I think the fundamental question is still to be answered.
How does it benefit users to add an Akismet key to WordPress without Akismet being active?
#35
in reply to:
↑ 34
@
6 weeks ago
Replying to peterwilsoncc:
I think the fundamental question is still to be answered.
How does it benefit users to add an Akismet key to WordPress without Akismet being active?
Hi @peterwilsoncc, I believe I addressed this earlier at https://core.trac.wordpress.org/ticket/65012?replyto=34#comment:25, but it may have gotten lost in the conversation:
That's a good point that is worth addressing. The UI doesn't actually allow setting a key without activating the plugin first. What it does is let users activate the plugin directly from the connectors screen, without needing to navigate to the plugins screen, and then provide the key right away without any page reloads. So by the time the key is set, the plugin is already active.
#36
in reply to:
↑ 25
;
follow-up:
↓ 37
@
6 weeks ago
- Component changed from General to Plugins
- Keywords revert added; commit removed
- Type changed from defect (bug) to feature request
- Version trunk deleted
Replying to jorgefilipecosta:
We are discussing this publicly here both on Trac and GitHub and @gziolo also raised awareness for this discussion on the release leads slack channel.
- The Slack thread that you didn't reference was started after the commit was made: https://wordpress.slack.com/archives/C0A803Z8MA5/p1775057127773399.
- There is no public discussion of this change outside of this Trac ticket. Discussion on the PR was technical feedback.
- Nobody approved your PR.
- The change was committed 36 minutes after opening the ticket.
Sorry @jorgefilipecosta but it is inappropriate to make this sort of change during RC, especially within such a short period of time and with no public discussion.
If you want to facilitate plugins registering an entry on the Connectors screen when they're installed but not activate, then make a proper proposal and discussion instead of privately deciding that it's ok for Akismet to be inserted there. Please go ahead and revert [62193] pending further discussion. Thank you.
#37
in reply to:
↑ 36
@
6 weeks ago
Replying to johnbillion:
Replying to jorgefilipecosta:
We are discussing this publicly here both on Trac and GitHub and @gziolo also raised awareness for this discussion on the release leads slack channel.
- The Slack thread that you didn't reference was started after the commit was made: https://wordpress.slack.com/archives/C0A803Z8MA5/p1775057127773399.
- There is no public discussion of this change outside of this Trac ticket. Discussion on the PR was technical feedback.
- Nobody approved your PR.
- The change was committed 36 minutes after opening the ticket.
Sorry @jorgefilipecosta but it is inappropriate to make this sort of change during RC, especially within such a short period of time and with no public discussion.
If you want to facilitate plugins registering an entry on the Connectors screen when they're installed but not activate, then make a proper proposal and discussion instead of privately deciding that it's ok for Akismet to be inserted there. Please go ahead and revert [62193] pending further discussion. Thank you.
Hi @johnbillion,
Thank you for raising your concerns. This ticket was approved by @gziolo (another committer) https://core.trac.wordpress.org/ticket/65012#comment:2, following the double sign-off process before committing. It was only committed to trunk and has not been backported into the 7.0 release branch.
The Slack thread was created to make the release leads aware of the disagreement on this ticket. At the time I committed we had a PR, questions and feedback were raised and addressed, the ticket was approved with a double sign-off, and I committed, like any other task/issue. Regarding the RC, the release has since been delayed and we are in a slightly "returning to beta" stage https://make.wordpress.org/core/2026/04/02/the-path-forward-for-wordpress-7-0/, though the ticket still had the double sign-off required for an RC.
If you want to facilitate plugins registering an entry on the Connectors screen when they're installed but not activate, then make a proper proposal and discussion instead of privately deciding that it's ok for Akismet to be inserted there.
It's worth noting that the approach used to add Akismet is the same as the one used for the other three connectors we already had, using what is currently possible. In the future, we could iterate on all connectors.
#38
in reply to:
↑ 32
@
6 weeks ago
Replying to jorgefilipecosta:
the connector only appear on the UI if Akismet is installed.
The current code shows the akismet connector for all users, not just those that have Akismet installed. Seeing that there are now six committers (seven based off of @matveb's comments) that are supporting the revert, that seems like the best immediate path.
I stand by my original recommendation that no additional connectors should be added until some guidelines are agreed up and published on make/core for what connectors need in order to ship with core. I can absolutely see a possible result of that is shipping a connector for Akismet (or something similar), but for the time being, it's clear this code is not ready for WordPress.
#41
follow-ups:
↓ 45
↓ 46
@
6 weeks ago
I'm a bit confused about the outcome. I agree, at this late stage, the connector should not show up when the plugin is not present in the WP install, but it should be displayed when it is, even if it's not activated.
It’s important to position connectors as not being exclusively for AI. Looking beyond, the connectors UI should show available connectors from any installed plugin, regardless of whether they are activated. Given Akismet is bundled by default, it should show up if the file is present for 7.0. It'd be odd to have the plugin present in plugins but not in connectors. For the next cycle, this should be formalized in plugin headers or some other broader mechanism.
This ticket was mentioned in PR #11460 on WordPress/wordpress-develop by @jorgefilipecosta.
6 weeks ago
#42
- Keywords has-unit-tests added
This is just to be able to demo the behavior before the revert of Akismet connector on playground, and share in the discussion issue https://core.trac.wordpress.org/ticket/65012 not something to review or merge.
#43
@
6 weeks ago
Historically, plugins have largely referred to these "connection details" as "API keys".
One thing I am still not clear on is what the benefit is of renaming the latter to "connectors" when a plugin requires a simple set of API credentials or a key.
Using connectors for AI-related tools makes sense because it is a new concept. But there is a long-standing word association that users will have to be retrained on by renaming this.
@matveb past listing AI connectors and plugin API keys in one location (which I fully agree with), are you able to help clarify what the benefits are of calling them the same thing instead of having two types?
#44
@
6 weeks ago
Hi @jorbin, thanks for following up on this!
Replying to jorbin:
Replying to jorgefilipecosta:
the connector only appear on the UI if Akismet is installed.
The current code shows the akismet connector for all users, not just those that have Akismet installed. Seeing that there are now six committers (seven based off of @matveb's comments) that are supporting the revert, that seems like the best immediate path.
I think there might be a small misunderstanding. As I mentioned in https://core.trac.wordpress.org/ticket/65012#comment:32, the connector only appears when Akismet is installed. If it helps, you can see this in action using Playground (PR wordpress-develop#11460 is just there to support this Playground demo).
I also recorded a quick video walking through the behavior: Akismet-connector.mov. You can see the connector appearing when Akismet is installed and disappearing once it's deleted.
That said, if you've run into a case where the connector showed up without Akismet being installed, that would be really useful to know about. It could point to a bug that might also affect third-party connectors, so any details about the setup where you saw this would be a big help in tracking it down.
Seeing that there are now six committers (seven based off of @matveb's comments) that are supporting the revert, that seems like the best immediate path.
I interpreted @matveb's comments a bit differently. I took him to be saying that Akismet should be shown even when not installed, which is what the original commit was doing, in line with what the infrastructure supported at the time, rather than supporting a revert.
Whatever direction we land on next, working through the Akismet integration has been a great opportunity to stress-test the connectors infrastructure and ship some improvements along the way, like fixes for assumptions about constants and settings sharing the same naming, and the bug @peterwilsoncc reported at gutenberg#76984. Really appreciate the suggestions and issues reported.
#45
in reply to:
↑ 41
;
follow-up:
↓ 47
@
6 weeks ago
Replying to matveb:
I'm a bit confused about the outcome. I agree, at this late stage, the connector should not show up when the plugin is not present in the WP install, but it should be displayed when it is, even if it's not activated.
It’s important to position connectors as not being exclusively for AI. Looking beyond, the connectors UI should show available connectors from any installed plugin, regardless of whether they are activated. Given Akismet is bundled by default, it should show up if the file is present for 7.0. It'd be odd to have the plugin present in plugins but not in connectors. For the next cycle, this should be formalized in plugin headers or some other broader mechanism.
Mobile, jetlgged, flight delays. Excuse typos
The Akismet team have added a connector to their plugin for the next release (mentioned in core-ai channel)
An akismet API entry field will show up once the plugin is active and needed. I’m not sure what happened when both the plugin and core were registered the connectors
#46
in reply to:
↑ 41
@
6 weeks ago
Replying to matveb:
It’s important to position connectors as not being exclusively for AI.
I agree. Do you want to open a ticket to discuss how best to do that or do you think this might be better as a make/core discussion?
Given Akismet is bundled by default, it should show up if the file is present for 7.0.
How does that help users? If anything it's going to create confusion since they may think that by having entered the key on the connectors screen they have activated akismet. Aditionally, the connectors screen should be about reusable connections. Besides akismet, which plugins currently make use of this key? Installation and activation are different intents and should be treated differently.
#47
in reply to:
↑ 45
@
6 weeks ago
Replying to peterwilsoncc:
Replying to matveb:
I'm a bit confused about the outcome. I agree, at this late stage, the connector should not show up when the plugin is not present in the WP install, but it should be displayed when it is, even if it's not activated.
It's important to position connectors as not being exclusively for AI. Looking beyond, the connectors UI should show available connectors from any installed plugin, regardless of whether they are activated. Given Akismet is bundled by default, it should show up if the file is present for 7.0. It'd be odd to have the plugin present in plugins but not in connectors. For the next cycle, this should be formalized in plugin headers or some other broader mechanism.
Mobile, jetlgged, flight delays. Excuse typos
The Akismet team have added a connector to their plugin for the next release (mentioned in core-ai channel)
An akismet API entry field will show up once the plugin is active and needed. I'm not sure what happened when both the plugin and core were registered the connectors
Hi @peterwilsoncc, I tried to address this point earlier in 25. What we had works well with the latest released version of Akismet on the wp.org repo. The Akismet developers are aware of what is happening in core and will make sure things continue to work well together in future releases, independently of what is on the development branch now. It is totally fine for plugins to remove core registration and enhance it at the plugin level; AI providers can also do the same if, for example, they want to include credit information, etc.
Hi @jorbin,
How does that help users? If anything it's going to create confusion since they may think that by having entered the key on the connectors screen they have activated akismet.
I tried to address this point earlier in 25:
That's a good point that is worth addressing. The UI doesn't actually allow setting a key without activating the plugin first. What it does is let users activate the plugin directly from the connectors screen, without needing to navigate to the plugins screen, and then provide the key right away without any page reloads. So by the time the key is set, the plugin is already active.
So this shouldn't create confusion. The user can activate the plugin and provide a key directly from the connectors screen, without any page reloads or needing to visit a separate settings page. If users think they've activated Akismet, they're correct: everything is ready to use, and the UI accurately reflects that.
It's possible to test this flow on Playground: https://playground.wordpress.net/wordpress.html?pr=11460 (note: Akismet needs to be installed first in the Playground PR reviewer, as it does not bundle Akismet the way normal core does). I also recorded a video with the full flow.
Aditionally, the connectors screen should be about reusable connections. Besides akismet, which plugins currently make use of this key?
My understanding is that the connectors screen is not exclusively about reusable connections. It is a central place that supports a set of common patterns for connecting to third-party services, even if a connection is only used by a single plugin. That said, in the specific case of Akismet, the key could actually be used by many third-party plugins, such as LifterLMS, Fluent Forms, Form Assembly, Formidable Forms, GiveWP, and some other services.
#48
in reply to:
↑ 12
@
5 weeks ago
Replying to peterwilsoncc:
I think Akismet API registration belongs in the plugin, per Matt's comment on the AI client merbe proposal:
I did say that, and have changed my mind and we're doing this.
Let's and pick up the debate for 7.1 in Slack and other places where it's easier to communicate.
I have rewritten this comment 4 times and gotten to 500+ words realizing I'm doing the exact mistake I'm trying to point out: spending time arguing about other things instead of resolving this thing so we can move on. And now I will move to Slack.
This ticket was mentioned in Slack in #core-committers by david.baumwald. View the logs.
5 weeks ago
#50
follow-up:
↓ 51
@
5 weeks ago
While I don't agree with including Akismet as a default option in the list of Connectors, since @matt has asked us to move forward with including it, can we please have it as a permanent option, available whether Akismet is installed or not. The same deal as Anthropic, ChatGPT, and Google – in a defaults array specified during the _wp_connectors_init function – rather than special treatment depending on whether it's installed or not.
Unless, of course, we decide that showing all Installed but not Active connector plugins on this screen is a good way forward.
#51
in reply to:
↑ 50
@
5 weeks ago
Hi @lukecarbis, in terms of code, nothing would block the Akismet connector from showing even when it is not installed. It is a product decision, and @matveb's messaging was clear that it should only show when installed, so it makes sense to follow the decision.
My understanding of the reasons is that the other connectors are not bundled. Akismet is. If a user did the extra work of removing it, that user probably is not interested in the connector. Happy to be corrected if there are other reasons at play.
Replying to lukecarbis:
While I don't agree with including Akismet as a default option in the list of Connectors, since @matt has asked us to move forward with including it, can we please have it as a permanent option, available whether Akismet is installed or not. The same deal as Anthropic, ChatGPT, and Google – in a defaults array specified during the
_wp_connectors_initfunction – rather than special treatment depending on whether it's installed or not.
Unless, of course, we decide that showing all Installed but not Active connector plugins on this screen is a good way forward.
@JeffPaul commented on PR #11428:
4 weeks ago
#52
Based on Matt's comment https://core.trac.wordpress.org/ticket/65012#comment:48, we should probably close this PR and move along.
This ticket was mentioned in Slack in #core by juanmaguitar. View the logs.
3 weeks ago
#54
@
3 weeks ago
- Keywords commit added
As per today's bug scrub:
A decision was made and we now need this to be re-committed and backported to 7.0.
#55
follow-up:
↓ 59
@
2 weeks ago
The AI plugin callout section states, "Connect a provider below to generate featured images, alt text, titles, excerpts, and more." However, in my understanding, even if the Akismet API key is set, no AI features can be utilized. This could potentially confuse users. At the very least, the text in the callout section may need improvement.
This ticket was mentioned in PR #11688 on WordPress/wordpress-develop by @jorgefilipecosta.
2 weeks ago
#56
## Summary
- Registers Akismet in the default connector registry as a
spam_filteringtype. - Wires plugin metadata to
akismet/akismet.phpwith anis_activecallback defaulting to__return_false, so the connector reports inactive until the Akismet plugin overrides it from its own registration. - Reuses the existing
wordpress_api_keyoption /WPCOM_API_KEYconstant for API key authentication, and points users tohttps://akismet.com/get/for credentials.
Must be tested with akismet installed, as the connector only appears if akismet is installed, does not needs activation.
Ticket: https://core.trac.wordpress.org/ticket/65012
## Test plan
- [ ] With Akismet inactive, confirm the connector appears in the registry and reports
is_activeasfalse. - [ ] With Akismet active and registering its own
is_activecallback, confirm the connector reportsis_activeastrue. - [ ] Verify the
wordpress_api_keyoption andWPCOM_API_KEYconstant are picked up as credentials.
#59
in reply to:
↑ 55
@
11 days ago
Replying to wildworks:
The AI plugin callout section states, "Connect a provider below to generate featured images, alt text, titles, excerpts, and more." However, in my understanding, even if the Akismet API key is set, no AI features can be utilized. This could potentially confuse users. At the very least, the text in the callout section may need improvement.
Thank you for raising this issue, @wildworks. The banner code is on the Gutenberg repo; I proposed a small improvement there.
Guessing that this is supposed to ship with 7.0