Language Change New Feature PR-3.10-dev RTC

Pending

User tests: Successful: Unsuccessful:

avatar roland-d
roland-d
26 Apr 2018

Summary of Changes

This pull request adds a new custom field to the core of Joomla. This custom field is called Repeatable because it allows users to enter a repeatable list of items which in turn are by default shown as a list. With a template override you can do a whole lot of other things with this.

Testing Instructions

Installation

  1. Copy all the files to their respective location in your site
  2. Go to Extensions -> Manage -> Discover
  3. In the list find Fields - Repeatable
    image
  4. Select this plugin
  5. Click on Install
  6. Go to Extensions -> Plugins
  7. Filter the list on repeat
  8. Select this plugin
    image
  9. Click Enable

Usage

  1. Go to Content -> Fields
  2. Click New
  3. Give the Custom Field a Title of Marbles
  4. As Type select Repeatable (repeatable)
  5. At the bottom click on the green + to add a new field
    image
  6. Enter the name of the field Size
  7. Select a type of field Text
  8. Click again on the green +
  9. Enter the name of the field Description
  10. Select a type of field Text Area
  11. Save the custom field and it looks like this:
    image
  12. Close the custom field
  13. Click on Articles
  14. Click on New
  15. Give the Article a Title of All about marbles
  16. Click on the Fields tab
  17. Click on the green + sign to add a new line
  18. Enter the text Small
  19. Enter the description I want to make this marble grow
  20. Click on the green + sign to add a new line
  21. Enter the text Medium
  22. Enter the description I have been growing this for a while
  23. Click on the green + sign to add a new line
  24. Enter the text Large
  25. Enter the description It is as big as it gets
  26. Your table now looks like this:
    image
  27. Save and close the article
  28. Now view the article on the site
  29. Your article should look like this:
    image

There you have a it. Users can now create their own lists. If you are creative, you can use it to make tables or other kinds of lists.

Feedback

Let me know if this is something to be considered for core. If not, I will just close this request.

avatar roland-d roland-d - open - 26 Apr 2018
avatar roland-d roland-d - change - 26 Apr 2018
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 26 Apr 2018
Category Administration Language & Strings SQL Installation Postgresql MS SQL Front End Plugins
avatar roland-d roland-d - change - 26 Apr 2018
Labels Added: Language Change New Feature PR-3.9-dev
avatar brianteeman
brianteeman - comment - 26 Apr 2018

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

avatar brianteeman
brianteeman - comment - 26 Apr 2018

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

avatar Septdir
Septdir - comment - 26 Apr 2018

@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 ?

avatar roland-d
roland-d - comment - 26 Apr 2018

@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.

avatar laoneo
laoneo - comment - 26 Apr 2018

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?

avatar brianteeman
brianteeman - comment - 26 Apr 2018

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

avatar brianteeman
brianteeman - comment - 26 Apr 2018

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

avatar laoneo
laoneo - comment - 26 Apr 2018

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

avatar joomla-cms-bot joomla-cms-bot - change - 26 Apr 2018
Category Administration Language & Strings SQL Installation Postgresql MS SQL Front End Plugins Administration Language & Strings SQL Installation Postgresql MS SQL Libraries Front End Plugins
avatar roland-d
roland-d - comment - 26 Apr 2018

@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.

avatar brianteeman
brianteeman - comment - 26 Apr 2018

@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

avatar roland-d
roland-d - comment - 26 Apr 2018

@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.

avatar laoneo
laoneo - comment - 26 Apr 2018

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

avatar roland-d
roland-d - comment - 26 Apr 2018

@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:
image

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.

avatar AndyGaskell
AndyGaskell - comment - 26 Apr 2018

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.

avatar brianteeman
brianteeman - comment - 26 Apr 2018

@roland-d i get it

avatar AndyGaskell
AndyGaskell - comment - 26 Apr 2018

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

avatar coolcat-creations
coolcat-creations - comment - 26 Apr 2018

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 ?

avatar laoneo
laoneo - comment - 26 Apr 2018

Now I got it the enlightenment too. Nice one.

avatar laoneo
laoneo - comment - 26 Apr 2018

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.

avatar ggppdk
ggppdk - comment - 26 Apr 2018

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 ?

avatar brianteeman
brianteeman - comment - 26 Apr 2018

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

avatar roland-d
roland-d - comment - 26 Apr 2018

@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.

avatar Septdir
Septdir - comment - 26 Apr 2018

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

avatar brianteeman
brianteeman - comment - 26 Apr 2018

@brianteeman I am open to suggestions

How about calling it
"Create a list"

avatar Septdir
Septdir - comment - 26 Apr 2018

About name maybe multiple text
Maybe add multiple option for plg_fileds_text

avatar laoneo
laoneo - comment - 27 Apr 2018

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.

avatar roland-d roland-d - change - 27 Apr 2018
Title
[FEATURE] A Display List Custom Field
[FEATURE] A Repeatable Custom Field
avatar roland-d roland-d - edited - 27 Apr 2018
avatar roland-d roland-d - change - 27 Apr 2018
The description was changed
avatar roland-d roland-d - edited - 27 Apr 2018
avatar roland-d
roland-d - comment - 27 Apr 2018

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.

avatar Septdir
Septdir - comment - 27 Apr 2018

@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.

avatar laoneo
laoneo - comment - 27 Apr 2018

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

avatar Septdir
Septdir - comment - 27 Apr 2018

@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

avatar laoneo
laoneo - comment - 27 Apr 2018

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

avatar Septdir
Septdir - comment - 27 Apr 2018

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

avatar laoneo
laoneo - comment - 27 Apr 2018

@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.

avatar Septdir
Septdir - comment - 27 Apr 2018

I have tested this item successfully on f3e4c64

Tested in Joomla 3.9-dev


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20243.

avatar Septdir Septdir - test_item - 27 Apr 2018 - Tested successfully
avatar roland-d
roland-d - comment - 27 Apr 2018

@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.

avatar roland-d
roland-d - comment - 27 Apr 2018

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

On Github it is shown as this:
image

avatar mbabker
mbabker - comment - 27 Apr 2018

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).

avatar woluweb
woluweb - comment - 5 May 2018

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 :) )

avatar roland-d
roland-d - comment - 7 May 2018

@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.

avatar woluweb
woluweb - comment - 7 May 2018

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 :)

avatar coolcat-creations
coolcat-creations - comment - 9 May 2018

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).


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20243.

avatar coolcat-creations coolcat-creations - test_item - 9 May 2018 - Tested successfully
avatar laoneo
laoneo - comment - 9 May 2018

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.

avatar coolcat-creations
coolcat-creations - comment - 9 May 2018

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 :)

avatar laoneo
laoneo - comment - 9 May 2018

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

avatar AndySDH
AndySDH - comment - 9 May 2018

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.

avatar laoneo
laoneo - comment - 9 May 2018

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.

avatar AndySDH
AndySDH - comment - 9 May 2018

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.

avatar woluweb
woluweb - comment - 9 May 2018

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.

avatar AndySDH
AndySDH - comment - 9 May 2018

@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...

avatar roland-d
roland-d - comment - 9 May 2018

@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.

avatar AndySDH
AndySDH - comment - 9 May 2018

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...

avatar AndySDH
AndySDH - comment - 9 May 2018

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

avatar brianteeman
brianteeman - comment - 9 May 2018

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

avatar roland-d
roland-d - comment - 10 May 2018

@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.

avatar roland-d roland-d - change - 14 May 2018
Labels Added: PR-3.10-dev
Removed: PR-3.9-dev
avatar roland-d
roland-d - comment - 17 May 2018

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

avatar ot2sen ot2sen - test_item - 18 May 2018 - Tested unsuccessfully
avatar ot2sen
ot2sen - comment - 18 May 2018

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


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20243.
avatar roland-d
roland-d - comment - 18 May 2018

@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?

avatar ot2sen
ot2sen - comment - 18 May 2018

@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

avatar roland-d
roland-d - comment - 18 May 2018

@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?

avatar ot2sen
ot2sen - comment - 18 May 2018

@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

avatar roland-d
roland-d - comment - 19 May 2018

@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:

image

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

avatar alikon
alikon - comment - 19 May 2018

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

avatar roland-d
roland-d - comment - 19 May 2018

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

avatar alikon
alikon - comment - 19 May 2018

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

avatar ot2sen
ot2sen - comment - 19 May 2018

@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.

avatar joomla-cms-bot joomla-cms-bot - change - 19 May 2018
Category Administration Language & Strings SQL Installation Postgresql MS SQL Front End Plugins Libraries SQL Administration com_admin Postgresql MS SQL Language & Strings Installation Libraries Front End Plugins
avatar roland-d
roland-d - comment - 19 May 2018

@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?

avatar ot2sen
ot2sen - comment - 19 May 2018

I have tested this item successfully on d09ba7c

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


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20243.

avatar ot2sen ot2sen - test_item - 19 May 2018 - Tested successfully
avatar ot2sen
ot2sen - comment - 19 May 2018

@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.

avatar yvesh
yvesh - comment - 19 May 2018

I have tested this item successfully on 675d0a7

Works as expected!


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20243.

2018-05-19_15-05-1526738135

avatar yvesh yvesh - test_item - 19 May 2018 - Tested successfully
avatar joomlara
joomlara - comment - 19 May 2018

I have tested this item successfully on f6542e0


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20243.

avatar joomlara joomlara - test_item - 19 May 2018 - Tested successfully
avatar joomlara
joomlara - comment - 19 May 2018

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

avatar ot2sen ot2sen - test_item - 19 May 2018 - Tested successfully
avatar ot2sen
ot2sen - comment - 19 May 2018

I have tested this item successfully on e13a749

Still works


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20243.

avatar franz-wohlkoenig
franz-wohlkoenig - comment - 19 May 2018

Why is only one Test count as successful?

avatar Quy
Quy - comment - 19 May 2018

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

avatar roland-d
roland-d - comment - 19 May 2018

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

avatar Quy Quy - change - 19 May 2018
Status Pending Ready to Commit
avatar Quy
Quy - comment - 19 May 2018

RTC


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20243.

avatar mbabker
mbabker - comment - 19 May 2018

Merged to 3.9 via 327fa65

avatar mbabker mbabker - change - 19 May 2018
Status Ready to Commit Closed
Closed_Date 0000-00-00 00:00:00 2018-05-19 22:31:00
Closed_By mbabker
Labels Added: RTC
avatar mbabker mbabker - close - 19 May 2018
avatar laoneo
laoneo - comment - 2 Jun 2018

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

avatar coolcat-creations
coolcat-creations - comment - 26 Jun 2018

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?
grafik

avatar roland-d
roland-d - comment - 26 Jun 2018

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

avatar coolcat-creations
coolcat-creations - comment - 26 Jun 2018

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?

avatar coolcat-creations
coolcat-creations - comment - 26 Jun 2018

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

avatar laoneo
laoneo - comment - 26 Jun 2018

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

Add a Comment

Login with GitHub to post a comment