8000 Bugfix/4012 Correct closest page with template in rootline logic and refactor repository by wazum · Pull Request #4355 · TYPO3-Solr/ext-solr · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Bugfix/4012 Correct closest page with template in rootline logic and refactor repository #4355

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

wazum
Copy link
@wazum wazum commented May 8, 2025

What this PR does

This PR addresses issue #4012 by:

Correcting the logic for finding the closest page with an active system template within a given rootline.
* Ensured that the rootline data provided to the SystemTemplateRepository is interpreted correctly (root page first, current page last).
* Verified that the sorting logic correctly identifies the template on the current page or its nearest ancestor as the "closest".
* Updated unit tests to reflect the correct rootline structure and expected outcomes.

How to test

  1. Verify that the integration tests in SystemTemplateRepositoryTest.php pass.
  2. Manually test scenarios where a TYPO3 page tree has system templates on various levels of the rootline. Ensure that the system correctly identifies the template from the closest parent page in the rootline that has a template.
    • Example:
      • Root Page (no template)
        • Level 1 Page (no template)
          • Level 2 Page (has template A)
            • Current Page (has template B) -> Template B should be found.
      • Root Page (no template)
        • Level 1 Page (has template C)
          • Level 2 Page (no template)
            • Current Page (no template) -> Template C should be found.

Fixes: #4012

@dkd-kaehm
Copy link
Collaborator
dkd-kaehm commented May 8, 2025

The example in that pull-requiest is not the same as in issue, it is reversed(roots without templates in top and no-roots with templates on bottom).

To your issue, which should work currently without changes:
EXT:solr relies and uses the is_siteroot PIDs everywhere(beginning by tx_solr_indexqueue_item) and tries to initialize the TSFE to use the TypoScript, so the last chain link with TypoScript must always be the is_siteroot-Page with template.

EXT:solr requires a root page with template to work at all.
So you can assign a "empty or small" template to each of your micro-sites(whose root pages are marked as is_siteroot) and apply a whole TypoScript on some shared parent-page(try as non-root first, and if it works don't switch to is_siteroot because of #4353)

@wazum Please try the suggestion without your change and with.

@wazum
Copy link
Author
wazum commented May 8, 2025

Hm, that's exactly my problem as described in the issue:

I noticed the behaviour when I initialized the queue for a site that is inside another one (microsite). Also the outer site is inside a page that holds a sys_template record (not a site itself, just a page to hold TypoScript defaults for a number of sites).

  • the container on top has a template (with general settings for all microsites/tenants) and no "Use as Root Page" set
  • all microsites/tenants have a template and have "Use as Root Page" set (they are associated with a site/domain)

And this is solved with this pull request.
If you take a look at the original code, you see the problem instantly … it's just a query for all pages with a template and then returns any randomly (and not the one that is closest).
Please explain what is unclear or what you need to understand the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] ConfigurationPageResolver::getClosestPageIdWithActiveTemplate relies on IN() to force a sort order (which it does not) [WITH FIX]
2 participants
0