PluginProbe
CryptX / 4.2.1
CryptX v4.2.1
4.2.1 4.2.0 4.1.1 trunk 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.9 2.0 2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.4.0 2.4.1 2.4.2 2.4.3 2.4.4 All 93 releases
← All changes | src/components/HelpTab.js +59 -2 4.1.14.2.1 View file →
@@ -134,16 +134,22 @@
134 134 </CardHeader>
135 135 <CardBody>
136 136 <p>
137 137 { __(
138 - 'The shortcode works even in posts you excluded from CryptX, which makes it the way to protect one address in otherwise untouched content.',
138 + 'In the editor, look for the "Protected email address" block — it does the same thing with fields instead of syntax, and it is the easier way in. The shortcode below is for everywhere a block cannot go: a widget, a custom field, a theme template.',
139 139 'cryptx'
140 140 ) }
141 141 </p>
142 + <p>
143 + { __(
144 + 'Both outrank the two ways of switching CryptX off: they work in posts you excluded, and inside them no address is exempt, however the list under Exceptions reads. That makes them the way to protect one address in otherwise untouched content.',
145 + 'cryptx'
146 + ) }
147 + </p>
142 148 <Snippet>{ '[cryptx]info@example.com[/cryptx]' }</Snippet>
143 149 <p>
144 150 { __(
145 - 'Any setting from this screen can be overridden for a single shortcode by using its option name, written in lower case:',
151 + 'Almost any setting from this screen can be overridden for a single shortcode by using its option name, written in lower case. The list of addresses to leave alone is the exception, and deliberately so: a shortcode says "protect this one", so nothing inside it is ever exempt.',
146 152 'cryptx'
147 153 ) }
148 154 </p>
149 155 <Snippet>
@@ -226,8 +232,59 @@
226 232 <Snippet>
227 233 { `const link = document.createElement( 'a' );
228 234 link.href = generateDeCryptXHandler( 'info@example.com' );
229 235 link.textContent = 'Contact us';` }
236 + </Snippet>
237 + </CardBody>
238 + </Card>
239 +
240 + <Card className="cryptx-section">
241 + <CardHeader>
242 + <h2 className="cryptx-section__title">
243 + { __( 'On the command line', 'cryptx' ) }
244 + </h2>
245 + </CardHeader>
246 + <CardBody>
247 + <p>
248 + { __(
249 + 'With WP-CLI installed. The first two read and write the settings, through the same validation this screen uses.',
250 + 'cryptx'
251 + ) }
252 + </p>
253 + <Snippet>
254 + { `wp cryptx settings
255 +wp cryptx settings opt_linktext
256 +wp cryptx settings disable_rss 0` }
257 + </Snippet>
258 + <p>
259 + { __(
260 + 'The third is the one worth knowing about: it runs the body and the title of every published post through the filters that render it, and reports the ones that still carry a readable address. That is the question you have after changing a setting, and the preview above cannot answer it — it only ever renders a single sample.',
261 + 'cryptx'
262 + ) }
263 + </p>
264 + <Snippet>{ 'wp cryptx scan' }</Snippet>
265 + <p className="cryptx-help__note">
266 + { __(
267 + 'A verdict of "encoded" means the address is in the page as HTML entities. That is invisible to a naive scanner and plain to anything that decodes them, which is most things — it is not the same as "hidden".',
268 + 'cryptx'
269 + ) }
270 + </p>
271 + <p className="cryptx-help__note">
272 + { __(
273 + 'An address in a post title is always reported, because CryptX cannot protect one: the title reaches the document head through WordPress itself, along a path no plugin filter touches. Take it out of the title. And what the scan does not cover: widgets, comments, feeds, and whatever a theme prints on its own.',
274 + 'cryptx'
275 + ) }
276 + </p>
277 + <p>
278 + { __(
279 + 'On a multisite network both take --url, so one shell loop covers every site:',
280 + 'cryptx'
281 + ) }
282 + </p>
283 + <Snippet>
284 + {
285 + 'wp site list --field=url | xargs -I{} wp cryptx scan --url={}'
286 + }
230 287 </Snippet>
231 288 </CardBody>
232 289 </Card>
233 290