WPIntell

Source evidence

Fatal error (eeb_protect_emails function)

Email Encoder – Protect Email Addresses and Phone Numbers · support · 2026-01-07T12:33:00+00:00

mixedsentiment
highseverity
0.94relevance
4replies
Evidence linked to opportunitycommercial context

Proof Health

Open evidence

Commercial opportunities need traceable source links before they are treated as build-worthy.

4 / 28 rows with source links

14.3% of this page's analysis has direct source links.

0 build-decision rows missing links

0 rows here require auditable proof before promotion.

24 rows with no attached evidence

0 rows have source counts but still need direct links.

Conversation

support
la_ri_za resolved
After upgrading to 2.3.9 I see this error [07-Jan-2026 11:56:50 UTC] PHP Fatal error: Uncaught Error: Call to undefined method OnlineOptimisation\EmailEncoderBundle\Validate\Validate::filter_content() in .../wp-content/plugins/email-encoder-bundle/core/includes/functions/template-tags.php:155 Stack trace: #0 .../wp-content/plugins/email-encoder-bundle/core/includes/functions/template-tags.php(142): eeb_protect_emails() ... Hi @la_ri_za Thanks for bringing this to our attention. We found a bug that could trigger an error under specific conditions, and it’s been fixed in the latest release. Please update the plugin (v2.4.0) and check if everything works as expected now. Great, thank you! Everything works now. 🙂 @ooivan The changelog entries for the last five version all state Fix: Bug fixes As a developer I am relying on a proper changelog in order to determine what every version brings about in terms of code changes and I would appreciate if you could provide us with a more elaborate protocol. That said: Thank you very much for providing the plugin and makeing the (WordPress-)web a safer place! Hi @leanderbraunschweig That’s a totally fair point, and I agree with you! I was (perhaps a bit too much) following the “best practice” you often see from big players, where changes get bundled under vague labels like “bug fixes”, “security update”, or “various improvements”. What we’ve been doing recently is modernising the codebase while keeping all existing functionality intact. The plugin has been around for quite a while, and over the years it’s lived through multiple PHP and WordPress versions, along with coding standards and best practices that made sense at the time. Untangling that isn’t trivial. A lot of the recent “bug fixes” are actually part of this cleanup work: improving structure, testability, reliability, removing dead code, and addressing issues we uncovered along the way – some of which were genuine bugs. It’s very much a work in progress, but the goal is to move away from just carrying legacy code forward and instead properly clean things up before building further. I’ll definitely be more explicit in the changelog going forward. Thanks for calling it out 🙂 This reply was modified 5 months, 3 weeks ago by Ivan .

Comments

4 shown
Ivan 2026-01-08T04:08:00+00:00

Hi @la_ri_za Thanks for bringing this to our attention. We found a bug that could trigger an error under specific conditions, and it’s been fixed in the latest release. Please update the plugin (v2.4.0) and check if everything works as expected now.

la_ri_za 2026-01-08T10:05:00+00:00

Great, thank you! Everything works now. 🙂

leanderbraunschweig 2026-01-09T06:46:00+00:00

@ooivan The changelog entries for the last five version all state Fix: Bug fixes As a developer I am relying on a proper changelog in order to determine what every version brings about in terms of code changes and I would appreciate if you could provide us with a more elaborate protocol. That said: Thank you very much for providing the plugin and makeing the (WordPress-)web a safer place!

Ivan 2026-01-12T06:48:00+00:00

Hi @leanderbraunschweig That’s a totally fair point, and I agree with you! I was (perhaps a bit too much) following the “best practice” you often see from big players, where changes get bundled under vague labels like “bug fixes”, “security update”, or “various improvements”. What we’ve been doing recently is modernising the codebase while keeping all existing functionality intact. The plugin has been around for quite a while, and over the years it’s lived through multiple PHP and WordPress versions, along with coding standards and best practices that made sense at the time. Untangling that isn’t trivial. A lot of the recent “bug fixes” are actually part of this cleanup work: improving structure, testability, reliability, removing dead code, and addressing issues we uncovered along the way – some of which were genuine bugs. It’s very much a work in progress, but the goal is to move away from just carrying legacy code forward and instead properly clean things up before building further. I’ll definitely be more explicit in the changelog going forward. Thanks for calling it out 🙂 This reply was modified 5 months, 3 weeks ago by Ivan .