You absolutely should not be using custom fields in this way it is not what it is intended to be used for and changing it would introduce security vulnerabilities.

Hi @brianteeman,

Thank you for your feedback. I understand the security concerns regarding XSS and field data.

However, my point is about consistency and administrative control. As a Super User with "No Filtering" enabled, I am already trusted to inject scripts directly into an article's body (com_content). If the system trusts me to do this in an article, why is it considered a security vulnerability to do the exact same thing in a Custom Field assigned to that same article?

By restricting this, we lose the ability to manage repetitive scripts (like FAQ schema, tracking snippets, or specific UI interactions) from a single location. Currently, I am forced to hardcode scripts into every single article instead of using a "Single Source of Truth" via a Custom Field.

If the "Raw" filter and "Super User" permissions are ignored in com_fields, it creates a workflow bottleneck that doesn't exist in com_content. Is there a specific architectural reason why com_fields cannot respect the same Text Filter rules as com_content?

@1405djarnis Maybe you should research the definition of a bug. A bug is when a software produces error or does not act as intended by the developer. Your issue here is clearly not a bug report, it is a feature request. Using the key word bug in all your issues is wrong and may harm the reputation of Joomla. So please remove that. Thanks in advance.

Can't replicate this. Fields content is preserved after saving.

It works for me same way as in articles or modules.

As super user I set plugin tinyMCE set "Joomla Text Filter" ON

Hi @chmst

As I have already explained, this is not a configuration issue. I have tested this extensively with the Joomla Text Filter set to both On and Off, and the result is the same: the code is still stripped or rendered as plain text.

I have confirmed that your approach works for standard articles: simply removing script from Prohibited Elements is sufficient. In an article, you don't even need to turn the Joomla Text Filter to On or add anything to Extended Valid Elements for the code to be saved correctly. I have nevertheless tried adding both script[*] and script,iframe to Extended Valid Elements as a precaution.

The fact that this exact setup—which works perfectly in articles—fails globally when saving in Custom Fields, proves that this is a bug in the Joomla core (com_fields). The system is ignoring the editor's permissions and cleaning the content before it hits the database. This inconsistency between articles and fields is the core issue that needs to be addressed.

Regards, John

Hi @richard67

I am well aware of the definition of a bug. A bug is precisely when software does not act as intended or shows inconsistent behavior.

In this case, Joomla allows a Super User to save script tags in articles by simply removing them from the Prohibited Elements list. However, when using the exact same editor settings and the exact same user permissions in Custom Fields, the code is stripped.

When a core function like com_fields ignores the global editor permissions and the "No Filtering" setting of a Super User, while com_content respects them, it is the definition of inconsistent behavior—and therefore a bug.

Furthermore, the ability to use scripts in Custom Fields is a highly useful and essential feature for many advanced setups. Since the functionality is already intended to be controlled via editor and filter settings, it should work consistently across the entire CMS.

I am reporting this to improve Joomla and ensure that a very useful feature works as it is supposed to. Consistency in how the core handles editor permissions is vital for any professional CMS.

Regards, John

@1405djarnis I tried myself and also could not replicate the issue, too. When Filter is set to Raw, the script tag is still being saved and I can see the string Test in browser console

So far, 3 of us could not replicate the issue, so there might be something special on your site causing the issue. Please test it again with a fresh installation of Joomla to see if the issue still happens. If not, please close this issue.