The panel fields are simply used for a nice way to interact with the data. They do not change how it is rendered. Since rendering is done outside of the panel, you need to manage obfuscation in your template, or use the kirbytag email like you mentioned.
It’s what the kirbytag email uses to generate it’s obfuscated email. Use it inside your <p> tag. It creates that <a href="mailto: tag with obfuscated email.
@texnixe, would it not be a good idea to include either the kirbytag() approach or the html::email($site->email()) or the str::encode() one in the docs? (or both?) I use them veeery often, and since people are asking (and spending two months developing plugins ), it seems I’m not alone.
The inspector often decodes the entity encoding again for better readability. Please take a look at the raw source code – it should contain the encoded version.
I wrote a small plugin to automatically encode emails in kirbytext and to provide a fieldMethod to apply the same filter to other fields, e.g. block-textfields.
This also works if a email gets wrapped in an A-Tag, because only the emails found are converted to encoded characters.
I imagine this is useful, in order that no rawtext email gets output on the website.
Maybe it’s also useful for someone here:
<?php
class Encode {
public static function email ($value) {
return Str::encode($value);
}
public static function emailsInText ($text) {
$text = preg_replace_callback('/[A-Z0-9\._%+-]+(@)[A-Z0-9\.-]+(\.)[a-z]{2,6}/i', function($match) {
return Encode::email($match[0]);
}, $text);
return $text;
}
}
Kirby::plugin('site/encode', [
'fieldMethods' => [
'encodeEmail' => function ($field) {
$field->value = Encode::email($field->value);
return $field;
},
'encodeEmails' => function ($field) {
$field->value = Encode::emailsInText($field->value);
return $field;
},
],
'hooks' => [
'kirbytext:after' => function ($text) { return Encode::emailsInText($text); }
],
]);