Bug #24183
closed
Changing Page Type in Alternative Page Language Record doesn't work
0%
Description
In BE it's possible to change page type for pages_language_overlay records. But this has no effect in FE in TYPO3 4.4.4 (tested on production website and "clean" introduction package)
e.g.:
default language: page type standard
translated: page type shortcut
It's only possible to set the same page type for page and alternative_page_record and change e.g. only the shortcut to page.
In my opinion it's a frontend bug, but you can categorize it as a BE usability problem too.
(issue imported from #M16538)
Files
Updated by Jonas Renggli over 13 years ago
Relation to http://bugs.typo3.org/view.php?id=4911
doktype is evaluated in class.tslib_fe.php getPageAndRootline() before there's more language information available
Updated by 
Updated by Thorsten Kahler over 13 years ago
No benefit, just more irritation for editors.
But it should be fixed: by adding "doktype" to TYPO3_CONF_VARS.FE. pageOverlayFields in config.default.php
Updated by Jonas Renggli over 13 years ago
Patch bug_16538_v1.diff works for me. Thank you.
The problem is that be-users can choose a different doktype for alternative page records. But this field isn't evaluated by default. Therefore i see two solutions (and hope that one of them is commited to core):
- hiding the doktype field in BE
OR
- adding doktype field to pageOverlayFields
Personally I prefer the second option, because this fulfills the needs of big corporate websites with different pages and links for translations.
Updated by Andrei Semenenko over 13 years ago
Is it a good idea also to add to overlay or hide field "hidden"? It also exists in translation-related settings of page in BE, and also has no effect.
Concerning the question what is better to hide field in BE or add it to overlayed fields. What if we check the field if it is overlayed or not before show it in BE? In this way we will always have BE fields set linked to configured overlayed fields set, even if overlayed fields set will be changed by admin.
I think this is quite easy task. I tested following code on my 4.4.5 version:
I'm not familiar with diff files, sorry;)
I've just changed line 725 in file typo3\sysext\cms\tbl_cms.php
So that it became:
'3' => array('showitem' => ((in_array('doktype', $fieldArr)) ? 'doktype' : '').';;;;1-1-1, '.((in_array('hidden', $fieldArr)) ? 'hidden, ' : '').'sys_language_uid, title...
Instead of:
'3' => array('showitem' => 'doktype;;;;1-1-1, hidden, sys_language_uid, title...
And I made config string explosion a bit earlier, on line 513:
$fieldArr = explode(',', $GLOBALS['TYPO3_CONF_VARS']['FE']['pageOverlayFields']);
I think this solution can be extended to all other page types, and some other page fields.
Updated by Andreas Kiessling over 13 years ago
The patch seems to work. If you don't want to modify your sources, you can also put this line in your localconf.php:
$GLOBALS['TYPO3_CONF_VARS']['FE']['pageOverlayFields'] .= ',doktype';
The patch should go into 4.5, but i fear the change would be too big for 4.4 / 4.3, although it is definitely a bug.
Since the doktype from pages_language_overlay was not respected, i fear a lot of editors did not care about that setting. templavoila also did not copy the doktype field (up to version 1.5.1) when a localization was initialized from the page module, so there will be quite some pages with wrong doktype setting out there.
Updated by Jonas Renggli over 13 years ago
@Andrei: From usability sight your solution would be great. It doesn't matter what's configured, the system would take care that the config is consistent. But I doubt that the TCA default config file is the right place to put in a lot of conditions. This way code will get quite unreadable.
Updated by Jonas Renggli over 13 years ago
I see your problem of "changed behavior". Can't we write an update script for the update wizard, which checks $GLOBALS['TYPO3_CONF_VARS']['FE']['pageOverlayFields'] and copies the doktype value from pages to pages_language_overlay?
Therby existing content still works and when making new translations of a page the doktype is copied anyway.
Updated by Andreas Kiessling over 13 years ago
@Jonas: Yes, that would be the best solution. Problem could still be Templavoila < 1.5.1, which creates new records in pages_language_overlay with default doktype (unless you change it manually). Also editors need to be aware of that change, probably access for the field doktype needs to be adjusted.
Updated by Stefan Neufeind about 13 years ago
Tried this with 4.5.2. I can add the "doktype" to pageOverlayfields just fine, but in class.tslib_fe.php, function getPageAndRootline() there still appears the original page and not it's overlay-version. So the page-type (shortcut for example) seems to be evaluated against the main doktype, and not the alternative language one.
After the first line
$this->page = ...
tried adding
$this->initTemplate();
$this->getConfigArray();
$this->settingLanguage();
where in settingLanguage() the overlay would get loaded. However that fails since no TypoScript-template is yet loaded at this point.
Can somebody please confirm this patch (adding doktype to pageOverlayFields) still works the same way in 4.5.2? Where would the overlay-page get loaded (before getPageAndRootline)?
Updated by Bernd Wilke almost 13 years ago
- File patch_24183_part.diff patch_24183_part.diff added
Just another step to the correct handling:
I tested on 4.5.2 with the problem:
- In default-language a page is shortcut (doktype = 4)
- Translated it should be default-type (=just show content from page) (doktype = 1)
by default the shortcut is executed also in the translation, even after point 1:
1. As doktype does not belong to the pageOverlayFields ($TYPO3_CONF_VARS['FE']['pageOverlayFields']) by default you have to set this in the install-tool
(no core-patch needed!!! not all fields of pageoverlay-records are transfered by default)
2. If you have a page with doktype = 4 (shortcut), you can define another shortcut-target for translated pages.
The check for another target is done in the method tslib_fe::checkTranslatedShortcut(), where the shortcut already was 'executed' and the actual page is the shortcut-target of default-language. if the target is another one, the target-page is calculated anew.
Here I add a check on the overlaydata of the original(!) record for doktype other than shortcut.
If that overlay was no shortcut at all, I reload the page (and rootline) as it is done for shortcut-pages with another target.
(lines 2445-2454)
3. while doing this reload of page (and rootline) the local variable $this->sys_page (class t3lib_pageSelect) is initialized anew, which includes the destroing of information about another language.
I set the language immediate after makeInstance() (line 891)
on the first run there is no information about another language, but afterwards.
By this all selected pages get immediate overlay handling and the page is recognized as default instead of shortcut.
4. in settingLanguage() I set language-information for $this->sys_page as early as possible. (line 2293)
Drawbacks:
1. somewhere a cache is done outside this handling.
If a FE-user calls the target-shortcut of the default-language in the translated language this page is handled like the shortcut in default-language
(Question: is this also done for translated shortcuts?)
Solution: before changing the page (in the default-language) to shortcut-mode, set the no_cache-flag for this page (this field is not available for pages with doktype shortcut)
2. this is no solution for the problem:
- in default language the page is doktype default
- translated it is a shortcut
=> language-independend the content of the page is shown, no shortcut!
Updated by Mathias Schreiber over 9 years ago
- Description updated (diff)
- Category deleted (
Communication) - Target version changed from 0 to 7.2 (Frontend)
- Is Regression set to No
Updated by Stefan Neufeind over 9 years ago
Hiding the field in a translated version would imho be the best quick option, since it doesn't work anyway. Afaik you'll be able to have a shortcut point to a different target in the translation (is that right?) but only use the same type as you have in the original version.
If we'd really want to for example have a page in the default-language and a shortcut in the translated version, I fear we'll need to do overlaying quite some steps earlier before checking the page-type. But then we'd end up overlaying it again and again later on if we want to correctly catch it in all places. Am I right?
Updated by Benni Mack almost 9 years ago
- Target version changed from 7.2 (Frontend) to 7.4 (Backend)
Updated by Bernd Wilke almost 9 years ago
just stumbled again upon this ticket by random.
we have a big installation where we use different pagetypes for some translated pages: in default language there is content, in the translation it is an forwarding realized as "external Url" as there are some URL-Parameters included.
AS the whole content is transfered to static pages no redirect would resolve so I have to change the menu-rendering to resolve URLs on menu generation. this might be neccessary for link generation for every kind of 'forwarding' page.
Updated by Susanne Moog over 8 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Benni Mack over 8 years ago
- Target version changed from 7.5 to 7 LTS
Updated by Mathias Schreiber over 8 years ago
- Status changed from Accepted to Closed
This is not how a translation should work.
A translation is a direct descendant of its parent record and should change content, not functionality.
Updated by Stefan Neufeind over 8 years ago
@Mattes: Then why are those fields changeable in the translated version? Tested on current master.
Updated by Benjamin Robinson over 8 years ago
@Mathias: why did you close this ticket? The pagetype of translations is still changeable in 7 LTS.
Updated by Markus Mächler Mächler over 6 years ago
Those fields should not be changeable if that is not how translations work in TYPO3. But in my opinion that is definitely something I would expect to work as an editor, regardless of whether that violates some design principle. Those principles are tools that should make a developer's life easier and not something you have to obey by law.
Please reopen this issue, TYPO3 users all over the world lose their time because they have to research and deal with this issue since years.