This reverts commit 203d2c4ebac696d39d3dbd92137077db3fb82978 as it was causing issues with classes that didn't exist.
> The class that is not found is: Winter\User\Classes\UserEventBase
This fixes an issue where composer dependencies on replaced plugins are directly swapped with the replacement plugins meaning that the replaced plugin files are no longer present in the filesystem when the replacement plugin tries to register for the first time.
Documented by https://github.com/wintercms/docs/pull/11
Co-authored-by: @jaxwilko Jack Wilkinson <me@jackwilky.com>
Co-authored-by: @mjauvin Marc Jauvin <marc.jauvin@gmail.com>
Co-authored-by: @bennothommo Ben Thomson <git@alfreido.com>
Co-authored-by: @LukeTowers Luke Towers <github@luketowers.ca>
Fixes#13
Follows on from wintercms/storm#16
Moves the version.yaml processing into the System module and updates all version file parsing to use this new processor.
On PHP 7.4 method_exists can return true for protected (i.e. not callable) methods. Additionally, some plugins already implemented their own registerValidationRules method not implementing the expected return type, so that needed to be handled more gracefully
During the regular october install using october:install, the user-defined password is overwritten with the random generated string password. Instead, now it uses random password only if the user-defined password defaults to *admin* and if a user did set a custom password, that is used instead.
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).
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.
SystemExceptions are already logged when the System ServiceProvider listens to the Message Logged event, this code used to be for ApplicationExceptions to bypass the fact that they were explicitly ignored by October's core exception handler.
ApplicationExceptions were added 27 Jan 2015 in 6a68036260
ApplicationExceptions were explicitly ignored in the core exception handler on 16 Feb 2015 in 237d97d87a (diff-b6bf0348130fdd1311473a97536310cdR20) and were explicitly logged in the System exception handler on the same day in 7b52e07b65 (diff-547f5794a63e9f138c33b20de8649b7eR20-R31)
Not sure why that was originally the case, but we've made the decision that ApplicationExceptions shouldn't be logged by default as they should occur semi-regularly in a healthy application (mostly as an expression of complex logical validation that triggers them based on bad user input): https://github.com/octobercms/october/pull/4569#issuecomment-550172508Fixesoctobercms/october#5253.
