Basically exploiting the autoloader's ability to locate classes. So stick a 'module' class in a folder and hey-ho - it doesn't matter where it lives - we'll find it.
This is a breaking change because existing site modules will need to define the module class. The migration is relatively simple. There's a to do it all, but basically looks like this:
namespace SproutModules\Karmabunny\ModuleName;
use Sprout\Helpers\Module;
class MyModule extends Module
{
use ModuleSiteTrait;
}
This will find any existing sprout_load.php and admin_load.php files. The module version will track the root package.
It was considered (and briefly existed) that there could be an automatic shim for 'classic' modules. This only created more confusion so the effort was instead directed to make the migration easier.
Future work
It's possible that Sprout itself is a module (to a degree). The configurations, admin controllers, widgets, sprout_load, admin_load all fit into the same lifecycles and paths of a module.
This is part of Sprout 4.0
Modules loaded via Composer and other tricks.
Basically exploiting the autoloader's ability to locate classes. So stick a 'module' class in a folder and hey-ho - it doesn't matter where it lives - we'll find it.
This is a breaking change because existing site modules will need to define the module class. The migration is relatively simple. There's a to do it all, but basically looks like this:
This will find any existing
sprout_load.phpandadmin_load.phpfiles. The module version will track the root package.It was considered (and briefly existed) that there could be an automatic shim for 'classic' modules. This only created more confusion so the effort was instead directed to make the migration easier.
Future work
It's possible that Sprout itself is a module (to a degree). The configurations, admin controllers, widgets, sprout_load, admin_load all fit into the same lifecycles and paths of a module.
Does this bring any tangible benefit? Dunno.