- Remove $indexCount property, as it is no longer needed
- Determine highest key number in data, and increment when adding item
- Remove some old code and dependencies
Fixes#4402.
Fixes a bug which causes grouped repeaters to lose data when repeater items are re-ordered and saved, due to the data indexes not being correctly mapped to the corresponding form widget.
Credit to @datune.
Run an AJAX handler on uploading and processing a file as opposed to using a post() data check in the widget initialization, as the widget may initialize several times in certain circumstances - eg. inside a relation widget.
Credit to @alxy. Refs: https://github.com/octobercms/october/issues/4300
* register a new bundle
* add the new bundle target asset
* remove the non-proprietary source file from the proprietary bundle definition
* create a new build target for the non-proprietary asset files
* remove the non-proprietary code from the compiled proprietary asset
* add compiled and minified build-ocms file
* add missing line at the end
* use better asset file names
This allows the repeater to retrieve the load value
from the model only on initialisation. Any further
requests to the repeater (ie. AJAX requests) should
use the POST data.
This fixes#4117
Currently, the color picker modal (palette) is appended to the body (default) which makes it unusable in Octobers modals, e.g. for related model forms. This fixes this issue by appending the spectrum div to the parent element.
Credit to @alxy
There was a conflict between two repeaters that had the same fieldName (data) bound to the same controller. Example:
Controller: Events
Manages a ReportTemplate model with a custom popup Form widget that uses a grouped repeater with the field name data to define the available "fields" within a ReportTemplate
Also manages Report models through a relation controller that uses a Form widget with a regular repeater with the field name data that defines the values of the fields defined by the associated ReportTemplate.
Since both repeaters had the field name of "data", but one of them was grouped and the other wasn't, this would cause an issue in Repeater::processExistingItems() where the grouped repeater would attempt to process the ungrouped repeater's data which would then fail. This issue could easily cause many other vastly more confusing and difficult to detect issues in cases where multiple repeaters with the same field name AND the same mode (grouped vs regular) existed on the same page under different contexts. The simple solution is just to ensure that the indexInputName and groupInputName are both taking the repeater's alias into account when being generated to ensure that everything stays unique like it should.
Ben Thomson
webmaxx
Anita
Ayumi Hamasaki
Rike-cz
Marc Jauvin
Samuel Georges
Luke Towers
Luke Towers
datune
Alexander Guth
Patrik Nemeček
Serge
Tom
Anže Časar
Rachasak Ragkamnerd
SeriousKen
Szabó Gergő
Ben Thomson
Ben Thomson
rejuvenatedigital
Sebastiaan Kloos