User tests: Successful: Unsuccessful:
Pull Request resolves # .
Adds an optional Copy button to the rows of a repeatable subform. It inserts a new row below the row it belongs to, with the values of that row.
SubformField: new copy value for the buttons attribute, for example buttons="add,copy,remove,move". Off by default.button-copy attribute.joomla-field-subform: copyRow(). The values are set on the new row before it is inserted, so fields that initialise when they are added to the page (fancy select, editor, calendar, showon) start with the copied values.JGLOBAL_FIELD_COPY and PLG_FIELDS_SUBFORM_PARAMS_COPY_ROWS_LABEL.Notes for review:
JoomlaEditor from editor-api to read the current content of an editor, and the webcomponent.field-subform asset depends on editor-api.The PR changes JavaScript and SCSS. Use the prebuilt package of this PR, or apply it and run npm ci.
Custom fields
Form API
Add buttons="add,copy,remove,move" to a repeatable subform in any form XML, for example:
<field name="rows" type="subform" label="Rows" multiple="true" max="3"
layout="joomla.form.field.subform.repeatable-table" buttons="add,copy,remove,move">
<form>
<field name="title" type="text" label="Title" />
<field name="tags" type="tag" label="Tags" mode="ajax" multiple="true" />
<field name="text" type="editor" label="Text" filter="safehtml" />
<field name="user" type="user" label="User" />
</form>
</field>Check that the copy has the same values, that a newly typed tag and the editor content are copied, that the button does nothing when the maximum number of rows is reached, and that the button works with the keyboard (Tab to the button, Space or Enter).
Also check a language with RTL direction: in the form and grid layouts the button sits next to the Add button.
A subform row can only be added empty. There is no "Copy Rows" option in the Subform field.
copy in buttons) shows a Copy button in each row.Please select:
Documentation link for guide.joomla.org:
No documentation changes for guide.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
| Category | ⇒ | Administration Language & Strings Layout Libraries NPM Change JavaScript Front End Plugins |
Thanks a lot for your feedback! Back to the drawing board. i've investigated alternative solutions.
I looked into two ways:
option 1: Before reading the source row, the subform dispatches one generic event on it, alongside the joomla:updated and joomla:removed events it already sends. Fields that keep state outside their controls write it back when they receive it. TinyMCE and CodeMirror each get a small listener next to their existing joomla:updated handling.
option 2: No new event; the editors keep their textarea up to date themselves (save on blur or change).
My guess is the calendar data-alt-value trick is also unwanted 😅. So i was thinking to change it so when it initialises with a value but no alt value, it should parse the value. The calendars own change handler already does it like this from what i understand.
I'll put this PR to draft until we figure out the best way forward.
| Title |
|
||||||
| Labels |
Added:
Language Change
NPM Resource Changed
PR-6.3-dev
|
||
Hmm i think it is better to do one event for the whole row that will cover all fields:
Option 1, refined: instead of an event that only asks the source row to write its state back, the subform could fire one event per copied row, like subform-row-add, with the source row, the new row and the matched controls (source control and its counterpart in the new row) in the detail. Every field that keeps state outside its controls can then carry it over itself: the editors put their current content into the new textarea, and the calendar copies its data-alt-value. The subform stays unaware of field types, and third party fields can use the same event.
That would replace my calendar idea above. Parsing the value loses whatever the display format hides, for example the time of a date that is shown without it.
You like this better or do you have other idea's on how it should be implemented?
Hmhm, need to think. Cannot say currently.
Hmhm, need to hink. Cannot say currently.
Thanks for a try.
I am sorry, this is not acceptable.
The feature should work independend from the form fields like it does currently when User push "Add row".
We need to look how we can extend our API to make it work properly without such hacking.
This will get an issue reaport very quickly ;)
It is better no feature than half working feature ;)