User tests: Successful: Unsuccessful:
Pull Request for Issue #24343 (Part 1 of 2)
This PR adds a configuration option to the sortable function to trigger a "subform-row-sort" event when a repeatable subform is sorted.
After applying the PR, make a copy of the file. Delete the media/system/js/subform-repeatable.js, and rename the copy to media/system/js/subform-repeatable.js
On the bottom of the file, under
$(document).on('subform-row-add', initSubform);
add
$(document).on('subform-row-sort', function (event, row) {
console.log(row);
});
In Content -> Fields, create a new Field with the Type Repeatable. Give the Field a name, eg: Repeat Text. Create a Form Field of type Text and give it a name.
Assign the field to Category All and Field Group None.
Click Save & Close.
Create a new article to edit, click on the Fields tab. Click on the plus icon twice in Text Repeat to create 2 new Text fields.
Open your browsers javascript console.
Drag the bottom field using the blue handle to re-order it above the top field. When this is done you should see a message in the browser's Console.
After conducting the test, remove the logging script, ie:
$(document).on('subform-row-sort', function (event, row) {
console.log(row);
});
No message is disaplyed in the browser console as not sort event is triggered.
A sort event is triggered and a message is displayed in the browser console.
None.
Status | New | ⇒ | Pending |
Category | ⇒ | JavaScript |
Labels |
Added:
?
|
every pull request needs at least two successful test before merging. This doesnt have any yet.
Additionally it should use "update" instead of "stop".
The event should not be triggered if user does not change the order.
Btw, it is "new feature".
Additionally it should use "update" instead of "stop".
The event should not be triggered if user does not change the order.
If you don't change the order but still attempt the drag, this can still affect the dom and therefore the editor, which is the point of triggering the event. See the reference to the issue in the initial comment.
Btw, it is "new feature".
This is part of a fix for an issue, so is not a new feature.
There no point to trigger this event if the order does not changes.
There no point to trigger this event if the order does not changes.
Yes there is:
If someone drag and drops the item without changing the order, the content gets lost anyway if the event does not get triggered.
What @ryandemmer did here is completely fine and correct, trust me, i'm implementing his fix manually for over a year now on my sites.
Please prove, show a real case.
If someone drag and drops the item without changing the order, the content gets lost anyway if the event does not get triggered.
What and where is lost?
@Fedik - Did you read the issue this refers to? - #24343 - specifically - #24343 (comment)
I have checked, but this PR does not fix that issue.
My comment still valid:
There no point to trigger this event if the order does not changes.
I will give you a hint, every sorting library have at least 3 events:
start (always), change (only if something changed), stop (always)
If you want 1, then you required to have another 2.
nope
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-12-18 18:45:30 |
Closed_By | ⇒ | Fedik | |
Labels |
Added:
?
Information Required
Removed: ? |
I am closing it.
In current implementation it is not much useful.
If need "sorting" events, then should be all: start, stop, cancel (kind of)
Feel free to make new PR, for joomla 4.
This pull request is open for more than a year (and so is the bug in Joomla), can someone please merge it?