All modules?

That´s what you define in Field Groups and Fields where you want to apply it to. Of course it makes bit more sense in core modules, but an advanced developer could extend the functionality of any module with com_fields which would be nice.

This was also a feature of DPFields. I never used it and honestly never figured out a proper use case for fields in modules. But some users did use it extensively. The implementation would be rather quick as the code already exists in DPFields 1.x.

Wouldn't that have a rather big impact on queries count / performance if we have to check custom fields for each module? Something to keep in mind for sure.

How about having Custom Fields only for core modules? Extensions would need to activate support themselves so we can be sure nothing breaks ;)
Possible use cases:

1. Using a custom field also in a module position instead of in an article
2. Extending the field parameters with own fields and use them in your override
3. Provide a set of fields for the website manager to "build" structured content (requires an override). (For example, background image, image, textbox, Link1, Link2 -> Header with Backgroundimage, into image, styled text and two styled buttons

If it affects performance maybe without automated display like in Users - just with the possibility to call in a chrome or override.

You'd have to do fields support on a case by case basis. Even in core, there's little argument (if any) to put fields support in all the modules. What are you going to do with custom fields in a feed module or one of the search modules?

And yes, there will be a performance hit doing it, whether it's in one module only or every module in general, because it will mean more processing during save routines in the backend and during rendering routines on the frontend. It may well be minimal if you're only processing fields on one or two modules in total, but it will be there because it'll mean extra database queries and extra memory consumption.

Only automatic display has an impact on performance on the front end. If it would be enough to work with the fields in an override, then I suggest to add a function in the ModuleHelper class which returns the fields for a particular module. Something like

$fields = ModuleHelper::getFields($module->id);

Like that we have a convenient way to get the fields and no additional query is done for every module.

I think it´s great for overrides and the module Button in WYSIWYG, the automatic display is not really needed.

Can you pleas test #17378 which adds a new feature custom fields for modules.

@laoneo can you please correct PR-Number?

#17490 is the correct one

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/17378

closed as having Pull Request #17490

Thanks!