Feature #97247
closedTYPO3 extensions ins typo3conf/ext should use namespace & cleaner bootstrapping (replacement for ext_localconf.php)
0%
Description
Beside TYPO3 I have some background work with Laravel & Package development. I think for more recent TYPO3-Versions these suggestions should be considered:
1.) Extensions should not be installed as typo3conf/ext/my-package
,
instead it should also use namespace, like: typo3conf/ext/myvendor.my-package
2. Using ext_localconf.php feels really "dusty" while working with some other php-frameworks & package-development.
I think there would be many advantages using a bootstrap-class instead. Just to give a hint what I mean.
For Laravel packages an integration looks like this, being able to register configuration, services, routes and so on
use Illuminate\Support\ServiceProvider;
namespace ExamplePackage {
# Custom 'use'-statements are here
class ExamplePackageServiceProvider extends ServiceProvider
{
public function boot()
{
# code...
}
public function register()
{
# code...
}
}
}
I would love TYPO3 using now a lot of Symfony components to adopt this as replacement for ext_localconf.php. I even think it would be "easy" to wrap existing ext_localconf.php's into such a structure.
There could be so many advantages just to mention:
- These files could be serialized for caching
- every Extension configuration are wrapped into it's own namespace!
- Loading and handling of each boostrapper could be wrapped with try/catch making everything more stable and fault-tolerant.
- the whole integration for packages follows more modern principles
If you agree I would love to help implementing such modernisation. I think this could be done flawless while preserving the current behaviour of ext_localconf.php configurations.
Updated by Christian Kuhn over 2 years ago
- Status changed from New to Closed
Hey Gabriel.
You're right in both points.
- ext_localconf.php / ext_tables.php: Yes, we want to get rid of these. If you look at younger core releases, you'll see they're shrinking a lot over time. For instance in v12, BE module registration is now done without using ext_tables.php, and we're migrating more and more old hooks to events. Some hard nuts are left, but we continue to reduce this until there is no need for these two files anymore.
- typo3conf/ext/<ext-name>: The strategy is here to keep extensions in vendor/ folder - just like any other package, and to just link/copy the Resources/Public folder to public. The younger CmsComposerInstallers provide this already for composer instances. We'll also continue in this area with further core versions.
As such, we are aware of these points and we agree. Patches for single areas will be done with dedicated patches in different issues, though. But I don't think there is a general need for this 'strategy' issue and some parts will simply take some further time to continue and get done. I hope it's ok to close here for now, since this general issue does not help us too much on this path and the general goal similar to what you outlined with this issue is accepted.