Version and hits has been already removed can't remember the pr number

Version and hits has been already removed can't remember the pr number

For reference #12674
Thanks for the reminder.

Concerning Title and Label, I think we should keep them as LABEL can be translatable via a new language string and, in this case, it has to obey to our usual rules for string constants.
This may not be really readable vs Title.

Images can be used in a template override, but this is not implemented yet, just one more possibility for the site admin when he is doing an override.

Images can be used in a template override, but this is not implemented yet, just one more possibility for the site admin when he is doing an override.

Yes sure, in overrides everything is possible. But I don't see the usecase for it to store data which eventually could be used in an override. If we have the options, it should be used in core or removed. Otherwise users will be confused and telling us core is broken.

Found out the alias is used as the field id in the HTML code. So maybe it should be named differently?

Many users of DPFields did use the alias also for a more human readable lookup.

Found out the alias is used as the field id in the HTML code. So maybe it should be named differently?

Many users of DPFields did use the alias also for a more human readable lookup.

I have a similar thing to 'alias' called 'name' of the field,

• that appears in html code, and elsewhere, (e.g. when in a field selector, 2 fields have the same title, i will append the fleld's name to distiguish them)

I would suggest we have an advanced config option in com_fields which is used if doing template overrides which shows the additional input values that the user can then use in the front end in an override. Displaying inputs which have no effect in the default output would lead to a very confused user.

There is (currently) no configuration at all for com_fields.
Imho it makes no sense to have additional database columns which may only be used (or not) by templates overrides.
Most of the mentioned fields even don't make sense in an override. For example "hits", "created_by_alias", "publish_up" and "publish_down". They would need code to deal with it.
The image may be used in an override, but really what is the usecase? Why would you want to attach an image to a field? If you need a template override anyway to show it, you could as well just add some code there hardcoded to show that image you want. Or even better use CSS and show the image based on a class on the field.

I think it's also for the fact the DPFields will have to provide a migration for it's current users.

We should probably look at adding ACL for com_fields, what ACL is controlling who can add fields?

ACL should be working with PR #13019.

As for the users of DPFields, I have no clue. Does that one use the same component name (com_fields)? If so then it's an issue, otherwise not. I'd rather rename com_fields component then to something else to avoid that issue. DPFields can add a migration path to its extension, not a core issue to deal with.

DPfields is "com_dpfields"

Closing as there is a PR for the remaining issues.
#13621