fix: the last four places we still promise things we do not do by cport1 · Pull Request #82 · WebDecoy/wordpress-plugin

cport1 · 2026-08-22T23:26:46Z

Companion to WebDecoy/app#761. Copy only, no behaviour change, no version bump.

The claim that keeps coming back

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses ever seen at more than one site, 93% of attacker addresses gone inside an hour, 82% of feed entries already a week stale, none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now.

That fix landed here in 2.3.2. purge_feed_blocks() deletes the rows earlier versions wrote, and both connected variants of the CRITICAL notice were rewritten with a comment above them:

Must not claim Pro would have BLOCKED this. Since 2.3.2 the cross-site feed is advisory and writes nothing to the block list, on any plan.

Four lines below that comment, the unconnected variant went on offering "and to block threats like it automatically" for another three weeks.

A comment asking the next person not to do something is not a guard. There is now a test: it reads every translatable string in the file and fails on one promising to block, prevent or stop anything. Comments in the file discuss blocking at length and are deliberately exempt. Verified by putting the sentence back:

✗ no translatable string in the file offers to block anything
copy promises "block" — the feed is advisory on every plan and writes
nothing to the block list (#476): A CRITICAL deception trap was just
tripped. Connect to WebDecoy Cloud to see whether this attacker is already
known across the network, and to block threats like it automatically.

The wordpress.org listing

Live on the directory today, so these are the ones a stranger reads.

"Webhooks & Alerts: automated response chains, email notifications." The API refuses per-detection email (#702). Decoys are public bait and a busy site records thousands of hits a day, so "email me on every detection" is a mailbox nobody reads. Now: automated response chains plus a monthly email report.
"Push confirmed attackers to Cloudflare or AWS WAF." True, and it happens in the dashboard. Stated without that, in a plugin readme, it reads like something the plugin does. The claim keeps its substance and gains its location.
"Start Free Trial" → "Create a free account". There is no trial on this channel: a connected site is Free Connected, free, indefinitely. Sending someone to a trial they cannot start is a dead end at the exact moment they decided to sign up.
The settings upsell said "email alert automation" for the same reason, now the webhook plus the monthly report.

Release

95 tests pass, php -l clean on both touched PHP files.

Nothing here changes behaviour, so no version bump. The readme correction only reaches wordpress.org after an SVN sync, which is a separate deliberate step and not part of this PR.

Refs WebDecoy/app#759, WebDecoy/app#476, WebDecoy/app#702

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses were ever seen at more than one site, 93% of attacker addresses were gone inside an hour, and 82% of feed entries were already a week stale with none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now. purge_feed_blocks() deletes the rows earlier versions wrote, and the two connected variants of the CRITICAL notice were rewritten with a comment above them saying not to claim a block. The unconnected variant went on offering "to block threats like it automatically" for another three weeks, four lines below that comment. A comment asking the next person not to do something is not a guard, so there is now a test: it reads every translatable string in the file and fails on one that promises to block, prevent or stop anything. Verified by putting the sentence back. The listing on wordpress.org had two more. It sold "email notifications", which the API refuses (#702) because decoys are public bait and a busy site records thousands of hits a day; email is the monthly report. And it said attackers get pushed to Cloudflare or AWS WAF without saying that happens in the dashboard, which reads, in a plugin readme, like something the plugin does. Both corrected; the WAF claim keeps its substance and gains its location. "Start Free Trial" is now "Create a free account", because there is no trial on this channel: connecting is free and stays free. The settings upsell claimed "email alert automation" for the same reason and is now the webhook plus the monthly report. No behaviour changes, so no version bump. The readme correction is live on wordpress.org only after an SVN sync, which is a separate deliberate step. Refs #759, #476, #702

The alerts entitlement is served to every paid plan and the plugin has never read it. A site that upgraded got a flag it could not see and a feature it could not find. The Cloud tab now says which it is. On Pro: alerts are on, with a link to the dashboard where they are configured. On the free tier: what they are and that detection, blocking and the monthly report stay free, because the answer to "what do I lose by not paying" should be on the same line as the pitch. The plugin still sends nothing itself. That is deliberate and is the PRD's §9 guardrail: an entitlement check may gate a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account at all. Refs WebDecoy/app#762

cport1 · 2026-08-23T00:03:04Z

Added a second commit: the Cloud tab now reads features.alerts and says whether Slack and webhook alerts are on, with a link to where they are configured.

That flag has been served true to paid plans since P0 and read by nothing, here or anywhere. The companion is WebDecoy/app#764, which makes it mean something in the backend and the rule-engine.

The plugin still sends nothing itself, deliberately: the PRD's §9 guardrail is that an entitlement check gates a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account.

The free-tier line names what stays free rather than only what is missing. "What do I lose by not paying" belongs on the same line as the pitch.

cport1 · 2026-08-22T23:26:46Z

Companion to WebDecoy/app#761. Copy only, no behaviour change, no version bump.

The claim that keeps coming back

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses ever seen at more than one site, 93% of attacker addresses gone inside an hour, 82% of feed entries already a week stale, none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now.

That fix landed here in 2.3.2. purge_feed_blocks() deletes the rows earlier versions wrote, and both connected variants of the CRITICAL notice were rewritten with a comment above them:

Must not claim Pro would have BLOCKED this. Since 2.3.2 the cross-site feed is advisory and writes nothing to the block list, on any plan.

Four lines below that comment, the unconnected variant went on offering "and to block threats like it automatically" for another three weeks.

A comment asking the next person not to do something is not a guard. There is now a test: it reads every translatable string in the file and fails on one promising to block, prevent or stop anything. Comments in the file discuss blocking at length and are deliberately exempt. Verified by putting the sentence back:

✗ no translatable string in the file offers to block anything
copy promises "block" — the feed is advisory on every plan and writes
nothing to the block list (#476): A CRITICAL deception trap was just
tripped. Connect to WebDecoy Cloud to see whether this attacker is already
known across the network, and to block threats like it automatically.

The wordpress.org listing

Live on the directory today, so these are the ones a stranger reads.

"Webhooks & Alerts: automated response chains, email notifications." The API refuses per-detection email (#702). Decoys are public bait and a busy site records thousands of hits a day, so "email me on every detection" is a mailbox nobody reads. Now: automated response chains plus a monthly email report.
"Push confirmed attackers to Cloudflare or AWS WAF." True, and it happens in the dashboard. Stated without that, in a plugin readme, it reads like something the plugin does. The claim keeps its substance and gains its location.
"Start Free Trial" → "Create a free account". There is no trial on this channel: a connected site is Free Connected, free, indefinitely. Sending someone to a trial they cannot start is a dead end at the exact moment they decided to sign up.
The settings upsell said "email alert automation" for the same reason, now the webhook plus the monthly report.

Release

95 tests pass, php -l clean on both touched PHP files.

Nothing here changes behaviour, so no version bump. The readme correction only reaches wordpress.org after an SVN sync, which is a separate deliberate step and not part of this PR.

Refs WebDecoy/app#759, WebDecoy/app#476, WebDecoy/app#702

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses were ever seen at more than one site, 93% of attacker addresses were gone inside an hour, and 82% of feed entries were already a week stale with none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now. purge_feed_blocks() deletes the rows earlier versions wrote, and the two connected variants of the CRITICAL notice were rewritten with a comment above them saying not to claim a block. The unconnected variant went on offering "to block threats like it automatically" for another three weeks, four lines below that comment. A comment asking the next person not to do something is not a guard, so there is now a test: it reads every translatable string in the file and fails on one that promises to block, prevent or stop anything. Verified by putting the sentence back. The listing on wordpress.org had two more. It sold "email notifications", which the API refuses (#702) because decoys are public bait and a busy site records thousands of hits a day; email is the monthly report. And it said attackers get pushed to Cloudflare or AWS WAF without saying that happens in the dashboard, which reads, in a plugin readme, like something the plugin does. Both corrected; the WAF claim keeps its substance and gains its location. "Start Free Trial" is now "Create a free account", because there is no trial on this channel: connecting is free and stays free. The settings upsell claimed "email alert automation" for the same reason and is now the webhook plus the monthly report. No behaviour changes, so no version bump. The readme correction is live on wordpress.org only after an SVN sync, which is a separate deliberate step. Refs #759, #476, #702

The alerts entitlement is served to every paid plan and the plugin has never read it. A site that upgraded got a flag it could not see and a feature it could not find. The Cloud tab now says which it is. On Pro: alerts are on, with a link to the dashboard where they are configured. On the free tier: what they are and that detection, blocking and the monthly report stay free, because the answer to "what do I lose by not paying" should be on the same line as the pitch. The plugin still sends nothing itself. That is deliberate and is the PRD's §9 guardrail: an entitlement check may gate a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account at all. Refs WebDecoy/app#762

cport1 · 2026-08-23T00:03:04Z

Added a second commit: the Cloud tab now reads features.alerts and says whether Slack and webhook alerts are on, with a link to where they are configured.

That flag has been served true to paid plans since P0 and read by nothing, here or anywhere. The companion is WebDecoy/app#764, which makes it mean something in the backend and the rule-engine.

The plugin still sends nothing itself, deliberately: the PRD's §9 guardrail is that an entitlement check gates a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account.

The free-tier line names what stays free rather than only what is missing. "What do I lose by not paying" belongs on the same line as the pitch.

cport1 · 2026-08-22T23:26:46Z

Companion to WebDecoy/app#761. Copy only, no behaviour change, no version bump.

The claim that keeps coming back

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses ever seen at more than one site, 93% of attacker addresses gone inside an hour, 82% of feed entries already a week stale, none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now.

That fix landed here in 2.3.2. purge_feed_blocks() deletes the rows earlier versions wrote, and both connected variants of the CRITICAL notice were rewritten with a comment above them:

Must not claim Pro would have BLOCKED this. Since 2.3.2 the cross-site feed is advisory and writes nothing to the block list, on any plan.

Four lines below that comment, the unconnected variant went on offering "and to block threats like it automatically" for another three weeks.

A comment asking the next person not to do something is not a guard. There is now a test: it reads every translatable string in the file and fails on one promising to block, prevent or stop anything. Comments in the file discuss blocking at length and are deliberately exempt. Verified by putting the sentence back:

✗ no translatable string in the file offers to block anything
copy promises "block" — the feed is advisory on every plan and writes
nothing to the block list (#476): A CRITICAL deception trap was just
tripped. Connect to WebDecoy Cloud to see whether this attacker is already
known across the network, and to block threats like it automatically.

The wordpress.org listing

Live on the directory today, so these are the ones a stranger reads.

"Webhooks & Alerts: automated response chains, email notifications." The API refuses per-detection email (#702). Decoys are public bait and a busy site records thousands of hits a day, so "email me on every detection" is a mailbox nobody reads. Now: automated response chains plus a monthly email report.
"Push confirmed attackers to Cloudflare or AWS WAF." True, and it happens in the dashboard. Stated without that, in a plugin readme, it reads like something the plugin does. The claim keeps its substance and gains its location.
"Start Free Trial" → "Create a free account". There is no trial on this channel: a connected site is Free Connected, free, indefinitely. Sending someone to a trial they cannot start is a dead end at the exact moment they decided to sign up.
The settings upsell said "email alert automation" for the same reason, now the webhook plus the monthly report.

Release

95 tests pass, php -l clean on both touched PHP files.

Nothing here changes behaviour, so no version bump. The readme correction only reaches wordpress.org after an SVN sync, which is a separate deliberate step and not part of this PR.

Refs WebDecoy/app#759, WebDecoy/app#476, WebDecoy/app#702

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses were ever seen at more than one site, 93% of attacker addresses were gone inside an hour, and 82% of feed entries were already a week stale with none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now. purge_feed_blocks() deletes the rows earlier versions wrote, and the two connected variants of the CRITICAL notice were rewritten with a comment above them saying not to claim a block. The unconnected variant went on offering "to block threats like it automatically" for another three weeks, four lines below that comment. A comment asking the next person not to do something is not a guard, so there is now a test: it reads every translatable string in the file and fails on one that promises to block, prevent or stop anything. Verified by putting the sentence back. The listing on wordpress.org had two more. It sold "email notifications", which the API refuses (#702) because decoys are public bait and a busy site records thousands of hits a day; email is the monthly report. And it said attackers get pushed to Cloudflare or AWS WAF without saying that happens in the dashboard, which reads, in a plugin readme, like something the plugin does. Both corrected; the WAF claim keeps its substance and gains its location. "Start Free Trial" is now "Create a free account", because there is no trial on this channel: connecting is free and stays free. The settings upsell claimed "email alert automation" for the same reason and is now the webhook plus the monthly report. No behaviour changes, so no version bump. The readme correction is live on wordpress.org only after an SVN sync, which is a separate deliberate step. Refs #759, #476, #702

The alerts entitlement is served to every paid plan and the plugin has never read it. A site that upgraded got a flag it could not see and a feature it could not find. The Cloud tab now says which it is. On Pro: alerts are on, with a link to the dashboard where they are configured. On the free tier: what they are and that detection, blocking and the monthly report stay free, because the answer to "what do I lose by not paying" should be on the same line as the pitch. The plugin still sends nothing itself. That is deliberate and is the PRD's §9 guardrail: an entitlement check may gate a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account at all. Refs WebDecoy/app#762

cport1 · 2026-08-23T00:03:04Z

Added a second commit: the Cloud tab now reads features.alerts and says whether Slack and webhook alerts are on, with a link to where they are configured.

That flag has been served true to paid plans since P0 and read by nothing, here or anywhere. The companion is WebDecoy/app#764, which makes it mean something in the backend and the rule-engine.

The plugin still sends nothing itself, deliberately: the PRD's §9 guardrail is that an entitlement check gates a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account.

The free-tier line names what stays free rather than only what is missing. "What do I lose by not paying" belongs on the same line as the pitch.

cport1 · 2026-08-22T23:26:46Z

Companion to WebDecoy/app#761. Copy only, no behaviour change, no version bump.

The claim that keeps coming back

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses ever seen at more than one site, 93% of attacker addresses gone inside an hour, 82% of feed entries already a week stale, none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now.

That fix landed here in 2.3.2. purge_feed_blocks() deletes the rows earlier versions wrote, and both connected variants of the CRITICAL notice were rewritten with a comment above them:

Must not claim Pro would have BLOCKED this. Since 2.3.2 the cross-site feed is advisory and writes nothing to the block list, on any plan.

Four lines below that comment, the unconnected variant went on offering "and to block threats like it automatically" for another three weeks.

A comment asking the next person not to do something is not a guard. There is now a test: it reads every translatable string in the file and fails on one promising to block, prevent or stop anything. Comments in the file discuss blocking at length and are deliberately exempt. Verified by putting the sentence back:

✗ no translatable string in the file offers to block anything
copy promises "block" — the feed is advisory on every plan and writes
nothing to the block list (#476): A CRITICAL deception trap was just
tripped. Connect to WebDecoy Cloud to see whether this attacker is already
known across the network, and to block threats like it automatically.

The wordpress.org listing

Live on the directory today, so these are the ones a stranger reads.

"Webhooks & Alerts: automated response chains, email notifications." The API refuses per-detection email (#702). Decoys are public bait and a busy site records thousands of hits a day, so "email me on every detection" is a mailbox nobody reads. Now: automated response chains plus a monthly email report.
"Push confirmed attackers to Cloudflare or AWS WAF." True, and it happens in the dashboard. Stated without that, in a plugin readme, it reads like something the plugin does. The claim keeps its substance and gains its location.
"Start Free Trial" → "Create a free account". There is no trial on this channel: a connected site is Free Connected, free, indefinitely. Sending someone to a trial they cannot start is a dead end at the exact moment they decided to sign up.
The settings upsell said "email alert automation" for the same reason, now the webhook plus the monthly report.

Release

95 tests pass, php -l clean on both touched PHP files.

Nothing here changes behaviour, so no version bump. The readme correction only reaches wordpress.org after an SVN sync, which is a separate deliberate step and not part of this PR.

Refs WebDecoy/app#759, WebDecoy/app#476, WebDecoy/app#702

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses were ever seen at more than one site, 93% of attacker addresses were gone inside an hour, and 82% of feed entries were already a week stale with none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now. purge_feed_blocks() deletes the rows earlier versions wrote, and the two connected variants of the CRITICAL notice were rewritten with a comment above them saying not to claim a block. The unconnected variant went on offering "to block threats like it automatically" for another three weeks, four lines below that comment. A comment asking the next person not to do something is not a guard, so there is now a test: it reads every translatable string in the file and fails on one that promises to block, prevent or stop anything. Verified by putting the sentence back. The listing on wordpress.org had two more. It sold "email notifications", which the API refuses (#702) because decoys are public bait and a busy site records thousands of hits a day; email is the monthly report. And it said attackers get pushed to Cloudflare or AWS WAF without saying that happens in the dashboard, which reads, in a plugin readme, like something the plugin does. Both corrected; the WAF claim keeps its substance and gains its location. "Start Free Trial" is now "Create a free account", because there is no trial on this channel: connecting is free and stays free. The settings upsell claimed "email alert automation" for the same reason and is now the webhook plus the monthly report. No behaviour changes, so no version bump. The readme correction is live on wordpress.org only after an SVN sync, which is a separate deliberate step. Refs #759, #476, #702

The alerts entitlement is served to every paid plan and the plugin has never read it. A site that upgraded got a flag it could not see and a feature it could not find. The Cloud tab now says which it is. On Pro: alerts are on, with a link to the dashboard where they are configured. On the free tier: what they are and that detection, blocking and the monthly report stay free, because the answer to "what do I lose by not paying" should be on the same line as the pitch. The plugin still sends nothing itself. That is deliberate and is the PRD's §9 guardrail: an entitlement check may gate a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account at all. Refs WebDecoy/app#762

cport1 · 2026-08-23T00:03:04Z

Added a second commit: the Cloud tab now reads features.alerts and says whether Slack and webhook alerts are on, with a link to where they are configured.

That flag has been served true to paid plans since P0 and read by nothing, here or anywhere. The companion is WebDecoy/app#764, which makes it mean something in the backend and the rule-engine.

The plugin still sends nothing itself, deliberately: the PRD's §9 guardrail is that an entitlement check gates a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account.

The free-tier line names what stays free rather than only what is missing. "What do I lose by not paying" belongs on the same line as the pitch.

cport1 · 2026-08-22T23:26:46Z

Companion to WebDecoy/app#761. Copy only, no behaviour change, no version bump.

The claim that keeps coming back

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses ever seen at more than one site, 93% of attacker addresses gone inside an hour, 82% of feed entries already a week stale, none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now.

That fix landed here in 2.3.2. purge_feed_blocks() deletes the rows earlier versions wrote, and both connected variants of the CRITICAL notice were rewritten with a comment above them:

Must not claim Pro would have BLOCKED this. Since 2.3.2 the cross-site feed is advisory and writes nothing to the block list, on any plan.

Four lines below that comment, the unconnected variant went on offering "and to block threats like it automatically" for another three weeks.

A comment asking the next person not to do something is not a guard. There is now a test: it reads every translatable string in the file and fails on one promising to block, prevent or stop anything. Comments in the file discuss blocking at length and are deliberately exempt. Verified by putting the sentence back:

✗ no translatable string in the file offers to block anything
copy promises "block" — the feed is advisory on every plan and writes
nothing to the block list (#476): A CRITICAL deception trap was just
tripped. Connect to WebDecoy Cloud to see whether this attacker is already
known across the network, and to block threats like it automatically.

The wordpress.org listing

Live on the directory today, so these are the ones a stranger reads.

"Webhooks & Alerts: automated response chains, email notifications." The API refuses per-detection email (#702). Decoys are public bait and a busy site records thousands of hits a day, so "email me on every detection" is a mailbox nobody reads. Now: automated response chains plus a monthly email report.
"Push confirmed attackers to Cloudflare or AWS WAF." True, and it happens in the dashboard. Stated without that, in a plugin readme, it reads like something the plugin does. The claim keeps its substance and gains its location.
"Start Free Trial" → "Create a free account". There is no trial on this channel: a connected site is Free Connected, free, indefinitely. Sending someone to a trial they cannot start is a dead end at the exact moment they decided to sign up.
The settings upsell said "email alert automation" for the same reason, now the webhook plus the monthly report.

Release

95 tests pass, php -l clean on both touched PHP files.

Nothing here changes behaviour, so no version bump. The readme correction only reaches wordpress.org after an SVN sync, which is a separate deliberate step and not part of this PR.

Refs WebDecoy/app#759, WebDecoy/app#476, WebDecoy/app#702

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses were ever seen at more than one site, 93% of attacker addresses were gone inside an hour, and 82% of feed entries were already a week stale with none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now. purge_feed_blocks() deletes the rows earlier versions wrote, and the two connected variants of the CRITICAL notice were rewritten with a comment above them saying not to claim a block. The unconnected variant went on offering "to block threats like it automatically" for another three weeks, four lines below that comment. A comment asking the next person not to do something is not a guard, so there is now a test: it reads every translatable string in the file and fails on one that promises to block, prevent or stop anything. Verified by putting the sentence back. The listing on wordpress.org had two more. It sold "email notifications", which the API refuses (#702) because decoys are public bait and a busy site records thousands of hits a day; email is the monthly report. And it said attackers get pushed to Cloudflare or AWS WAF without saying that happens in the dashboard, which reads, in a plugin readme, like something the plugin does. Both corrected; the WAF claim keeps its substance and gains its location. "Start Free Trial" is now "Create a free account", because there is no trial on this channel: connecting is free and stays free. The settings upsell claimed "email alert automation" for the same reason and is now the webhook plus the monthly report. No behaviour changes, so no version bump. The readme correction is live on wordpress.org only after an SVN sync, which is a separate deliberate step. Refs #759, #476, #702

The alerts entitlement is served to every paid plan and the plugin has never read it. A site that upgraded got a flag it could not see and a feature it could not find. The Cloud tab now says which it is. On Pro: alerts are on, with a link to the dashboard where they are configured. On the free tier: what they are and that detection, blocking and the monthly report stay free, because the answer to "what do I lose by not paying" should be on the same line as the pitch. The plugin still sends nothing itself. That is deliberate and is the PRD's §9 guardrail: an entitlement check may gate a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account at all. Refs WebDecoy/app#762

cport1 · 2026-08-23T00:03:04Z

Added a second commit: the Cloud tab now reads features.alerts and says whether Slack and webhook alerts are on, with a link to where they are configured.

That flag has been served true to paid plans since P0 and read by nothing, here or anywhere. The companion is WebDecoy/app#764, which makes it mean something in the backend and the rule-engine.

The plugin still sends nothing itself, deliberately: the PRD's §9 guardrail is that an entitlement check gates a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account.

The free-tier line names what stays free rather than only what is missing. "What do I lose by not paying" belongs on the same line as the pitch.

cport1 · 2026-08-22T23:26:46Z

Companion to WebDecoy/app#761. Copy only, no behaviour change, no version bump.

The claim that keeps coming back

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses ever seen at more than one site, 93% of attacker addresses gone inside an hour, 82% of feed entries already a week stale, none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now.

That fix landed here in 2.3.2. purge_feed_blocks() deletes the rows earlier versions wrote, and both connected variants of the CRITICAL notice were rewritten with a comment above them:

Must not claim Pro would have BLOCKED this. Since 2.3.2 the cross-site feed is advisory and writes nothing to the block list, on any plan.

Four lines below that comment, the unconnected variant went on offering "and to block threats like it automatically" for another three weeks.

A comment asking the next person not to do something is not a guard. There is now a test: it reads every translatable string in the file and fails on one promising to block, prevent or stop anything. Comments in the file discuss blocking at length and are deliberately exempt. Verified by putting the sentence back:

✗ no translatable string in the file offers to block anything
copy promises "block" — the feed is advisory on every plan and writes
nothing to the block list (#476): A CRITICAL deception trap was just
tripped. Connect to WebDecoy Cloud to see whether this attacker is already
known across the network, and to block threats like it automatically.

The wordpress.org listing

Live on the directory today, so these are the ones a stranger reads.

"Webhooks & Alerts: automated response chains, email notifications." The API refuses per-detection email (#702). Decoys are public bait and a busy site records thousands of hits a day, so "email me on every detection" is a mailbox nobody reads. Now: automated response chains plus a monthly email report.
"Push confirmed attackers to Cloudflare or AWS WAF." True, and it happens in the dashboard. Stated without that, in a plugin readme, it reads like something the plugin does. The claim keeps its substance and gains its location.
"Start Free Trial" → "Create a free account". There is no trial on this channel: a connected site is Free Connected, free, indefinitely. Sending someone to a trial they cannot start is a dead end at the exact moment they decided to sign up.
The settings upsell said "email alert automation" for the same reason, now the webhook plus the monthly report.

Release

95 tests pass, php -l clean on both touched PHP files.

Nothing here changes behaviour, so no version bump. The readme correction only reaches wordpress.org after an SVN sync, which is a separate deliberate step and not part of this PR.

Refs WebDecoy/app#759, WebDecoy/app#476, WebDecoy/app#702

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses were ever seen at more than one site, 93% of attacker addresses were gone inside an hour, and 82% of feed entries were already a week stale with none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now. purge_feed_blocks() deletes the rows earlier versions wrote, and the two connected variants of the CRITICAL notice were rewritten with a comment above them saying not to claim a block. The unconnected variant went on offering "to block threats like it automatically" for another three weeks, four lines below that comment. A comment asking the next person not to do something is not a guard, so there is now a test: it reads every translatable string in the file and fails on one that promises to block, prevent or stop anything. Verified by putting the sentence back. The listing on wordpress.org had two more. It sold "email notifications", which the API refuses (#702) because decoys are public bait and a busy site records thousands of hits a day; email is the monthly report. And it said attackers get pushed to Cloudflare or AWS WAF without saying that happens in the dashboard, which reads, in a plugin readme, like something the plugin does. Both corrected; the WAF claim keeps its substance and gains its location. "Start Free Trial" is now "Create a free account", because there is no trial on this channel: connecting is free and stays free. The settings upsell claimed "email alert automation" for the same reason and is now the webhook plus the monthly report. No behaviour changes, so no version bump. The readme correction is live on wordpress.org only after an SVN sync, which is a separate deliberate step. Refs #759, #476, #702

The alerts entitlement is served to every paid plan and the plugin has never read it. A site that upgraded got a flag it could not see and a feature it could not find. The Cloud tab now says which it is. On Pro: alerts are on, with a link to the dashboard where they are configured. On the free tier: what they are and that detection, blocking and the monthly report stay free, because the answer to "what do I lose by not paying" should be on the same line as the pitch. The plugin still sends nothing itself. That is deliberate and is the PRD's §9 guardrail: an entitlement check may gate a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account at all. Refs WebDecoy/app#762

cport1 · 2026-08-23T00:03:04Z

Added a second commit: the Cloud tab now reads features.alerts and says whether Slack and webhook alerts are on, with a link to where they are configured.

That flag has been served true to paid plans since P0 and read by nothing, here or anywhere. The companion is WebDecoy/app#764, which makes it mean something in the backend and the rule-engine.

The plugin still sends nothing itself, deliberately: the PRD's §9 guardrail is that an entitlement check gates a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account.

The free-tier line names what stays free rather than only what is missing. "What do I lose by not paying" belongs on the same line as the pitch.

cport1 · 2026-08-22T23:26:46Z

Companion to WebDecoy/app#761. Copy only, no behaviour change, no version bump.

The claim that keeps coming back

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses ever seen at more than one site, 93% of attacker addresses gone inside an hour, 82% of feed entries already a week stale, none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now.

That fix landed here in 2.3.2. purge_feed_blocks() deletes the rows earlier versions wrote, and both connected variants of the CRITICAL notice were rewritten with a comment above them:

Must not claim Pro would have BLOCKED this. Since 2.3.2 the cross-site feed is advisory and writes nothing to the block list, on any plan.

Four lines below that comment, the unconnected variant went on offering "and to block threats like it automatically" for another three weeks.

A comment asking the next person not to do something is not a guard. There is now a test: it reads every translatable string in the file and fails on one promising to block, prevent or stop anything. Comments in the file discuss blocking at length and are deliberately exempt. Verified by putting the sentence back:

✗ no translatable string in the file offers to block anything
copy promises "block" — the feed is advisory on every plan and writes
nothing to the block list (#476): A CRITICAL deception trap was just
tripped. Connect to WebDecoy Cloud to see whether this attacker is already
known across the network, and to block threats like it automatically.

The wordpress.org listing

Live on the directory today, so these are the ones a stranger reads.

"Webhooks & Alerts: automated response chains, email notifications." The API refuses per-detection email (#702). Decoys are public bait and a busy site records thousands of hits a day, so "email me on every detection" is a mailbox nobody reads. Now: automated response chains plus a monthly email report.
"Push confirmed attackers to Cloudflare or AWS WAF." True, and it happens in the dashboard. Stated without that, in a plugin readme, it reads like something the plugin does. The claim keeps its substance and gains its location.
"Start Free Trial" → "Create a free account". There is no trial on this channel: a connected site is Free Connected, free, indefinitely. Sending someone to a trial they cannot start is a dead end at the exact moment they decided to sign up.
The settings upsell said "email alert automation" for the same reason, now the webhook plus the monthly report.

Release

95 tests pass, php -l clean on both touched PHP files.

Nothing here changes behaviour, so no version bump. The readme correction only reaches wordpress.org after an SVN sync, which is a separate deliberate step and not part of this PR.

Refs WebDecoy/app#759, WebDecoy/app#476, WebDecoy/app#702

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses were ever seen at more than one site, 93% of attacker addresses were gone inside an hour, and 82% of feed entries were already a week stale with none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now. purge_feed_blocks() deletes the rows earlier versions wrote, and the two connected variants of the CRITICAL notice were rewritten with a comment above them saying not to claim a block. The unconnected variant went on offering "to block threats like it automatically" for another three weeks, four lines below that comment. A comment asking the next person not to do something is not a guard, so there is now a test: it reads every translatable string in the file and fails on one that promises to block, prevent or stop anything. Verified by putting the sentence back. The listing on wordpress.org had two more. It sold "email notifications", which the API refuses (#702) because decoys are public bait and a busy site records thousands of hits a day; email is the monthly report. And it said attackers get pushed to Cloudflare or AWS WAF without saying that happens in the dashboard, which reads, in a plugin readme, like something the plugin does. Both corrected; the WAF claim keeps its substance and gains its location. "Start Free Trial" is now "Create a free account", because there is no trial on this channel: connecting is free and stays free. The settings upsell claimed "email alert automation" for the same reason and is now the webhook plus the monthly report. No behaviour changes, so no version bump. The readme correction is live on wordpress.org only after an SVN sync, which is a separate deliberate step. Refs #759, #476, #702

The alerts entitlement is served to every paid plan and the plugin has never read it. A site that upgraded got a flag it could not see and a feature it could not find. The Cloud tab now says which it is. On Pro: alerts are on, with a link to the dashboard where they are configured. On the free tier: what they are and that detection, blocking and the monthly report stay free, because the answer to "what do I lose by not paying" should be on the same line as the pitch. The plugin still sends nothing itself. That is deliberate and is the PRD's §9 guardrail: an entitlement check may gate a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account at all. Refs WebDecoy/app#762

cport1 · 2026-08-23T00:03:04Z

Added a second commit: the Cloud tab now reads features.alerts and says whether Slack and webhook alerts are on, with a link to where they are configured.

That flag has been served true to paid plans since P0 and read by nothing, here or anywhere. The companion is WebDecoy/app#764, which makes it mean something in the backend and the rule-engine.

The plugin still sends nothing itself, deliberately: the PRD's §9 guardrail is that an entitlement check gates a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account.

The free-tier line names what stays free rather than only what is missing. "What do I lose by not paying" belongs on the same line as the pitch.

cport1 · 2026-08-22T23:26:46Z

Companion to WebDecoy/app#761. Copy only, no behaviour change, no version bump.

The claim that keeps coming back

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses ever seen at more than one site, 93% of attacker addresses gone inside an hour, 82% of feed entries already a week stale, none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now.

That fix landed here in 2.3.2. purge_feed_blocks() deletes the rows earlier versions wrote, and both connected variants of the CRITICAL notice were rewritten with a comment above them:

Must not claim Pro would have BLOCKED this. Since 2.3.2 the cross-site feed is advisory and writes nothing to the block list, on any plan.

Four lines below that comment, the unconnected variant went on offering "and to block threats like it automatically" for another three weeks.

A comment asking the next person not to do something is not a guard. There is now a test: it reads every translatable string in the file and fails on one promising to block, prevent or stop anything. Comments in the file discuss blocking at length and are deliberately exempt. Verified by putting the sentence back:

✗ no translatable string in the file offers to block anything
copy promises "block" — the feed is advisory on every plan and writes
nothing to the block list (#476): A CRITICAL deception trap was just
tripped. Connect to WebDecoy Cloud to see whether this attacker is already
known across the network, and to block threats like it automatically.

The wordpress.org listing

Live on the directory today, so these are the ones a stranger reads.

"Webhooks & Alerts: automated response chains, email notifications." The API refuses per-detection email (#702). Decoys are public bait and a busy site records thousands of hits a day, so "email me on every detection" is a mailbox nobody reads. Now: automated response chains plus a monthly email report.
"Push confirmed attackers to Cloudflare or AWS WAF." True, and it happens in the dashboard. Stated without that, in a plugin readme, it reads like something the plugin does. The claim keeps its substance and gains its location.
"Start Free Trial" → "Create a free account". There is no trial on this channel: a connected site is Free Connected, free, indefinitely. Sending someone to a trial they cannot start is a dead end at the exact moment they decided to sign up.
The settings upsell said "email alert automation" for the same reason, now the webhook plus the monthly report.

Release

95 tests pass, php -l clean on both touched PHP files.

Nothing here changes behaviour, so no version bump. The readme correction only reaches wordpress.org after an SVN sync, which is a separate deliberate step and not part of this PR.

Refs WebDecoy/app#759, WebDecoy/app#476, WebDecoy/app#702

#476 withdrew blocking from the cross-site actor feed after measuring it against production: 2 of 4,866 addresses were ever seen at more than one site, 93% of attacker addresses were gone inside an hour, and 82% of feed entries were already a week stale with none still active. Blocking an abandoned address does not stop the attacker, it stops whoever holds it now. purge_feed_blocks() deletes the rows earlier versions wrote, and the two connected variants of the CRITICAL notice were rewritten with a comment above them saying not to claim a block. The unconnected variant went on offering "to block threats like it automatically" for another three weeks, four lines below that comment. A comment asking the next person not to do something is not a guard, so there is now a test: it reads every translatable string in the file and fails on one that promises to block, prevent or stop anything. Verified by putting the sentence back. The listing on wordpress.org had two more. It sold "email notifications", which the API refuses (#702) because decoys are public bait and a busy site records thousands of hits a day; email is the monthly report. And it said attackers get pushed to Cloudflare or AWS WAF without saying that happens in the dashboard, which reads, in a plugin readme, like something the plugin does. Both corrected; the WAF claim keeps its substance and gains its location. "Start Free Trial" is now "Create a free account", because there is no trial on this channel: connecting is free and stays free. The settings upsell claimed "email alert automation" for the same reason and is now the webhook plus the monthly report. No behaviour changes, so no version bump. The readme correction is live on wordpress.org only after an SVN sync, which is a separate deliberate step. Refs #759, #476, #702

The alerts entitlement is served to every paid plan and the plugin has never read it. A site that upgraded got a flag it could not see and a feature it could not find. The Cloud tab now says which it is. On Pro: alerts are on, with a link to the dashboard where they are configured. On the free tier: what they are and that detection, blocking and the monthly report stay free, because the answer to "what do I lose by not paying" should be on the same line as the pitch. The plugin still sends nothing itself. That is deliberate and is the PRD's §9 guardrail: an entitlement check may gate a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account at all. Refs WebDecoy/app#762

cport1 · 2026-08-23T00:03:04Z

Added a second commit: the Cloud tab now reads features.alerts and says whether Slack and webhook alerts are on, with a link to where they are configured.

That flag has been served true to paid plans since P0 and read by nothing, here or anywhere. The companion is WebDecoy/app#764, which makes it mean something in the backend and the rule-engine.

The plugin still sends nothing itself, deliberately: the PRD's §9 guardrail is that an entitlement check gates a cloud response and never local behaviour. Everything this plugin does on its own keeps working on every plan, including with no account.

The free-tier line names what stays free rather than only what is missing. "What do I lose by not paying" belongs on the same line as the pitch.

cport1 added 2 commits August 22, 2026 18:25

chore: escape the alerts icon class
6fd4196

cport1 added 2 commits August 22, 2026 18:25

chore: escape the alerts icon class
6fd4196

cport1 added 2 commits August 22, 2026 18:25

chore: escape the alerts icon class
6fd4196

cport1 added 2 commits August 22, 2026 18:25

chore: escape the alerts icon class
6fd4196

cport1 added 2 commits August 22, 2026 18:25

chore: escape the alerts icon class
6fd4196

cport1 added 2 commits August 22, 2026 18:25

chore: escape the alerts icon class
6fd4196

cport1 added 2 commits August 22, 2026 18:25

chore: escape the alerts icon class
6fd4196

cport1 added 2 commits August 22, 2026 18:25

chore: escape the alerts icon class
6fd4196

Uh oh!

Conversation

cport1 commented Aug 22, 2026

The claim that keeps coming back

The wordpress.org listing

Release

Uh oh!

cport1 commented Aug 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

cport1 commented Aug 22, 2026

The claim that keeps coming back

The wordpress.org listing

Release

Uh oh!

cport1 commented Aug 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

cport1 commented Aug 22, 2026

The claim that keeps coming back

The wordpress.org listing

Release

Uh oh!

cport1 commented Aug 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

cport1 commented Aug 22, 2026

The claim that keeps coming back

The wordpress.org listing

Release

Uh oh!

cport1 commented Aug 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

cport1 commented Aug 22, 2026

The claim that keeps coming back

The wordpress.org listing

Release

Uh oh!

cport1 commented Aug 23, 2026

Uh oh!

Reviewers

Assignees

Labels