The web based Updates controller avoids this issue by completing the migration step as a separate AJAX request from the step where the plugin files are installed, thus allowing for the plugins to be registered by the PluginManager prior to migrations being run. As the plugin:install CLI command runs in a single request, it is necessary to manually register the newly installed plugin prior to running any migrations for the plugin so that any dependencies introduced by the plugin are guaranteed to be available prior to plugin code being run.
`artisan theme:sync --target=database --force --paths=layouts/,pages/,partials/`
But at the moment it also synchronizes paths that should not be synchronized. For example: `content/static-pages/`. Because here the pattern applies to `pages/`.
The fix is that the pattern starts at the beginning of the line.
Co-authored-by: Heiko Böhme <hboehme@menadwork.com>
Provides the ability for developers to specify a custom message for bulk deletion actions, as well as a custom message when no records could be deleted due to missing selections or an altered query not finding any applicable records.
It appears that doing this in the "register" process can result, at times, in an exception to be thrown as the connection to the DB is not yet established.
Plugins now have the ability to define quick actions through a "registerQuickActions" method, which follows the same configuration as the "registerNavigation" method. It is still recommended and preferred that most plugin functionality be defined in their own main menu items, but this will allow a plugin to easily define a shortcut (or remove one).
Fixes#5127, also will force a page reload after changing the status of a plugin (remove, disable, enable, etc) so that the menu structure is accurately reflected.
The Laravel view engine wants to supply the Twig engine with an absolute path, even though this is outside the inclusion rules. This implements a temporary exception to wave it through. It seems like a suitable alternative instead of implementing a reverse lookup to ensure the path is a valid view file, since we can trust the source engine has passed the value through its resolver already
Fixes previous fix
This logic is called via {% include %} (fixed) and as a custom .htm driver for View::make (broken). The previous change was too aggressive and broke the latter. This still fixes arbitrary file inclusion whilst retaining the original design. Both logic paths are now fixed and have been tested
Both the "view" and "manage" widgets, in list mode, now support a custom message when no records are available. To maintain BC, if "emptyMessage" is provided in the relation config, this is still used for the "view" widget in list mode.
Fixes https://github.com/octobercms/october/issues/3594
