Your example of the mp3 seems wrong to me and would be trying to mix a plugin with a field. The correct way to do this would be to create an mp3 custom field which would be a very simple thing to do

corrected Typo in Title; also Title to make clear Issue is about com_fields .

( I assumed CF meant Custom Fields)

allow plugin execution

IMO bad idea. This would require one event per field minimum, this will be a major performance hit on complex pages with numerous fields (go back to the 3.7 betas where there was one query per field at some point). To me, field data is not designed to be mutated by plugins during display events, rather the field plugin (or how the site owner manipulates their layout overrides) dictates display. Using the MP3 example, this really should be a dedicated MP3 plugin (especially because the field would presumably also handle other features such as file uploads for locally stored media, or if you're using some kind of podcast analytics measuring platform you may have configuration in the field plugin for this which means the plugin needs to manipulate the linked URL (in some cases) to add that analytic data. To me it would actually be a worse user experience if I were to set up a text field and add plugin tags as a prefix/suffix to make another plugin render the frontend correctly.

prefix/suffix field

This is field dependent, and then at this point we get into a debate of how much markup should be maintained in the field UI and how much should be integrated into other places (the field plugin's layouts, or the component layouts, etc.). I don't think you can universally add these options and just make things work.

allow JTEXT

Where? If I'm not mistaken some things already do use that API where it makes sense. Clearly this shouldn't be applied to the actual user input data (my company site we use fields for a testimonials section, I wouldn't want the customer comments to be pushed through JText).

Ok .... I understand your reply
Some cck have this option and its realy realy used by user they love it
For me it not à good idea to create 1 field for 1 usage... Custom field Can be more flexible with this approche less coding for integrator and more simple for editor content
For performance simple option to allow or not plugin exécution peer field ...
An other exemple an adresse field
Juste install googlemap plugin
Create à text field
Add plugin syntax un préfix ans suffixe
Now user Can type address
Map is display on front
Why did we need to wait a user coding a specific custom field ?
Its not good for Joomla cf...
That only m'y opinion lol

1. Content plugin triggering

IMO bad idea. This would require one event per field minimum, this will be a major performance hit on complex pages with numerous fields

agreed but it is happening already (partially), the

• editor field
• textarea field

trigger all contents plugins without option to turn it off,

so an improvement would do add the content trigger plugin option only to editor and the textarea fields, for the reverse purpose of being able to turn unneeded content plugin triggering OFF and gain performance

then about other fields, of course someone could argue that you do not need the option to trigger plugins to other fields at all (even with an OFF default setting), because you can just make a custom field layout

2. About prefix / suffix params

This is field dependent, and then at this point we get into a debate of how much markup should be maintained in the field UI and how much should be integrated into other places (the field plugin's layouts, or the component layouts, etc.). I

Exactly the field plugin's layouts, offer a lot more power, than prefix / suffix options

• but layouts are for power users / programmers only
• and prefix / suffix would win the debate of being worthwhile markup via configuration because they would be commonly use to add
• basic styling
• or something that now we are forced to add to the ... label
  e.g. $ (dollar, euro) , Sqr. Meters etc

3. About JTexting the values

I wouldn't want the customer comments to be pushed through JText).

Of course that is why it would be optional and by default it would be OFF

I believe that sooner or later the above will be done, if not now, then after a few months or after a year or more, there will be demand and PRs asking for these

An other exemple an adresse field
Juste install googlemap plugin
Create à text field
Add plugin syntax un préfix ans suffixe
Now user Can type address
Map is display on front

If you're loading a map, you require loading additional resources on the frontend. So you can either write it all into one field plugin, or you can write a content plugin and to put in that address and get the desired display you now require two plugins minimum to get it all right. Or you can write your field plugin to dispatch the other plugin events. Either way I don't believe that this is a spot where data should be manipulated by general purpose content plugins.

I wouldn't want the customer comments to be pushed through JText).

Of course that is why it would be optional and by default it would be OFF

User values shouldn't be translated. There are places where it makes sense to do so (i.e. a field's label), but those cases are few and far between. Of course, nothing stops you from creating a field that lets you have translated values if you really want them. Do we put contact address data through JText? Or content metadata? No, there's a reason.

no problem i close this request
i am agree with your return
have a good day and thanks for your work on joomla !