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.

Hi @joomdonation and the team,

Thank you for testing. While you might not be able to replicate the script stripping in your specific environments, there is a much deeper architectural issue with com_fields that I have documented in the attached screenshots (Image 3 and 4).

The core of the problem is that Default Values in Custom Fields are not dynamic.

Steps to see the failure in logic:

Create a Custom Field (e.g., "Price" or a "Script holder") and set a Default Value globally.

Assign this field to 100 articles.

Now, try to update that value globally in the Field settings (under Content -> Fields).

Result: The changes do not propagate to the articles. The articles keep the old value.

Why this is a "Bug" in user experience: If the purpose of a Global Field is to manage data centrally, it fails completely. As a user, I am forced to manually open and re-save every single article to update a value that is supposed to be controlled globally.

In com_content, if I change a global setting, it reflects everywhere. In com_fields, the "Default Value" is only a "one-time template" at the moment of creation. This makes it impossible to use Custom Fields for "Single Source of Truth" data like prices, FAQ schemas, or tracking scripts.

If Joomla 6.0.2 aims to be a professional CMS, com_fields must respect the "No Filtering" settings of a Super User consistently AND provide a way to push global value updates. Otherwise, the "Global" part of Global Fields is misleading and creates a massive maintenance bottleneck.

Please look at the screenshots where I show that even a simple price change in the global field doesn't update the article field.

Regards, John

@1405djarnis You just have closed this issue as completed, but your previous comment reads as if you still see an issue in it. Was closing maybe an accident?

Hi @1405djarnis

About "No Filtering" issue, I guess you are talking about No option in Filter setting of the custom field. Personal, I think it is confusing indeed. When you set it to No, Joomla still make default filtering to the data and it cause the issue. In your case, set Filter to Raw and it will work as expected

As Default Value for the custom field, that's how it works and nothing is wrong here. The default value will only be used if there is no value for that custom field saved for the item before. Once it is saved, the saved value will become the value of the custom field, not depends on default value of the field anymore. So if you change Default Value for the field later, you cannot expect that default value is updated for existing items. It is not working as you want does not mean it is bug.

Hi @richard67 and @joomdonation,

Thank you for the explanation, but I have to challenge the logic that this is "not a bug" simply because it’s "how it works."

The argument that Joomla is "protecting data" by not propagating global changes is inconsistent with how a professional CMS should function, especially considering Joomla's own architecture:

ACL & User Rights: You mentioned data protection, but Joomla already has a sophisticated ACL. If an administrator restricts a field, they have already decided who has control. The system should trust the administrator’s intent when they update a global value.

The Maintenance Failure: If I have 100+ articles and need to update a single value (like a service price or a tracking script), the current "static" logic forces me to manually open and save every single article. This is a massive maintenance bottleneck, not a feature.

Global vs. Local Intent: In almost every other part of Joomla, global settings are inherited until overridden. Custom Fields should offer an "Inherit from Global" or a "Push to Articles" option. By forcing the value to be "locked" in the article database the moment it's saved, you've turned a "Global Field" into nothing more than a one-time template.

If this is truly "by design," then the placement of these fields under the "Content" menu as "Global" is misleading to the user. It creates an expectation of central management that the core does not deliver.

Are there any plans to make Custom Fields more dynamic in future versions (like a "Push to articles" button), or is Joomla committed to this static approach?

Regards, John

No there are no plans

Hi @brianteeman, @richard67 and @joomdonation,

Thank you for the final clarification.

It is honest, though I must admit it's disappointing. I truly believe this could have been a "super feature" for Joomla 6 to bridge the gap between static content and dynamic data management. It feels a bit like a lot of great work has been put into the Custom Fields architecture without quite taking it across the finish line for professional maintenance workflows.

However, I accept your decision and the current vision for the core. Thank you all for your time and for the work you do for the community.

If anyone is in the same situation and wants to try this out, you are more than welcome to test it. Please note, however, that this might not be the final solution to the issues with the static fields. I have also attached a plugin that might help resolve the problem.

Best [regards,]
John

plg_content_dynamicfields.zip