Project

General

Profile

Actions

Bug #95688

closed

Storage folder outside of page tree does not allow translations

Added by Tizian Schmidlin about 3 years ago. Updated 5 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Site Handling, Site Sets & Routing
Start date:
2021-10-18
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
10
PHP Version:
7.4
Tags:
pending-close
Complexity:
Is Regression:
Sprint Focus:

Description

I've recently ran into an issue regarding translation on storage folders that are located outside of the main page trees where I was in some cases unable to translate the folder itself or create new translations for records situated inside of this folder.

Linux
PHP 7.4
TYPO3 10.4.20 + 10.4.21

The LocalConfiguration.php defines all available languages and moving the folder inside on of the page trees allows me to properly translate the folder and its contained records.

Comparing this to a copy of the same system with an earlier version of TYPO3 (10.4.17) I see that this works as I'd expect it. I've copied the configuration and the database from the 10.4.20 system to the 10.4.17 system and the behaviour stays as expected in the 10.4.17 version, so I guess there is something wrong there.

I've not started any further investigations in what might be the issue yet, but I'll go down that rabbit-hole this afternoon.

Actions #1

Updated by Tizian Schmidlin about 3 years ago

Well, that was faster than expected. Show diff from 10.4.17 to 10.4.20

Looking into the TranslationConfigurationProvider class explains why this does not behave in the same way as before:

Show code exerpt

Outside of a valid page tree, no languages are available, except if we are on page 0. Now this should probably be the same behaviour for the NullSite as well (at least IMHO, since anything else would break previous behaviour, even though the previous version was the buggy behaviour to begin with).

As far as I can see, there is no proper way to solve this:
  • either we have code duplication, because we have to add the logic for $pageId === 0 to replace the code from the catch
  • or we use the logic from $pageId === 0 inside the catch and try to create a Site object, but then we use Exceptions to handle logic, which is a huge code smell

I'm willing to provide a patch for both possibilities, if there is interest and this is really not the intended behaviour, if it turns out that this works as intended and my workflow is wrong, I'll keep the patch for myself :-)

Any thoughts?

Actions #2

Updated by Oliver Hader about 3 years ago

  • Category changed from Backend User Interface to Site Handling, Site Sets & Routing
Actions #3

Updated by Benni Mack almost 3 years ago

  • Status changed from New to Needs Feedback

IMHO all pages should have a site configuration, as "0" is merely a result of things like sys_category or sys_file_metadata, which could reside on "0". Otherwise it is much useful to exactly define the languages available for a site (= storage folder). Why? Because one might have different default language IDs for different page trees (yes, this concept existed also in prior versions and had always been a flaw). The only real solution is to define languages per page tree root.

Actions #4

Updated by Oliver Hader about 2 years ago

  • Tags set to pending-close

I think we can close this one, can't we? A real solution would require a unique assignment like using locales.

Actions #5

Updated by Georg Ringer 5 months ago

  • Status changed from Needs Feedback to Closed

closing as suggested. feel free to contact me on slack if you don't agree

Actions

Also available in: Atom PDF