Sulu Email Obfuscator Bundle Laravel Package

Product Decisions This Supports

• Publishing contact addresses without inviting spam. Any page that must legally or commercially show a real mailto: address (contact, press, team, imprint, tender documents) gets a harvesting defence without removing the address — a product/compliance decision, not just a technical one.
• Zero-template-change rollout (build vs. buy vs. build-in-house). Because the rewriting happens on the finished HTML response, adoption does not require retraining editors, migrating Twig templates, or coordinating a content freeze. That materially lowers the cost side of the build-vs-adopt comparison against a homegrown regex/middleware solution.
• Scope of the first release is deliberately narrow, which is itself a product signal: response-level rewriting as the default, Twig filters (sulu_obfuscate_email, sulu_obfuscate_emails) as the opt-in escape hatch where a template wants to own the decision. This supports a "safe default, explicit override" product posture rather than a configuration matrix.
• Editorial QA is preserved. The preview request attribute is respected, so previews show genuine addresses. This protects the editorial review workflow and avoids a class of "why is my page showing garbage?" support tickets — a real adoption blocker for CMS features.
• Instrumentation hook. The data-obfuscated-email marker means the client knows what to decode and the rewriter knows what it has already processed. For a PM this is the basis for idempotency guarantees (double-processing, nested rewrites) and for later analytics or audit work without a schema change.
• Roadmap input: whether email obfuscation belongs in the platform baseline or stays an optional package; whether further coverage (JSON-LD, title attributes, form values) is needed; whether the same response-rewriting pattern is worth reusing for other content-hardening needs.

When to Consider This Package

Consider it when:

• The site runs on Sulu and renders mailto: links server-side in HTML.
• You cannot or do not want to touch existing templates or the editorial workflow.
• Editors occasionally need to opt in or out per template — the Twig filters provide that without a global config switch.
• You want a small, single-purpose dependency with an explicit, auditable exclusion list rather than an opaque anti-spam service.
• Preview correctness matters to the content team.

Look elsewhere or plan mitigations when:

• You are not on Sulu. The preview handling reads a Sulu request attribute; this is not a drop-in for a generic Laravel/Symfony app without adaptation.
• Addresses appear outside HTML link text/href. Comments, script, style, textarea, title, and non-mailto link content are intentionally untouched — so emails in JSON-LD/structured data, analytics snippets, title tooltips, or textarea content remain harvestable.
• Addresses are injected client-side by JavaScript; the response rewriter will never see them.
• Decoding requires JavaScript. Confirm the no-JS and crawler behaviour before committing: obfuscated addresses that cannot be decoded or indexed have SEO, accessibility (screen readers, copy-paste, link previews) and machine-readability consequences.
• You need defence in depth. This is one layer; keep server-side form protection, rate limiting, and monitoring on the roadmap regardless.
• Maturity risk is unacceptable right now. This is v1.0.0 — the first release — with no production track record. Pin the version and stage the rollout.

How to Pitch It (Stakeholders)

For executives: A small, free, single-purpose addition that hides published email addresses from spam harvesters without changing a single page template or asking the content team to relearn anything. Cost is a dependency and a short QA pass; the benefit is reduced spam volume and reduced pressure to remove contact addresses that regulators, customers, or partners expect to find. It is a first release, so treat it as a low-risk, reversible pilot on one site rather than a platform-wide standard.

For engineering: Response-level rewriter plus two Twig filters, a data-obfuscated-email marker for idempotency and client-side reversal, a preview bypass, and a conservative exclusion list (comments, script, style, textarea, title, non-mailto links). Small surface area, easy to unit-test against fixture HTML, no template changes, no database migration. Ask before adoption: no-JS fallback behaviour, double-rewrite safety, and whether JSON-LD/structured-data emails need a follow-up.

For editorial and support: Nothing changes in how you work. Previews show real addresses. If a template needs special handling, it opts in explicitly rather than guessing.

Recommendation: Adopt as an evaluated pilot on a non-critical site, pin the version, and define the missing-coverage list (structured data, title attributes, JS-injected addresses) as the gate for wider rollout.