Bug/Issue: Custom Fields stripping script tags in Joomla 6.0.2 despite "No Filtering" and "Raw" settings

[1405djarnis]

Steps to reproduce the issue
Environment Setup: Ensure "Global Configuration" -> "Text Filters" is set to "No Filtering" for the Super User group.

Field Creation: Create a new Custom Field (com_fields) of type "Editor" or "Text Area".

Field Settings: * Set Filter to "Raw".

Under Permissions, set "Edit Custom Field Value" to "Allowed" for Super Users.

Set Automatic Display to "Do not automatically display".

Editor Setup: Set the user profile to "Editor - None" (to rule out any JS editor cleaning).

Data Entry: Open an article and enter a script in the custom field, e.g.: <script>console.log('Test');</script>.

Save: Click "Save" or "Save & Close".

Expected result
The <script> tags and the JavaScript code should be saved exactly as entered, because the filter is set to "Raw" and the user has "No Filtering" permissions.

Actual result
The <script> tags are stripped/removed upon saving. In some cases, the entire content of the field is wiped clean. The same script saves perfectly when pasted directly into the article body (com_content), but fails in the custom field (com_fields).

System information (as much as possible)
Joomla Version: 6.0.2

PHP Version: 8.4.16

MySQLi Version:* 10.6.23-MariaDB-ubu2204

Caching: Enabled

Gzip: Enabled

Editors Tested: JCE (with script allowed), TinyMCE (with script allowed), and Editor - None.

Additional comments
This issue makes global code management impossible. Since the global field won't store the script tags, I am forced to manually insert the script in every single article. This defeats the purpose of using Custom Fields for reusable code snippets and makes site maintenance extremely inefficient. It appears com_fields ignores the "No Filtering" and "Raw" settings that work correctly in com_content.

Regards,
John

[brianteeman]

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.

[1405djarnis]

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?

[richard67]

@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.

[OctavianC]

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

[chmst]

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

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

[1405djarnis]

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

[1405djarnis]

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