TYPO3 Core

The new installation process uninstalls an extension before installing it again during the update process. This is even documented in the phpDoc of the following method (from class \TYPO3\CMS\Extensionmanager\Service\ExtensionManagementService):

    /**
     * Uninstall extensions that will be updated
     * This is not strictly necessary but cleaner all in all
     *
     * @param array<Tx_Extensionmanager_Domain_Model_Extension> $updateQueue
     * @return array
     */
    protected function uninstallDependenciesToBeUpdated(array $updateQueue) {
        $resolvedDependencies = array();
        foreach ($updateQueue as $extensionToUpdate) {
            $this->installUtility->uninstall($extensionToUpdate->getExtensionKey());
            $resolvedDependencies['updated'][$extensionToUpdate->getExtensionKey()] = $extensionToUpdate;
        }
        return $resolvedDependencies;
    }

So if it's not strictly necessary, could we avoid doing it?

It could, yes, while making sure to avoid endless loops.

What this means - though - is that every time you install an extension, you need to recalculate all the dependencies. It's an overhead, but then again this does not happen so often. It would also be the right place to respect the priority property ("top" and "bottom"), which is not taken into account anymore (as I reported in a separate issue).

For 6.2, the extListArray is gone and substituted with PackageStates.php. A new algorithm takes care of load orders depending on the extension dependencies. For example, if your extension "bar" depends on other extension "foo", then it is taken care, that "foo"'s ext_localconf and ext_tables are loaded before "bar". Status of this is afaik "should work" in 6.2. Please feedback if there are still issues in this area that we may have missed (Markus Klein may be a good partner here since he wrote the sorting algorithm).

I'm sorry but priority is not the same as dependencies.

My use case is the following: I generally store all my customisations in a specific extension. I need to know that this extension is loaded last, hence the use of priority "bottom". Of course, I can set up the list of all modified extensions in the dependencies inside my extension, but it's more constraining than having just the priority.

I guess I can live with that, but we should then officially deprecate the "priority" property.

And BTW that does not change the question I posted in the list about the performance gain we could have by caching ext_emconf data.

Hey Susanne,

Good to see you active again!

I don't think there's any way to deprecate extension settings in the Core itself, since it is really information for extension developers. It could be an addition to the TER, some kind of report informing about wrong and deprecated settings.

So it would say it is mostly a documentation issue.

Even better would be "loadBefore" and "loadAfter" parameters because there are extensions that do not depend on others but need to be loaded before or after an other extension (if it is installed). So at the moment - and without "priority" - it is not guaranteed that loading order is fail safe.

yes please bring back a way to specify a load order independent of any requirements. In my case I have extensions that are used in two different contexts (websites) while on one website they must be loaded after a certain backend module was loaded and in the other context this management module doesn't (must not) exist - so I can't use dependencies but still need to ensure a certain load order. I tried to use the "priority" option, but this is not working anymore. So please add a more flexible way to ensure load orders other than hard dependencies.

Hi

Another usecase: I have an extension which prepend a hash to every resource url, in order to invalidate easily the client cache.
The rewriting is done in the hook "TSFE->contentPostProc-output", and must be done after merging/compression of another extension which use the same hook array (scriptmerger).

Another use case: Extension MyExt provides a configuration file for realurl. The configuration file contains references to configuration variables that are set by MyExt. Therefore, realurl must be loaded AFTER MyExt is loaded. But the loading order of extensions keeps changing every time an extension is installed/updated.

The actual flaw is that the various APIs do not provide a "priority system".

Even if we add a loadBefore/After setting to emconf/composer.json, I see the next reporter coming around the corner telling us that he now has the issue that Ext A says "load me after Ext B, because I add myself to API X" and Ext B says "load me after Ext A, since I use API Y".

The problem is that with "global" loadBefore you may cause other (unsolvable) issues. The only correct way to solve these kinds of issues, is to have a priority per configuration/hook.

Instead of attaching configuration with

$GLOBALS...['somehooking'][] = me::class;

$GLOBALS...['somehooking'][] = [
   'handler' => me::class,
   'priority' => 50,
   'maybeSomeOtherOptions => 'snafu'
];

Never the less we have loads of "legacy code" also in the Core, where APIs to provide those priorities. Examples: Extbase SignalDispatcher, almost all hooks, ...

It seems unrealistic to be able to change all those APIs in a short time, so we could at least ease the pain by adding the global loadBefore/*After mechanism for extensions.

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39692

Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39692

Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39711