Project

General

Profile

Actions

Feature #97247

closed

TYPO3 extensions ins typo3conf/ext should use namespace & cleaner bootstrapping (replacement for ext_localconf.php)

Added by Gabriel Kaufmann / Typoworx NewMedia over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2022-03-28
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

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.

Actions #1

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.

Actions

Also available in: Atom PDF