When removing a plugin via CLI or rolling back all DB migrations, we will now require the user to type out the plugin name (or "DELETE" for "winter:down") as a confirmation in order to proceed. This ensures that the user is well aware of what they are doing.
The "plugin:remove" command has now been added a "--no-rollback" option. When used, the plugin files will be removed, but the DB will remain untouched, allowing people to remove a plugin without losing their data.
Refs: https://github.com/wintercms/wn-translate-plugin/issues/13#issuecomment-988364253
Credit to @RomainMazB. Documented in https://github.com/wintercms/docs/pull/34. Proposed in #201.
Co-authored-by: Luke Towers <github@luketowers.ca>
Co-authored-by: Ben Thomson <ben@abweb.com.au>
Co-authored-by: Jack Wilkinson <me@jackwilky.com>
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>
This change implements an improved "set build" utility through the "october:version" Artisan command that, instead of checking the October CMS server for the latest build, checks the module files against a source manifest kept on GitHub.
This check allows us to accurately determine the build based on the module files in the October CMS installation, and can even detect versions if the module files are modified (except in the cases of extreme modification).
An additional utility has been implemented, "october:manifest", which will build the manifest JSON file in order to provide the maintainers with a way of generating this manifest file as required.
Replaces #4615.
Only works for uploads stored on the local disk right now, support for remote disks may be added in the future at some point.
Replaces #4518 & #4029. Credit to @LukeTowers, @BennoThommo, & @austinderrick.
This allows the `theme:sync` command to properly sync to specified targets.
Fixes#4887. Replaces #4935. Credit to @bennothommo for the initial implementation.
- Adds quotes around all strings inserted into config files, preventing them from being interpreted as constants.
- Changed all private methods in OctoberEnv.php to protected.
- Updated test to check some config files for expected changes.
This fix will apply quotes around string environment variables which contain either a single, or double, quote as well as any variables with a hash symbol - escaping any double-quotes encountered. When artisan october:env is run, this should correctly transfer all configuration values from the config files to the .env file.
Fixes#4979.
Adds an Artisan command "october:passwd" to change the password of a Backend User through CLI. This command may only be run through CLI - it will not work if called through a web handler.
Refs: #3521, #4835. Docs: 1f3bfc719e
