Supporting or prohibiting recursive mount points?

[t3elmar]

Invitation to comment and decide

In the BE forms it's possible to mount another mount point from a mount point form.

Neither the BE page tree nor the FE menus create mount point parameters that can deal with a recursive mount point.

To get a smooth user experience instead of broken root line exceptions, it should be clarified and communicated how to deal with recursive mount points.

Decision

[1] Prohibiting recursive mount points.
[2] Disabling recursive mount points by configuration
[3] Targeting the support of recursive mount points in all parts of TYPO3.

Are there use cases at all?

I discover only one.

Given directories/pages A, B, C, D, E, etc. mount a page P that is a mount point itself. At point P shared prepared subdirectories can be exchanged in a single point. M replaces N. Without recursive mount point the replacement with N is necessary in all of A, B, C, D, E, ...

Do you find more use cases? Are they worth to support recursive mount points? If not, how are they prohibited with useful feedback for the user?

Description

1. Prohibiting recursive mount points.

The policy is to not support recursive mount points. A clear understandable exception is thrown. The BE forms shall inform the user in a suitable way, that recursive mount points are not supported.

2. Disabling recursive mount points by configuration

Like case 1, when disabled (the default).

When enabled, it's possible to create recursive mount points in the BE. It's up to the developer, to care that recursive mount points work in the FE, i.e. by creation of an extension.

3. Targeting the support of recursive mount points in all parts of TYPO3

All parts of TYPO3 shall be prepared to support recursive mount points:

• Documentation
• Root line loader
• FE Menus
• BE links

Pro and Cons

Pro 1.

• The uses cases are that rare, that all support shall be dropped.
• Clear and easy.

Con 1.

• It's against the spirit of TYPO3 to disable features.
• There may be installations having a private implementation of it.

Pro 2.

• Disabled behaviour is what most users want.
• Existing installations don't break when enabled..

Con 2.

• It's overhead to set up a configuration for such a rare feature.
• There are already to many configurations.

Pro 3.

• It's a cool feature.
• It's in the spirit of TYPO3 to support such enterprise features.
• It's not that difficult to do.
• We love technical perfection.

Con 3.

• Nobody really needs it.
• Will never get done.

Remarks and notes

I basically proved that the resolution of recursive mount points is doable.

https://review.typo3.org/#/c/52461/71/typo3/sysext/core/Classes/RootLine/Internal/MountPointResolver.php

The URL of a recursive mount point requires multiple pairs of adjacent mount point parameters.

MP=66-55,55-44,44-33

Here page 66 is mounted on 55, 55 on 44 and 44 on 33. If all mount point records set the overlay setting, the content of page 66 is propagated up to page 33.

It would be doable to create this kind of parameters in page tree and menu URLs.

(If a page is mounted from multiple pages the preview button in the page tree can only create one of the possible mount point combinations. The combinations determine the breadcrumb in the FE, if multiple alternative paths to the root page are given.)

The current resolution of the mount point only supports a single MP pair, likely causing the issues with recursive records in the BE page tree.

Organizational

Topic Initiator: Elmar Hinz

[benni]

Did you find any use cases on forge.typo3.org where people complain that they need it?

Also, do we need to have an additional definition what happens to page overlays? (because target pages do not necessarily have a translation record of the current language).

Feels like the "recursive sys_domain records" feature which was never officially supported by kasper but people get it working, if they can that's fine but the official statement is still "At your own risk".

I personally tend to option 1. We still have loads of bugs related to the regular mount points on review.typo3.org and forge.typo3.org, which have a higher priority IMHO than this functionality. Plus, once the other fixes are done, we can see if this functionality could be built on top of the abstracted functionality.

[t3elmar]

The question of overlay pages applies for a simple mount point as well. Currently the overlaying mounted page is just used as it is loaded. Both pages, mount point and mounted page, delegate the language resolution to getPageOverlay.

$row = $this->pageRepository->getPageOverlay($row, $languageUid);

Is there a need for an additional definition?

My issue is rather with:

$this->pageRepository->versionOL('pages', $row, false, true);
$this->pageRepository->fixVersioningPid('pages', $row);

They don't take all state parameters. They depend on the state of $GLOBALS['TSFE']->sys_page. Either I need to create a new repository object or change the state temporarily and using backup values. It's difficult to estimate all implications of such an operation.

protected function loadWithContextAdjustment(
    int $pageId,
    RootLineIdentity $rootLineIdentity
): array {
    $record = $this->loadRecord($pageId);

    // Backup page context
    $pageRepository = $this->pageRepository;
    $contextBackup = [
        $pageRepository->sys_language_uid,
        $pageRepository->versioningWorkspaceId,
        $pageRepository->versioningPreview
    ];

    // Adjust the page context to the given settings.
    list(
        $pageRepository->sys_language_uid,
        $pageRepository->versioningWorkspaceId,
        $pageRepository->versioningPreview
        ) = [
        $rootLineIdentity->getLanguageId(),
        $rootLineIdentity->getWorkspaceId(),
        $rootLineIdentity->isVersioningPreview()
    ];

    $record = $this->handleRecordWithinAdjustedContext($record);

    // Context reset
    list(
        $pageRepository->sys_language_uid,
        $pageRepository->versioningWorkspaceId,
        $pageRepository->versioningPreview
        ) = $contextBackup;

    return $record;
}

[system]

This topic was automatically closed after 28 days. New replies are no longer allowed.