getLoadValue() was previously using the find method for getting the selected model on load when not using the Record Finder in relation mode.
This means it was searching by the primary key, regardless of whether the keyFrom setting on the Record Finder widget was changed. This has the effect of the keyFrom setting being correctly used to determine the value of the record finder field when a model is selected, but the widget being unable to find the model when it refreshes or reloads.
This change instead searches for the field's value in the column specified for the keyFrom setting, allowing us to use a different identifying column for loading the selected record.
This change removes the default postback handler for the datatable
widget (onSave) and instead relies on the closest form's request
handler. While `onSave` was a safe default, it did not take into account
the relation widget using other handlers.
The table widget will use an explicitly specified handler first, then it
will try and use the form's request handler, before using `onSave` as a
fallback, although this should really never occur.
Fixes#4776.
These can be added back in post-Laravel 6 era (> PHP 7.2)
Also removed the defaults since they are no longer needed, supplied by the new objects
Refs #4929
Can be one of three values:
- "default": Shows all repeater items expanded on load.
- "collapsed": Shows all repeater items collapsed on load.
- "accordion": Shows only the first repeater item expanded on load. When another item is clicked, all other open items are collapsed.
Implements #4801. Refs: https://github.com/rainlab/builder-plugin/issues/165, #2631
The upgrade to the latest Dropzone.js brought in a new `timeout` configuration variable, which defaults to 30s. This removes the time limit and restores original functionality.
Fixes#4869
This is a complex issues where a "model not found" exception is getting thrown during the `pageAction` cycle, then getting suppressed by the fatal error handler:
try {
// RelationController throws error here
}
catch (Exception $ex) {
$this->controller->handleError($ex);
}
Fixes#4784
It is unsure why this was ever needed, but it appears to fix the overflow issues with the sortable plugin
Refs https://github.com/rainlab/pages-plugin/issues/384
Refs 11be3fede39024f285309f61cbf32ee4d0d5cc28
This is one step closer to fixing the sorting issues when a scrollbar is present. It still doesn't quite fix the issue, still need to find a way to get the container dimensions to update
Refs https://github.com/rainlab/pages-plugin/issues/384
Refs 1d91c221b0b32592ec93c9f4824d108fc2a5cc5e
Similarly named repeater fields being used in viewBag variables were being assigned aliases which succeeded the `strpos` check on line 407. This will more clearly look for a child repeater form and index.
Fixes#4808
This occurs due to a race condition in the rendering where the scrollbars enable and disable over and over because of a slow height calculation. Giving any height number appears to close the loop by never letting the height resolve to 0
Refs #4632
If the DataTable widget is loaded in a Popup, the .focus() call does not
seem to focus the target element correctly, which leads to the problem,
that the updateCellFromFocusedItem method fails to find the focused
item.
This commit passes the target item along since it is already known.
When the value is null [id >= ''] an error is thrown, not being an integer, while [id >= null] will return nil results, curiously. Here we emulate infinity by using a large-ish number instead of null. In future if this becomes a problem we may need to resort to multiple condition definitions as a more verbose solution, for example:
- For when both are set (conditions: id >= ':min' and id <= ':max')
- For when min is set (conditionsMin: id >= ':min')
- For when max is set (conditionsMax: id >= ':max')
When ordering is applied externally, ie. by a relation config, the orderBy call in the List widget simply adds an additional field to the ordering clauses, which prevents lists in these scenarios from being re-ordered correctly. This changes the order clause so that the ordering is reset and only the specified column is ordered when the user sorts a column.
Developers can continue to use the `extendQuery` event to do specialised custom ordering if required.
Fixes#4439.
