I know it has been discussed before, now I am asking: Is it a good idea to put modules inside packages? One point is portability. The other is that putting one module inside a package just because portability is a bit ugly. :D But if the module needs some bootstrap.php-like autoloading then you either call it from the app's bootstrap or put it in a package and use that bootstrap.
I personally don't use modules in packages, I keep a strict separation between "frontend" or "application" logic (i.e. modules) and "backend" logic (i.e. packages).
That doesn't mean you can't design your modules to be portable, all our modules are designed to not have dependencies to other application logic, so we can freely share them between applications.
In our app framework, every module has a controller called 'module'. It's not really the same as bootstrapping, because ours is only called (using HMVC) when needed, all other stuff is done in migrations and stored so we don't have to process module setup data on every page request.
My other problem in connection with modules is asset management. I am trying to make modules to be portable, this means I am trying to make it work with one git pull or composer install, but if I want to use assets, I have to put them in the public dir.
My idea is to extend the asset class. When it tries to load an asset from a package or a module (based on the name) and that does not exists then it tries to fetch it from the module/package dir.
Assets have to by inside the docroot, otherwise a browser can't fetch them. If you leave them outside, you'll need a piece of PHP to fetch the file and output it (which adds overhead).
Extensions to both Asset and Theme are not going to solve this issue (which is on my personal todo list for quite some time...).
We currently solve it with rewrite rules at the apache level, but that's very inflexible and high maintenance.
Actually I was not clear: The asset would not fetch, but copy the requested asset to the docroot. This will only add overhead at the beginning (the first time the asset is requested). Actually this is some sort of cache.
It would be better to do that in deployment and not bother the frontend with it.
Every time we deploy (push to staging or production), we also run all migrations. We would put the copy in a migration file.
Well, we would probably create a symlink, that would make /public/themes/ourtheme/modulename a symlink to /modules/modulename/themes/ourtheme. That is a one-time operation, everytime you deploy after that your changed theme assets would be available immediately.
You might not be able to do this on a shared host though, I don't know, we don't use those.
Donate
