I have tested this item ✅ successfully on b65c37c

Tested Successful with following code in the override:

/* working example 1*/
$fields = \Joomla\CMS\Helper\ModuleHelper::getFields($module->id);
foreach ($fields as $field) {
echo $field->value;
}

/* working example 2 */

$fields = \Joomla\CMS\Helper\ModuleHelper::getFields($module->id);
foreach ($fields as $customField){
$customFields[$customField->name] = $customField;
}
echo $customFields['module-css-id']->value;

/* working example 3*/

$fields = \Joomla\CMS\Helper\ModuleHelper::getFields($module->id);
foreach ($fields as $customField){
$customFields[$customField->id] = $customField;
}
echo $customFields[40]->value;

THANK YOU !!!

Can this get the new feature label?

@mbabker beat me to it

Tentatively, I am OK with putting this in 3.8 as long as it is fully tested/reviewed/updated based on review and merged by the time beta 3 is tagged.

With that said though, I'm going to ask the tough question now. What is the benefit to custom fields in modules? They are by design a query for information, they aren't really something intended to be built on top of in the way I can think of "conventionally" using fields to extend components. So while I get this is a relatively low maintenance thing for core and adds a new layer of options for modules, is there any true practical benefit given the nature of what a module is versus a component?

To be honest it´s useful for every module override I can think of.

I can extend the functionality of mod_newsflash for example. I just build today an override showing articles in mod_newsflash in an owl carousel. If I want to use more of these overrides and decide on each module how many columns, if there is a navbar or not,... and so on.

Now I would need to write an override for each layout and to make it user friendly i would need to write a plugin.

Just like it was before com_content got the possibility to have custom_fields. But now we could have the possibility to use custom fields also in modules.

Another use cases:

1. User friendly input of introtext and linkbutton in a header module. The customer only selects the backgroundimage (already in mod_custom) writes some text in the editor and selects an article from the custom field "Article" -> With the help of the override the header is displayed perfectly without having the customer to add any "button" markup.

2. Having a customized module-id: For one-pagers you need to add ids to your modules to scroll to this anchor. Currently i solved it by adding "moduleposition-moduleid" into the chrome. But scrolling to services.html#bottom-123 is not that sexy like defining own ids - with the help of a custom field.
   Actually every new Parameter which is requested by an user could be declined with saying: build your own custom field for that need.

3. Grid parameters: You could setup Grid Parameters in your custom fields and use them in the override to include the specific classes. Yes - of course you can add module suffix right now. But with custom-fields you can create Userfriendly UI, without the need for them to know CSS markup.

... I´m happy to share more examples, but i hope these ones are enough :)

I am not commenting here on the usefulness of this PR or if it works (it does)

My concern is that we have a feature enabled in the admin that will not work unless the user overrides their modules. This is not intuitive as there is no other feature in the core of joomla that will not work without users getting into writing code

As I said in internal diskussions I am against adding this feature. I don't think it is needed, if I have to code then I can also add params to the module xml. It is also putting more functionality into modules, I think modules should display data and not more. This change would bring modules closer to components so the difference between both types will be even more unclear. It opens a chance to hack the system and I see the danger that this will make support more complicated. Bottom line for me is that the negative effects are bigger than the positive effects.

I agree to @brianteeman - having it disabled by default would maybe help, so that only the more experienced user could take advantage or is there a way to have an "extension" that enables exactly this option like the PR?
@rdeutz - My suggestions above only show data too, and have nothing to do with components. It´s easier to extend with fields than to write several plugins and modules that solve the above-listed examples.

Hi there, I have a suggestion for solving that issue. Can we implement custom fields in modules but name it custom params and enable it not by default? Just an idea.

And if we provide a "legancy core params set" we could reduce the params in J4 to a minimum by removing all the stuff for "not migrated" sites. Is it clear what i mean?

Custom fields in modules is something I urgently need. How can I test this PR?

@B3nito

• Testing Instructions at #17490 (comment)
• if you mean how to test a PR: https://brian.teeman.net/joomla/873-a-dummies-guide-to-joomla-bug-testing

Oops, how could I miss that? Although I seem to be too late to the party, here are my personal thoughts on "Custom Fields in Modules":

I would expect and use custom fields in Custom-HTML modules. A Custom-HTML module might serve as some "special content" and with frontend-edit it might be a customizable area for a client/manager. Drawback in the past: Only one big HTML area without structure and guidance for a user. Edit all or nothing. PR Benefits: Custom fields would allow a structured and easy input. Also different content parts could have different ACL/permissions. Detailed control who can edit what.

However, I always try to avoid using Custom-HTML modules for content, because it is not part of the regular article management. The flexible assignment and display is a nice option though. Which leads me to my second and final thought:

If Joomla would have a core article module, which displays a (selectable) single article including custom fields, we wouldn't need this PR. With an article module, we could achieve the same results AND we could stay in com_content.

Don't get me wrong, I really appreciate all your thoughts and hard work, but I don't believe that the current solution is frequently used by many site-builders. As mentioned in the comments, advanced users might use XML files and their custom module. Custom fields in 3rd-party modules don't make too much sense to me, because usually the module content is pulled from a component... which should be extended by custom fields itself.

Anyway, I am looking forward to the outcome! Hope to test it ASAP.
Regards!

Why is that closed ? :-(