CryptX

CryptX uses various methods to hide email addresses from spambots while keeping them functional for visitors. Methods include JavaScript encryption, Unicode conversion, and replacing emails with images or custom text.

CryptX is designed to be lightweight and only loads JavaScript when needed. The performance impact is minimal.

Yes. Under Settings / CryptX / Exceptions there is a list of addresses to leave alone. Write "info@example.com" for a single address, or "@example.com" to cover every address at that domain. CryptX leaves those addresses exactly as written -- it does not mask, link or encrypt them -- which is what you want for an address a helpdesk has to read out of the page, or one shown in a code example. There are two limits on purpose. Inside [cryptx]...[/cryptx] -- and inside the "Protected email address" block, which is the same instruction in a different shape -- nothing is exempt: it says "protect this one, here", and a setting made months ago on another screen is not an answer to that. Where the shortcode is written somewhere WordPress never expands it, such as a hand-written excerpt, this reaches a little further: an exempt address standing next to it in the same text is protected as well. That is the harmless direction, but worth knowing if you exempted an address precisely so a machine could read it. And in comments only a whole address counts, never the domain form -- otherwise exempting your own domain would hand out every address at that domain a visitor happened to leave in a comment. One more thing worth knowing about comments: WordPress itself turns a bare address into a link before CryptX ever sees it, so an exempt address stays readable there but does become a link. That distinction rests on which filter the text arrives through, and only comments can be told apart with certainty. Forum and front-end submission plugins -- bbPress and BuddyPress among them -- send what a visitor wrote through the same filter as your own posts, so the domain form does apply there. If your site takes text from visitors that way, exempt the individual addresses rather than a whole domain. Two neighbouring settings answer different questions. The list of endings ("jpeg,jpg,png,gif") is what keeps file names such as logo@2x.png from being mistaken for an address in the first place. The list of post IDs switches CryptX off for a whole post or page.

An address such as "post@münchen.de" is not protected -- CryptX looks for addresses using the ASCII form, so it does not recognise one with an accented or non-Latin domain in the first place. Write the domain in its punycode form ("post@xn--mnchen-3ya.de") and everything works as usual. The editor block says so where you type it; elsewhere the address is simply left as it was.

Yes, including network activation. Every site keeps its own settings and its own encryption secret, so nothing one site publishes can be read with another site's key. Sites created later are set up the same way as those that existed at activation time, and uninstalling removes the plugin's data from every site in the network. The settings live per site, because that is where the addresses and the design live. A site administrator configures their own site as usual. Since 4.2.0 a network administrator can set the defaults a newly created site starts with, under Network Admin / Settings / CryptX -- a starting point, not an instruction: sites that already exist are never changed by it, and a site administrator can change theirs at any time. Two settings are missing from that screen on purpose. The list of excluded post IDs and the uploaded image both refer to things that exist on one site only: post 17 on one site has nothing to do with post 17 on another, and copying that list would exclude the wrong posts -- which is precisely what left addresses unprotected on some networks before 4.1.1.

Yes, with WP-CLI. wp cryptx settings lists every setting with its current value; wp cryptx settings <name> reads one and wp cryptx settings <name> <value> writes it, through the same validation the settings screen uses. wp cryptx scan is the one worth knowing about. It runs every published post through the filters that render it and reports the ones that still carry a readable address -- the question you actually have after changing a setting, and the one the settings screen cannot answer, because it only ever renders a single sample. An "encoded" verdict means the address is in the page as HTML entities: invisible to a naive scanner, plain to anything that decodes them. It reads the body and the title of each post, and a "where" column says which of the two. Titles matter here because CryptX cannot protect them: a title goes into the document head through WordPress itself, along a path no plugin filter touches. An address in a post title is readable, and the only fix is to take it out of the title. What the scan does not cover: widgets, comments, feeds, and anything a theme prints on its own. It is a check on your posts and pages, not a clean bill of health for the whole site. On a network both take --url, so wp site list --field=url | xargs -I{} wp cryptx scan --url={} covers the whole network.

CryptX primarily works with email addresses displayed in content. It doesn't interfere with contact forms or other form functionality.

Yes, you can enable the meta box feature to control encryption on individual posts and pages. For more information, visit the Plugin Homepage