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.
- Allow minimum or maximum to be unspecified, meaning you want everything up to maximum, or everything above minimum.
- Allow for zero values to work
- Tweak display of infinite values
Fixes#3982.
Still need to resolve an issue where if the slave filter has values set when the master filter updates, thus triggering a change of the available options to the slave, the original values are still set on the slave but not actually visible in the popup as options because they're no longer valid options. To fix this we'll need the ability to get the browser to refresh the slave filter's selected values (count icon basically since it already forces the options popup to refresh) when its masters update; while at the same rechecking the slave's scope values set on the server to ensure that they're all valid and there aren't values left over from the previous request that are no longer valid but are still being applied to the query.
Reverts f73d8e6d49. While there are other ways to achieve some of the same end results, this code existed in the code base for 8 months without issues and is included in the official docs. This means that there could be devs that are depending on this behavior. Additionally, while this may make the internal logic to the BackendController class more complex, it simplifies the developer experience by bringing the Backend\Classes\Controller base class more in line with the standard Laravel controller class.
This was a contentious change is generally a bad idea to blanket all requests with a dependant cookie. We will try something else.
Revert enableXsrfCookies setting. Fixes UX issue introduced where the token expires. This should be replaced by a CSRF policy that determines whether this is needed on the front end.
runInternal has been removed because we do not want to blanket our response logic over every single response, only the happy path. This is because it is impossible to remove. So it is better to take the inverted approach, where if you want the CMS' headers in your custom response, add them yourself. This becomes easy via the new makeResponse() method
For some reason it was decided to allow October controllers to support Laravel middleware, this has been reverted because it is a convoluted solution that doesn't respect the original architecture. There are other ways to handle middleware requirements
The original use case appeared to be to simply allow backend controllers to inject headers. This is something easily solvable whilst keeping the simple and original workflow
