What are the advantages/differences over this field and the existing list field?

As its a new core plugin it needs to be added to the list in libraries/src/Extension/ExtensionHelper.php

@roland-d Why do not you want to make a separate plugin and add it to JED ?

The field looks quite useful and will probably be in demand

Why do you need to add it to the core ?

@brianteeman The distinct difference between these two is that with list you need to create the list when you create the custom field and is shown as select list to the end user. Displaylist allows the end user to create a list rather than make a selection. I hope that explains it.

@Septdir I don't want to maintain an extension on the JED. The field seems useful enough for the community, so I figured I share it.

As we do have a list already, I would rather see a new function in core to define a default layout for the field and provide different layouts for the same field type. For the list it would mean to add a new file here like /plugins/fields/list/tmpl/list_ul.php and then provide these layouts as option in the field. What do you guys think?

thanks @roland-d makes sense now - which it should have done because the name is perfect - sorry

@laoneo something like
display as select/ul/ol/ etc?

Or like what we have as layouts in modules and views.

@laoneo I thought of adding options to select which layout it would have but for new decided against it because the output is generally styled via a template anyway. So I figured, why add even more options.

@laoneo I thought of adding options to select which layout it would have but for new decided against it because the output is generally styled via a template anyway. So I figured, why add even more options.

@roland-d I think he meant not to add this new field but to add this as a layout to the current select list field

@brianteeman Ok, if that is what he meant than that would be a feature based on the existing list field and serves a different purpose.

Whats the difference of this plugin to the list field? Only the layout or not? The rest is more or less the same.

@laoneo Apparently my two tries so far have failed to make clear what this plugin does different so going to give it another try. It is not the layout, otherwise I would have added that as an option to the list.

Here is an image to show you the difference:

The existing List is a dropdown, the new Display List allows the one consuming the article to enter a list by themselves rather than having to choose from a fixed list. This can be a usergroup that has no access to maintain the custom fields but has access to create articles. To me this is a distinct difference between these two fields.

I think this would be nice, and a feature that a lot of folk would find useful.
I do agree with @laoneo though, there is quite a big overlap with the current list item.

Perhaps an addition to the existing list plugin, with an option of choosing tmpl output. So, perhaps to go with the list.php we could add a ul.php and a li.php, and a way of choosing the display when editing the list, as per template overrides.

@roland-d i get it

Hi @roland-d, sorry, just saw your comment there, yea, think I understand now.

I like it and it’s a great example for other developers to see how to create a repeatable field. +1 here

BTW: is it possible to have a subform + repeatable ?

Now I got it the enlightenment too. Nice one.

I think the path to a repeatable custom field where you can repeat other fields is not anymore far away. More feedback will come tomorrow.

This is not list (form) field, since it does not have selection out of a fixed set of options

It is text field + ability to be multi-value
and then its default layout for display renders it as a list

right ?

to avoid confusion i think this needs a different name that is more descriptive

@coolcat-creations Sorry, but I don't understand the question :)

@ggppdk Yes, you can look at it that way as well.

@brianteeman I am open to suggestions.

I think adding a layout option to com_fields with the ability to create overrides directly in the template (like in modules or components) would be great.

For example, the list field can also be displayed with a list and a string and many more options.

P.S I once did a subform field, did it for myself, so I did not spend much time developing interface and user convenience
It turned out like this
Field param
Field in contact item
Field in frontend

@brianteeman I am open to suggestions

How about calling it
"Create a list"

About name maybe multiple text
Maybe add multiple option for plg_fileds_text

If we want to go the way that you can include other fields and not just hardcode text, then I would name it repeatable to not limit us to something specific.

I have made some changes to this PR.

1. I have updated the title of this PR
2. I have rewritten the test instructions in the first post
3. The plugin has been renamed to Repeatable
4. I added the option that the user can add their own fields in the field configuration
5. I added the option that the user can select their own field type in the field configuration

To start I only have the text and textarea fieldtypes in there. Just wondering what else we should put in the list. Let me know and I will add them.

Please have a look at these changes and let me know what you think. With these changes this plugin has become a lot more flexible.

@roland-d You can add fields from plugins/fields/repeatable/params/fields.xml to plugins/fields/ repeatable/params/repeatable.xml

<?xml version="1.0" encoding="utf-8"?>
<form>
	<fields name="fieldparams">
		<fieldset name="fieldparams">
			<field
					name="fields"
					type="subform"
					label="PLG_FIELDS_REPEATABLE_PARAMS_FIELDS_LABEL"
					description="PLG_FIELDS_REPEATABLE_PARAMS_FIELDS_DESC"
					multiple="true">
				<form>
					<fields>
						<fieldset>
							<field
									name="fieldname"
									type="text"
									label="PLG_FIELDS_REPEATABLE_PARAMS_FIELDNAME_NAME_LABEL"
									description="PLG_FIELDS_REPEATABLE_PARAMS_FIELDNAME_NAME_DESC"
									icon="list"
									multiple="true"
							/>
							<field
									name="fieldtype"
									type="list"
									label="PLG_FIELDS_REPEATABLE_PARAMS_FIELDNAME_TYPE_LABEL"
									description="PLG_FIELDS__REPEATABLE_PARAMS_FIELDNAME_TYPE_DESC"
									icon="list"
									multiple="false"
							>
								<option value="text">PLG_FIELDS_REPEATABLE_PARAMS_FIELDNAME_TYPE_TEXT</option>
								<option value="textarea">PLG_FIELDS_REPEATABLE_PARAMS_FIELDNAME_TYPE_TEXTAREA</option>
							</field>
						</fieldset>
					</fields>
				</form>
			</field>
		</fieldset>
	</fields>
</form>

About the fields

• media
• number
• Maybe editor

If you can make a list field with the ability to conveniently add options (subform in subform). This plugin can be renamed to subform

It's also worth adding a choice of layout because joomla.form.field.subform.repeatable-table will not be convenient if many fields

Add multiple param because you do not always need a repeat In fact, you can simply add all the parameters from the subform documentation

And stay the last opportunity to conveniently select the layout of the output value. With overrides, easy adding, etc.

I would add the layout option to all fields and not only this one. So this should be done in a separate pr.

@laoneo I also like this idea. But it is not necessary to make a separate pr.

Need a field for example and testing. And this field will do just fine

@Septdir it is better to have one use case per pr.

@laoneo I agree. But then it is better to first do pr with layouts and then modify this pr.

@Septdir I see no problem in which order the pr's are done as this functions are not connected to each other. If somebody can do the layout pr first even better. But I would not hold back this one in the meantime.

I have tested this item ✅ successfully on f3e4c64

Tested in Joomla 3.9-dev

@Septdir Thanks for the info on merging the 2 XMLs. I have added the media and number field. Not the media because you would need config options for that one like showing the buttons or not.

Agree with @laoneo that the option for layouts is out-of-scope for this PR.

Updated PR with all feedback.

@Quy Any idea why the indents in the XML are different after I commit them? It looks like this in my editor:

On Github it is shown as this:

It's the way GitHub renders tab characters (in the IDE it's usually a representation of however many spaces you define a tab to be, GitHub's tabs IIRC are 8 characters in length).

Hi @roland-d
This Repeatable field is a very important one as it is a common need to many websites.
I see that there was some confusion in the first comments above about the usecase (difference with simple List field).

A good example of Repeatable field would be a website about Movies.
You would have a Category called Directors (Steven Spielberg, Quentin Tarantino, ...).
And your Repeatable Field would be called "Filmography" (for Spielberg : E.T., Ready Player One, ...).
One could not use a List Field as the idea is not to select amongst a predetermined list of movies, but to let the user add freely any movie when editing/creating an article.

In this example, the Repeable field could "contain" 3 fields :

• Name of movie (Text)
• Synopsis (TextArea... or even better : Editor bc most of the time the end-user needs to format the text and you cannot ask them to do in pure html)
• Year (Integer... or even better : List bc then you can ensure that the format is uniform, not "2015", "15" or "'15" or "last year" and you can also you can set a min/max

So coming back to the question of the types of fields to support, I would strongly suggest to also add also

• Editor
• ... and actually there is also a usecase for List, Checkbox, Calendar, Media etc. But -as you mentionned- for those you would need to add their own specific options.

So let me throw an idea and try to do some brainstorming : the goal should always be to try to keep the things as simple as they can be and/or to be generic, right ? So instead of integrating loads and loads of Options here, wouldn't it make sense to simply be able to choose amongst the already created Fields.

With other words, taking the example of the Movies website :

1. one creates a real Text field for the Title of the Movie
2. one creates a real Editor field for the the Synopsis
3. one creates a real Calendar field for the date of issue
4. one creates a real Media field for the Image of the film
5. one creates a Checkbox field for something like "PG13"
6. and why not : one creates a non-native field (like Related Article, Map, whathever)
7. ...
8. and finally, once all the necessary fields are created, the present Repeatable Field would allow to select all the above-mentioned fields

Then, when the end-user creates/edits a Director's article, she/he can enter the full detailed filmography of that Director. Sometimes there are only 2 films, sometimes 10+.

The Repeatable field is the only way to do this.
That would be totally generic (you could use any created Field, each having all its options available).

(now I am not sure of what this entails for your code, maybe it has other consequences etc. But I am just brainstorming :) )

@woluweb Thank you for your input. I can see the use of using existing fields and I think that would be a pretty cool option but better to have that in a second iteration.

I did add the Editor field.

Hi @roland-d
Txs a lot for the Editor field !
Indeed, if what I explained is not "incompatible" with what you've started here can be done in a second iteration that's fine :)

I have tested this item ✅ successfully on cf97021

Thats an amazing feature and very needed!
Tested successfully - however there is an option needed how the field output looks like. For example the media field shows the path of the image instead of the image. We need to think about how to apply layouts / overrides better to the fields (independant of this PR for fields in general).

I think it is now in a ready to merge condition. There will be always things to improve which we can do in upcoming pr's.

I think it is now in a ready to merge condition. There will be always things to improve which we can do in upcoming pr's.

yes, thats why i said it's independant of this PR :)

Please open an issue for that request, otherwise we will forget.

I've read it through it all and I can't bring myself to be convinced of the current application. What I'm thinking at this point is... With this repeatable field, we are filling the field values in each self contained article, and they are completely isolated and cannot be re-used or re-purposed in any way.

It's pretty much a "fancy" Text Editor with pre-defined things to fill in. I get it, it makes it easier for end users. Instead of making them using a Text Editor, they use pre-defined things they can compile. But they could have done a Table in a Text Editor and accomplish the same thing. Or a simple bullet point List and accomplish the same thing.

So let me throw an idea and try to do some brainstorming : the goal should always be to try to keep the things as simple as they can be and/or to be generic, right ? So instead of integrating loads and loads of Options here, wouldn't it make sense to simply be able to choose amongst the already created Fields.
With other words, taking the example of the Movies website:
one creates a real Text field for the Title of the Movie
one creates a real Editor field for the the Synopsis
one creates a real Calendar field for the date of issue
one creates a real Media field for the Image of the film
one creates a Checkbox field for something like "PG13"
and why not : one creates a non-native field (like Related Article, Map, whathever)
...
and finally, once all the necessary fields are created, the present Repeatable Field would allow to select all the above-mentioned fields
Then, when the end-user creates/edits a Director's article, she/he can enter the full detailed filmography of that Director. Sometimes there are only 2 films, sometimes 10+.

@woluweb This would bring it forward a bit, but I'm still thinking the same as what I mentioned above.

Think about it: at this point, with your example you are essentially allowing users to go in a Director article, and fill in fields about the Movies.

At this point, wouldn't it make more sense to first create the Movies Articles, with those fields that you listed above (Title, Synopsys, date, image, PG13, etc.), and THEN, go to the Directors Articles and
simply... Select from the List of Movies Articles. Ala this Plugin: https://www.regularlabs.com/extensions/articlesfield/tutorial

And the output on the frontend can be smart... in the Director Article it can automatically display ALL the fields of each Movie (Movie Article) he directed, in a table for example (with each movie being in its own row). This would make everything connected, re-usable and useful.

This would be an expansion of the Articles Field created by @regularlabs. Which I initially proposed as part of the core back then (#17876) but nobody took it upon to write it, so @regularlabs made it its own Plugin, and we expanded it tremendously from the original idea, I suggest to see everything that it can do now in the link of the Plugin that I put above.

I feel like THAT makes sense, and what this "repeatable" idea could be, it could be turned into simply a new Layout for Articles Field, where instead of displaying just the Title of the Related Article, you display ALL fields of the Related Article (or maybe not necessarily ALL of them, you get to pick which ones...).

Maybe we can get @regularlabs involved in this and made all of this part of the core.

After all, I feel like it's such an essential feature, Custom Fields in the core right now are very much self-contained, they can't be linked to anything and they can't be connected to anything, and this "repeatable" field, while a good idea in principle, I don't know, with the current implementation of this field I feel like we would be just adding even more "self-contained" stuff that can't be used in a really useful way.

Your idea of an articles field has nothing to do with this one here. As @regularlabs showcased perfectly is that if you need another type of field you can do it easily without the need to have it in core.

Your idea of an articles field has nothing to do with this one here. As @regularlabs showcased perfectly is that if you need another type of field you can do it easily without the need to have it in core.

I know it doesn't necessarily have anything to do with this one, just trying to point out what could be a more useful implementation of accomplishing the same thing this PR accomplishes.

Hi @AndySDH,
I am also a big fan of @regularlabs Articles Field (maybe even the biggest user of it, ask him ;) )

But Repeatable Fields and Related Articles Fields are two different things.
Actually, my suggestion of having a Repeatable Field allowing eventually (ie in another PR) to choose freely amongst any created Custom Field... means that you even have Related Article Field within Repeable Field.
Example :
Year [integer] : 2017 | Movies [Related Article] : film1, film2, film3, film4
Year [integer] : 2016 | Movies [Related Article] : filmX, filmY

So there is no contradiction here :
Repeatable Field are great (you don't always need to relate to other articles. And in many use cases you don't know in advance how many occurences you need : 1, 2 or 10).
Related Articles Fields are great as well.
But they are different things... and they could even be combined as shown in the example above.

So let's have this PR so that we can already enjoy it.
And with time we can improve upon it, generalizing it for example.

@woluweb

For sure, they can definitely both co-exist, just what I thought would have been a more comprehensive implementation, done in a different way but accomplishing the same exact goal this is trying to accomplish.

Year [integer] : 2017 | Movies [Related Article] : film1, film2, film3, film4
Year [integer] : 2016 | Movies [Related Article] : filmX, filmY

But "Year" would already be a Custom Field of the Movie Article. You wouldn't need a "Year" repeatable field here because there would already be a "Year" associated to the Movie, so you can simply output that in the frontend.

Movies Articles have fields: Year, Title, Description.

Director article, by choosing the related Movies Articles, shows:

Movies:
YEAR | TITLE | DESCRIPTION
2017 | film1 | What a Great Movie
2017 | film2 | Bad Movie
2016 | film3 | Average Movie

Again, they can definitely both co-exist, but I'm just not a big fan of typing information in self-contained fields that they are essentially the same thing as what a user can do with a Text Editor...

@AndySDH THEN, go to the Directors Articles and simply... Select from the List of Movies Articles There you are at the reason why I started this whole plugin. You do not know beforehand which values are going to be filled in. So you cannot have a select list with predefined values.

And the output on the frontend can be smart.. Every output can be made smart using template overrides. As @coolcat-creations mentioned earlier, the core can do with better outputs.

I'm just not a big fan of typing information in self-contained fields that they are essentially the same thing as what a user can do with a Text Editor... Here I disagree it is just a plain text field because the data is actually ordered. If I type a list of 25 items in a text field I cannot display them so easily as a list in one place and a table in another. It would force me to dissect the HTML it is in. With this field you have an array with data that you can display as you like.

Ok - I kinda get it.

What I have been thinking is that, using your example, you could have accomplished the same thing with my example, by creating a "Sizes" category, where you have 3 articles, called "Small", "Medium", and "Large". (simulating "Categories" as "Content Types", which by the way, off topic, totally agree with @brianteeman regarding #20233, we can pretty much already do this)
Then, you have a custom field for the "Sizes" category, called "Description". And each of those 3 articles have their own "Description".
Then, in the Marbles article, you could have simply assigned a Related Article Custom Field called "Sizes", where you select all three articles: Small, Medium and Large.
And make the output of the Related Article Custom Field to display the Description (Custom Field in the "Sizes") along with the Size.

This would accomplish the same thing as your example.

But I'm guessing, the only thing that is different, is that you might want to have different Descriptions for the same Size in different Articles?
For example, the "Small" size of article "Marbles" might have a different Description than the "Small" size of article "Granite"? Is this what you're trying to accomplish? If it's this, then ok, I get it now. But then again, in your example you're calling your custom field "Marbles", so I'm not sure this is what you meant...

Possible name idea for the field instead of "repeatable": How about "subfields"? Or "multi-field"?

Repeatable is the correct descriptive name. Subfields implies there is a parent which there isnt.

@AndySDH

But I'm guessing, the only thing that is different, is that you might want to have different Descriptions for the same Size in different Articles?

What I am actually using it for is documentation. I need to create a list of available fields. For each import and export article this list is different. So you have your Product Import and your Order Export, both these articles use completely different fields. This is not just 1 textfield or textarea or editor I need to enter but sometimes up to a 100. This field allows me to do that in a structured way. This gives me control over how I display them. That was the original setup of this PR, but now it has changed to be even more flexible and allowing me to enter more information for each available field.

@Septdir @coolcat-creations @alikon Can you guys please test this PR one more time so we can get it RTC and merged? Thanks heaps.

I have tested this item 🔴 unsuccessfully on ef12c0d

Works as described from backend. (Very useful field!)
In frontend submission of an article the fields can be added by for example a publisher, tested using various sizes of bowling balls. Saves fine - but fields just entered are not saved. Empty when viewing article and viewing in backend

@ot2sen Thank you for testing this. Your front-end issue I cannot reproduce. This strikes me as weird as well because the plugin doesn't do the actual saving, it only sets the values and this happens in exactly the same way as it is done in the back-end.

Can you provide step-by-step instructions on how to reproduce the issue you see?

@roland-d was testing towards staging of today, the 3.9-dev (3.8.8), would that make a difference. Noticed you targetted 3.10-dev

@ot2sen I really doubt it would make a difference because I first based it on 3.9 but then 3.9 become 3.10 and we have a new 3.9. Regardless, the saving of custom fields is a general task nothing special for this plugin. Do other custom fields work for you?

@roland-d did a few more tests. It is a matter of type of user I see. Reg/Publisher it won´t get saved. Worked fine in frontend using admin

@ot2sen Yes, that is it. However I think this is not a bug with my PR but you need to give these groups permission on the Custom Field as shown here in the screenshot:

By default the Publisher group for example has no right to Edit the custom field value.

shoulnd't you need to add administrator/components/com_admin/sql/updates/ files ?

@alikon why would that be needed? This is a custom field not a component adding new database fields.

on install you add'plg_fields_repeatable'in the #__extensions table, on update you should do the same

@roland-d yes, changing the last permission to edit will let it save.
But the problem is more that you have no indicator in front that you cannot edit if this permission isn´t set. You can enter new values and save your work and no indication that you weren't allowed to do so.

If you add a text field for an article for a publisher. This will be viewable on the fields tab - but you cannot enter anything in the field in front and a not allowed icon will appear on hover. For repeatable field you can enter and add, thinking all is good when permission is not set to edit.

@alikon Thanks understood and PR updated
@ot2sen I see your point now and I have looked into this. What I have done is made the fields readonly if you are not allowed to edit them. Will this work for you?

I have tested this item ✅ successfully on d09ba7c

With the read-only addition, it works as expected now. Nice.

@roland-d yes, the read-only extra removed confusion. Works well.
And even if you can hide the read-only fields in options settings it is good that it now also appear as read-only when it is.

I have tested this item ✅ successfully on 675d0a7

Works as expected!

I have tested this item ✅ successfully on f6542e0

Works as expected. Nice feature!
And unlike Yves, I really liked your clear testing instructions Roland....

I have tested this item ✅ successfully on e13a749

Still works

Why is only one Test count as successful?

Because joomlara tested the commit (f6542e0) before the last commit (e13a749).

With the number of tests this PR has gotten and the last commit being trivial one could say it has had enough tests ;)

RTC

Merged to 3.9 via 327fa65

For the people who are requesting a layout chooser per field, It got merged today by #18571.

Hi there! Is there a way to fix the appereance of the Media field? Is it related to the repeatable field or a separate issue?

Hello, this is a separate issue. The styling just doesn't fit.

Sorry for the late testing... But if you use 2 editor fields with JCE you can't type in into the second editor field. I know it's not core related (With TinyMCE everything works fine) but maybe something that can be still fixed?

Created the issue and will post the JCE one also towards JCE ;)

I'm going to lock this one. If there are followup issues, please open a new issue or pull request. Thanks for understanding.