Project

General

Profile

Feature #97264

Updated by Simon Schaufelberger over 2 years ago

I noticed from TYPO3 v11 there is an updated best-practice architecture for handling with ext_localconf.php. I'm referring refering to this document: 
 https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/ConfigurationFiles/Index.html 

 


 Mentioning NOT to use global namespaces to avoid namespace nesting. This is correct, but I think it would be a better approach to use classified namespaces for the extension vendor/extension key: 

 like this: 

 <pre><code class="php"> ``` 
 <?php 
 namespace My\FooBarExt { 
   use TYPO3\CMS\Core\Utility\VersionNumberUtility; 
   use TYPO3\CMS\Core\Utility\ExtensionManagementUtility; 

   defined('TYPO3_MODE') || die('Access denied.'); 

   (function ($extKey) { 
     // ... here is what usually is inside ext_localconf.php 
   })('my_foobar_ext'); 
 } 
 </code></pre> 


 ``` 

 I would much more favor to replace ext_localconf.php with a Package-Registration File/Class that looks like those one used in Symfony or Laravel Packages being able to configure f.e. Site YAML (site-package config & extension routes) and services provided by the package. 

 This would follow more the new approach to go with Symfony/HTTP-Foundation Symfony/HTTP-Foudnation coding standards. Here's an example for a ServiceProvider from laravel which I really like for how it is handling package (aka extension) registration: 

 https://laravelpackage.com/03-service-providers.html#creating-a-service-provider 

 


 Please drop me some constructive feedback. Please let me know if there are plausible reasons NOT to use any php namespace wrapping in ext_localconf.php or is this only meant ment for the global "namespace {}" without classified name?

Back