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
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
Credit to @SaifurRahmanMohsin
Added getConfig to make it easier for developers to fetch the config data from a list column while overriding the list items through extension. This also makes the class more compatible with [FormField](https://github.com/octobercms/october/blob/master/modules/backend/classes/FormField.php) which already has the same helper function.
An exception was thrown when loading middleware if a requested controller is from a disabled plugin, as the `getRequestedController` method returns a Response object in this scenario.
Hat tip to @w20k.
This will detect invalid navigation item configuration in installed plugins. In debug mode, this will throw an error, otherwise, it will simply log the error.
Credit to @Samuell1. Fixes#4491.
Fixes#4046
It is possible that the user model gets fetched using the SoftDelete
trait before the relevant migrations were applied during an update.
To fix this edge case the user model is always fetched using the
withTrashed scope and the deleted_at check is done manually afterwards.
@see https://github.com/octobercms/october/issues/3999
This enables complex FormWidgets that need to know what Form widget they belong to to access that information with $this->formField->form; This also enables a fix for: https://github.com/rainlab/location-plugin/issues/48
There are no `form` elements in the preview context of a form, so this adds an alternative selector to use when no common `form` elements are found for the Input Trigger API to use. Credit to @fansaien
