General :
Added striped background to active progress bar
The background was animated, but without stripes it wasn't visible.
In list :
Set default height equal to cell line-height, maked use of css variable so than the user can still set a différent height.
Added background color
Added a slight box shadow for better visibility of progress bars at 0%.
Preferred to border for greater smoothness.
Added a background color when hovering over a line in the list to match the hover color.
Fixes#1000
Fixes#988.
Instead of str_replace (which instead of truncating the leading directory from the path might replace some random inner part of it) use substr to remove it.
Fixes#630
This allows global variables populated by the View::share('name', 'value') method to be used in Twig templates. The values will only be populated if they have not been specified as a global previously, to prevent overriding system globals such as this.page. It will also allow the pages themselves to still override the values if need be.
Related: octobercms/october#3208. This issue surfaces when deployment tools attempt to run various commands not already protected (i.e. vapor:health-check) before running any migrations, which causes issues if plugins attempt to access the database during their registration or booting process.
In theory we could also apply this logic to HTTP requests, however it is generally easier to see and handle the reported exception of the table being missing in an HTTP context, so it's acceptable to limit this protection to the CLI.
As a reminder, plugins making use of the $elevated permissions are responsible for defensive measures to reliably operate in potentially unstable states of the application.
Related: octobercms/october#3208. This solves an issue when attempting to access any SettingsModel before initial migrations have been run but the database exists (which is all App::hasDatabase() looks for).
For some reason, these were not true importable classes as they were using the global Snowboard variable, so they couldn't be used in custom Snowboard builds.
I've created two new build files that use the same names as the previous builds, so this should be BC, but the source files are now true classes so they can be imported at will.
Fixes https://github.com/wintercms/wn-blog-plugin/issues/33.
Note for @bennothommo @jaxwilko @mjauvin, we may have issues at some point if the replaced plugin goes past the version that the replacing plugin starts its replacement at (for example, if RainLab.Blog starts going past 2.0 then we're going to have to rethink how we handle that migration process so that we can support taking over existing migrations that go past 2.0 on the original plugin while starting the replacement plugin's migrations at 2.0, although there's potentially some issues with that too. Perhaps we could require confirmation to rollback a plugin to the last version that it could be taken over from before allowing the takeover to proceed?
This reverts 4ed9b10b4e because it breaks the use of local file disks. We will need to just bite the bullet and refactor the CMS storage config to use proper filesystem disks in general instead of the current hacky approach that's causing these problems.
See https://laravel.com/docs/10.x/filesystem#scoped-and-read-only-filesystems
