TYPO3 Core

I forgot to mention:
Put the mountpoint of "page1" of site b to "page1" of site a

I can reproduce it. It doesn't matter what the page's name is. In my scenario i have the entry domain2.local/test1, where page "test1" is a mount point to another root (domain1.local) with page "test2". The menu link on domain2.local is also wrong and points to domain1.local/test2.

It looks like, that the whole MP handling is a known open point in typo3/sysext/core/Classes/Routing/PageUriBuilder.php (line 36):

• @todo: check handling of MP parameter.

I will have a look onto the problem in typo3 sprint berlin

Hier eine Dokumentation über das Verhalten der Mountpoints in TYPO3 9.5.1-dev:

Verhalten innerhalb einer Domain:
                                slug laut BE                Link auf diese Seite                    angezeigter Inhalt
-----------------------------------------------------------------------------------------------------------------
Rootseite           pid 1       slug: /                     link: domain1/
|__unter1           pid 2       slug: /unter1               link: domain1/unter1
   |__u11           pid 3       slug: /unter1/u11           link: domain1/unter1/u11                Inhalt: "u11" 
      |__u111       pid 4       slug: /unter1/u11/u111      link: domain1/unter1/u11/u111           Inhalt: "u111" 

----- Alternative1 :mount 1 mounted auf pid3; "show mounted page" 

|__mount1           pid 5       slug: /mount1               link: domain1/unter1/u11?MP=3-5         Inhalt: "u11" 
                                                            link: domain1/unter1/u11/u111?MP=3-5    Inhalt: "u111" 

----- Alternative2 :mount 1 mounted auf pid3; "show this page" 

|__mount1           pid 5       slug: /mount1               link: domain1/mount1                    Inhalt: "mount1" 
                                                            link: domain1/unter1/u11/u111?MP=3-5    Inhalt: "u111" 

Verhalten Domain-übergreifend:

                                slug laut BE                Link auf diese Seite                    angezeigter Inhalt
-----------------------------------------------------------------------------------------------------------------
Rootseite2          pid 6       slug: /                     link: domain2/
|__unter2           pid 7       slug: /unter2               link: domain2/unter2
   |__u21           pid 8       slug: /unter2/u21           link: domain2/unter2/u21                Inhalt: "u21" 
      |__u211       pid 9       slug: /unter2/u21/u211      link: domain2/unter2/u21/u211           Inhalt: "u211" 

----- Alternative1 :mount 2 mounted auf pid3; "show mounted page" 

|__mount2           pid 10      slug: /mount2               link: domain1/unter1/u11?MP=3-10        Inhalt: => Exception!!!
                                                   Soll:    link: domain2/unter1/u11?MP=3-10        Inhalt: "u11" 

                                                            link: domain1/unter1/u11/u111?MP=3-10   Inhalt: => Exception!!!
                                                   Soll:    link: domain2/unter1/u11/u111?MP=3-10   Inhalt: "u111" 

----- Alternative2 :mount 2 mounted auf pid3; "show this page" 

|__mount2           pid 10      slug: /mount2               link: domain2/mount2                    Inhalt: "mount2" 

                                                            link: domain1/unter1/u11/u111?MP=3-10   Inhalt: => Exception!!!
                                                   Soll:    link: domain2/unter1/u11/u111?MP=3-10   Inhalt: "u111" 

I see major conceptional difficulties here. The question is: how do we want to deal with cross-domain-mounts?

The basic use case could be something like this: domain1 has a subtree, e.g. a blog, that should be shown on another page (domain2), too. On domain2 all mounted pages should have urls starting with "domain2".

By allowing that, we run into difficulties: we have to deal with internal links pointing out of the subtree onto other pages of domain1. The edge-case would be a sitemap being part of the subtree. Than the complete site domain1 would be visible under "domain2" as well.

This seems to be unwanted behaviour.

Possible solutions:
- we create a new page-property "allow shared" that allows a page and all of its subpages to be mounted on other domains as well. Internal links out of the shared pages must than either stay on the original domain or be disabled. Implementing that looks like a huge task.

- we just disallow cross-domain-mounts. The use-case "blog-subtree" could than be realised by creating a new subtree in domain2 and mapping all pages using "show content from page"

For the time beeing, I would suggest the second solution.

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

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

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/59915

$queryParameters['MP'] can have multiple comma-separated parameters, resulting in an endless redirect. The following exam works for me and fixes the problem.

typo3/sysext/frontend/Classes/Typolink/PageLinkBuilder.php:188

if (!is_null($queryParameters['MP'])) {
  $mp = explode(",", $queryParameters['MP']);
  if (count($mp) > 1) {
    $queryParameters['MP'] = $mp[0];
  }
}
$siteOfTargetPage = GeneralUtility::makeInstance(SiteFinder::class)->getSiteByPageId((int)$page['uid'], null, $queryParameters['MP'] ?? '');

Any news on that?

We ran into this issue lately too.

We will provide feedback on the current state of the patch asap.

What is the status of the problem? We need the mountpointtrees in a multi-domain-channel asap for typo3 update

Is there anything new on this? Looks like it was set to "abandoned"... When will it be taken care of again? We need this for a current project so any Updates on this would be appreciated.

We had to cancel a current upgrade project cause of this and need a fix too

I really appreciate any work targeting PHP standards and replacing self-baked solutions with known and approved packages from e.g. symfony.

But mountpoints are there since TYPO3 v3 or even longer - at least they are there ever since I can remember using TYPO3.

v9 will be in security-only-mode within 4 months and it does not look like this issue will be fixed until then.

So this basically means, there is going to be a major TYPO3 LTS version with broken mountpoint-functionality.

And still uncertain if this will ever be fixed in v10 either.

just my 2c.

Will there still be a working solution in TYPO3 9 LTS for the problems arising from the use of "mountpoints"?
Is there a tutorial somewhere for using mountpoints in TYPO3 9 LTS?

We also have a 40 Domain installation online with 84 Mountpoints incl. subpages.
So this is top urgent for us too.

I would also sponsor a short-term patch for that MP problem. Message me.

Christoph

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62878

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

Hi, is this patch really for TYPO3 Version 9?
Error: Class 'TYPO3\CMS\Core\Domain\Repository\PageRepository' not found

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

Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62878

Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62878

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62878

Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62878

Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62878

Patch set 9 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62878

Patch set 2 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62933

Patch set 3 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62933

Please see the 9.5 backport https://review.typo3.org/c/Packages/TYPO3.CMS/+/62933

In v10 it's included finally!

Patch set 4 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62933

Patch set 5 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62933

Patch set 6 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62933

Patch set 7 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62933

We have similar issue in our TYPO3 9 installation - and actually your last fixes does not solve our problem.

We have two different websites (separate roots) in our TYPO3 installation.

Installation 1 (pid = 0)
Installation 2 (pid = 0)

and one page which is not actual website but just 'container' which is shared across those two websites. Some of pages from shared folder are linked in Installation 1, other in Installaion 2 and some of them are used by both installations.
Shared (pid=0, uid=110)
- some page (pid = 110, uid=88)

Installation 1 and Installation 2 have it's site configuration defined.

If 'Shared' does not have site configuration defined (should it have one? since it is not real website) - then links are generated like:
domainname.com/index.php?id=88&MP=7-115
and functionality works fine - page could be opened when linked in frontend.

However if I define site configuration for 'Shared' then links in frontend are rendered with routing (example: domainname.com/some-page) but when opening a page - error is displayed
"(1/1) #1518472189 TYPO3\CMS\Core\Error\Http\PageNotFoundException
The requested page does not exist".

Gerrit Code Review wrote:

Patch set 7 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62933

Hello, as we need to upgrade (fast) our 150 TYPO3 websites using mount points, we installed the latest patch.
After somes tests, we found an issue on some pages becoming 404.

Steps to reproduce the issue :
- switch a page from "standard" to "mount point"
- set "mount_pid_ol" to 1
- switch back to standard

The page is now 404.

RVVN no-lastname-given wrote:

Gerrit Code Review wrote:

Patch set 7 for branch 9.5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/62933

Hello, as we need to upgrade (fast) our 150 TYPO3 websites using mount points, we installed the latest patch.
After somes tests, we found an issue on some pages becoming 404.

Steps to reproduce the issue :
- switch a page from "standard" to "mount point"
- set "mount_pid_ol" to 1
- switch back to standard

The page is now 404.

Thanks for the info. we've added a followup to latest 9.5 which got merged today, this issue should now be resolved as well!

Hi, we have sites with hundreds of subpages under a mountpoint. In the frontend we have now following error:

Doctrine\DBAL\Exception\DriverException

_An exception occurred while executing 'SELECT `uid`, `l10n_parent`, `pid`, `slug`, `mount_pid`, `mount_pid_ol`, `t3ver_state`, `doktype` FROM `pages` WHERE (`sys_language_uid` = ?) AND (`slug` IN (?, ?, ?, ?, ?, ?)) AND ((`pages`.`deleted` = 0) AND ((`pages`.`t3ver_state` <= 0) AND (`pages`.`pid` <> -1))) ORDER BY `slug` desc' with params [0, "\/", "\/", "\/blahblah", "\/blahblah\/", "\/blahblah", "\/blahblah\/"]: Can't create more than max_prepared_stmt_count statements (current value: 16382)

Sorry, but we also need a quick solution to the problem, because the customer has been waiting for an update for months.

Thx for your good job.

Hey Stephan,

Stephan Boiting wrote:

Hi, we have sites with hundreds of subpages under a mountpoint. In the frontend we have now following error:

Doctrine\DBAL\Exception\DriverException

_An exception occurred while executing 'SELECT `uid`, `l10n_parent`, `pid`, `slug`, `mount_pid`, `mount_pid_ol`, `t3ver_state`, `doktype` FROM `pages` WHERE (`sys_language_uid` = ?) AND (`slug` IN (?, ?, ?, ?, ?, ?)) AND ((`pages`.`deleted` = 0) AND ((`pages`.`t3ver_state` <= 0) AND (`pages`.`pid` <> -1))) ORDER BY `slug` desc' with params [0, "\/", "\/", "\/blahblah", "\/blahblah\/", "\/blahblah", "\/blahblah\/"]: Can't create more than max_prepared_stmt_count statements (current value: 16382)

Sorry, but we also need a quick solution to the problem, because the customer has been waiting for an update for months.

Thx for your good job.

What version are you running on? We now have mountpoints working across sites in TYPO3 v9.14-dev (latest 9.x-dev-branch as of today). Hope that helps.

In general MountPoint setups are hard to understand, if you don't know the scenarios, so just by taking your example, it seems like you run 9-x-dev from last week. We've fixed some other things today and yesterday in that area.

All the best,
Benni.

Currently we have version 9.5.13.

We have one main domain with many pages, subpages (four level deep) and several domains that mount the main trees with entry points.

In version 7 it works very well.
I will test it with the v9.14-dev version and hope.

Hi Benni,
did you have a chance to read my problem that I described 27.01? Do you think it can be considered as a TYPO3 bug?
As I wrote - without routing configured (parameter urls) it works fine. But when routing is configured then url leeds to "The requested page does not exist". Let me know if you need any more informations regarding that.

Benni Mack wrote:

Hey Stephan,

Stephan Boiting wrote:

Hi, we have sites with hundreds of subpages under a mountpoint. In the frontend we have now following error:

Doctrine\DBAL\Exception\DriverException

_An exception occurred while executing 'SELECT `uid`, `l10n_parent`, `pid`, `slug`, `mount_pid`, `mount_pid_ol`, `t3ver_state`, `doktype` FROM `pages` WHERE (`sys_language_uid` = ?) AND (`slug` IN (?, ?, ?, ?, ?, ?)) AND ((`pages`.`deleted` = 0) AND ((`pages`.`t3ver_state` <= 0) AND (`pages`.`pid` <> -1))) ORDER BY `slug` desc' with params [0, "\/", "\/", "\/blahblah", "\/blahblah\/", "\/blahblah", "\/blahblah\/"]: Can't create more than max_prepared_stmt_count statements (current value: 16382)

Sorry, but we also need a quick solution to the problem, because the customer has been waiting for an update for months.

Thx for your good job.

What version are you running on? We now have mountpoints working across sites in TYPO3 v9.14-dev (latest 9.x-dev-branch as of today). Hope that helps.

In general MountPoint setups are hard to understand, if you don't know the scenarios, so just by taking your example, it seems like you run 9-x-dev from last week. We've fixed some other things today and yesterday in that area.

All the best,
Benni.

Ok, problem solved.
It is necessary that all domains with mountpoints, also deactive channels, in the site configuration are completely configured, with languages etc.
Otherwise you will have problems above.

But there is a next problem: 404 error if slug name more than two times in multichannel domains (with patch https://forge.typo3.org/issues/90166)

Main Domain
- Mainpage 1
-- Subpage 1
-- Subpage 2
...

Second Domain
- Mainpage 1 (Mountpoint with mount_pid_ol from "Main Domain->Mainpage 1") ------- Status: OK (Same slug as "Main Domain->Mainpage 1")

Third Domain
- Mainpage 1 (Mountpoint with mount_pid_ol from "Main Domain->Mainpage 1") ------- Status: 404 ERROR (Same slug as "Main Domain->Mainpage 1")

...

If "Second Domain->Mainpage 1" has another slug name as "Main Domain->Mainpage 1" "Third Domain->Mainpage 1" is also Status: OK

Further information from my side - I am able to reproduce my problem on clean TYPO3 installation with introduction package installed. Related typoscript configuration that is used is:

config {
MP_mapRootPoints = root
MP_disableTypolinkClosestMPvalue = 0
content_from_pid_allowOutsideDomain = 1
typolinkEnableLinksAcrossDomains = 1
typolinkCheckRootline = 1
}

Stephan Boiting wrote:

But there is a next problem: 404 error if slug name more than two times in multichannel domains (with patch https://forge.typo3.org/issues/90166)

Main Domain
- Mainpage 1
-- Subpage 1
-- Subpage 2
...

Second Domain
- Mainpage 1 (Mountpoint with mount_pid_ol from "Main Domain->Mainpage 1") ------- Status: OK (Same slug as "Main Domain->Mainpage 1")

Third Domain
- Mainpage 1 (Mountpoint with mount_pid_ol from "Main Domain->Mainpage 1") ------- Status: 404 ERROR (Same slug as "Main Domain->Mainpage 1")

...

If "Second Domain->Mainpage 1" has another slug name as "Main Domain->Mainpage 1" "Third Domain->Mainpage 1" is also Status: OK

We also confirm the issue when testing on our sites (with patch https://forge.typo3.org/issues/90166).
The fact is that on some multi-sites instances, we have 30-40 sites referring same pages of the "Main" domain.

We also confirm that if you change the slug on each mounting point, the status is then OK.

We need a fix please please ;)