To be fair, all Field Types should be added to the list for Repeatable Field (#20243). There is a case use for all of them. So other than Calendar, also List, Radio, Checkboxes, Colour, User, etc, all of them should be available.

And yes, all Fields should also come with with their respective options that they each have. So the maximum length, the filter for text, the editor options for editor, etc.

It should essentially be a SubFields creations inside one Field.

Also, as @woluweb suggested previously, it would be cool to be able to select from already existing fields instead of "creating" one.

Another issue, a Media field should output the img tag like a normal Media Field does, not the image path, not sure why it outputs the image path in the repeatable field.

@roland-d

@AndySDH Yeah, all(!) what you are describing is exactly what we have in #22446 . Lets keep the discussion there, so I think this issue can be closed (as we have a PR?)

@contiga Sure! Just as long as we make sure to keep it under one field. So let's revamp upon the repeatable field, no need for a separate one :)

I agree 😄

What we really need is not only support for more fields but that you can choose an already existing custom field.

You know, @continga, supporting existing custom fields would make it even MUCH MORE EASIER. So you don't have to replicate all the settings for each field inside the field creation, you just use the ones from existing fields.

This is going to be fun to document after 4.0.

The repeatable form field was removed. Not the repeatable custom field,
that’s actually subform. But it’s not called subform because “reasons”.

On Fri, Oct 19, 2018 at 8:06 AM AndySDH notifications@github.com wrote:

@contiga Sure! Just as long as we make sure to keep it under one field. So
let's revamp upon the repeatable field, no need for a separate one :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#22415 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWfoa12JH66VHijlqCDKE0ffCKJymxzks5umc5LgaJpZM4W9fPH
.

--

• Michael Please pardon any errors, this message was sent from my iPhone.

@mbabker Right! We'll probably ending up renaming this while we are at it.

#22446 is actually supporting custom field types. There is no limitation on the nested field types (besides they shouldn't be subforms themselfes, see https://github.com/joomla/joomla-cms/pull/22446/files#diff-cb0a6f090d20a596a5a809a8d1653294R39 ). What the plugin basically is doing is loading all available field types into the selection. I think I need to write documentation for it, as describing its functionality in GitHub issues seems a bit odd. How would I do that? Just create a new wiki page in the docs and make clear it is for my PR?

Maybe I misunderstood the "already existing custom field" sentence. We really need to work on the word choices... Confusing. I thought you were talking about custom field types (as per, plugins installed from the JED e.g.), not about already existing custom fields

Maybe I misunderstood the "already existing custom field" sentence. We really need to work on the word choices... Confusing. I thought you were talking about custom field types (as per, plugins installed from the JED e.g.), not about already existing custom fields

Right yes. The idea is use already existing Custom Fields.

• So first create an actual separate custom field with whatever field type, settings and display options.
• Then create a subform/subfield and load that into it.

Would make it more easy and also can save some time. Say you need to re-use a custom field in multiple subforms. You create it only once and then you can load it into different subforms/subfields.
What do you think?

Let's move discussion over at #22446

closed as Discussion is on #22446. Please reopen if i'm wrong.

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