Bug #60199
closedPage module: tt_content records are not editable
100%
Description
This problem was introduced with 6.2.4:
When trying to edit a tt_content record in the page module that has sys_language_uid > 0 but no l18n_parent, TYPO3 shows "Sorry, you didn't have proper permissions to perform this change." even es admin.
You can edit the same record via the list module.
Switched back to 6.2.3: the record is editable.
Set a l18n_parent: the record is editable.
I narrowed the problem down to the url that is requested when you click the edit icon, the uid in the edit parameter is missing:
Without i18n_parent: "edit[tt_content][]=edit"
With i18n_parent: "edit[tt_content][2766,]=edit"
Where 2766 is the uid of the tested record in my case.
I think this problem may was introduced with the following commit:
https://github.com/TYPO3/TYPO3.CMS/commit/f746410ad1016b8afaf2a033ad8577303e9bcb21#diff-48b710d2dff23d6dddca0c9e2951fe1b
The record uids used to generate the edit urls are generated by the code changed with this commit.
Files
Updated by Robert Heinig over 10 years ago
This was a gridelements issue:
http://forge.typo3.org/issues/60194
Sorry, this issue here can be closed.
Updated by Robert Heinig over 10 years ago
With the gridlements-Fix this problem was only partially solved.
I uninstalled gridelements and I´m still experiencing this error in page module mode "languages" - it works in "columns" mode.
Updated by Teamgeist Medien over 10 years ago
Currently having the same problem. Even without gridelements the error still occurs in the language module, when clicking the edit icon. Directly clicking on an element oder rightclick and then "edit" does not show up this error.
Updated by Christian Hernmarck over 10 years ago
The problem also occurs in 4.5.35 - so it's not (or not only) related to something from version 6.*
As stated in other issues:
- page view
- also use the edit icon and not just click in the text to edit
- then you see that only the first content in a column works - the other bring up the message...
And in the source it's obvious (as stated above) - just look for "edit[tt_content]"...
link from edit icon (not first):
<a href="#" onclick="window.location.href='../../../alt_doc.php?returnUrl=%2Ftypo3%2Fsysext%2Fcms%2Flayout%2Fdb_layout.php%3Fid%3D5&edit[tt_content][]=edit'; return false;" title="Bearbeiten">
link when clicking in the content to edit:
<a href="#" onclick="window.location.href='../../../alt_doc.php?returnUrl=%2Ftypo3%2Fsysext%2Fcms%2Flayout%2Fdb_layout.php%3Fid%3D5&edit[tt_content]15=edit'; return false;" title="Bearbeiten">
so the content-id is missing here.
version 4.5.34 works.
And: with multilanguage pages it also works...
Updated by Christian Hernmarck over 10 years ago
Sorry
Seems not to be that easy. I checked several sites and the problem only occurs with one site (I'm currecntly working on).
So I try to find the probem - maybe the "multicolumn" extension is not compatible to 4.5.35... ??
Updated by Christian Hernmarck over 10 years ago
For now it really seems to be a problem in the multicolumn extension.
The content-elements after the first multicolumn-content seem to be affected...
I'll look further with this extension since I still use 4.5 the movement to gridelements is not an alternative...
Updated by Markus Klein over 10 years ago
- Status changed from New to Needs Feedback
Updated by Christian Hernmarck over 10 years ago
I have an Update...
in my case thee problem is related to multicolumn - but maybe also with other extensions which are using the hooks to draw backend items.
I did alot of debugging (because I don't know the structure/code inside typo3 very well) and came to this conclusion:
multicolumn uses this hook:
class tx_multicolumn_tt_content_drawItem_pre60 extends tx_multicolumn_tt_content_drawItem_base implements tx_cms_layout_tt_content_drawItemHook
and therefore is called in tt_content_drawItem in the original class.tx_cms_layout.php.
The problem is that "$this->tt_contentData" is different after calling the hook than before it was (the whole object is called via the hook and then $this->tt_contentData changes).
That's why the edit-icons (and btw. also the "move-up" and "move-down" icons) are not ok (or not there) after the first multicolumn (or other external) content element.
Saving the data helps:
$safeData = $this->tt_contentData; # safe the data
$hookObject->preProcess($this, $drawItem, $outHeader, $out, $row); # this line is in the code...
$this->tt_contentData = $safeData; # restore the data
with this two additional lines there it seems that everything is as it should.
So far it seems not to be a problem of a certain extension.
Maybe some others can check and give some feedback?
Updated by Markus Klein over 10 years ago
Hi thanks for your endurance. The question does the hookObject do with the tt_contentData? I guess it does modify those data on purpose.
Please check the called hook which is called.
Adding the code you proposed would mean to break all extensions using this hook to modify tt_contentData on purpose.
Updated by Christian Hernmarck over 10 years ago
Hi
ok, I think I can give some hints...
In the hook functions (file hook/class.tx_multicolumn_tt_content_drawItem.php in multicolumn) there is a function buildColumnContentElements which calls tx_multicolumn_db::getContentElementsFromContainer which does the call $cmsLayout->getResult($res, 'tt_content', 1);
And there were made some changes concerning the content of "tt_contentData"...
Obviously the original object is changed.. becaous it's always referenced as reference...
(original) tx_cms_layout:
$hookObject->preProcess($this, $drawItem, $outHeader, $out, $row);
(multicolumn) class.tx_multicolumn_tt_content_drawItem.php:
public function preProcess(tx_cms_layout &$parentObject, &$drawItem, &$headerContent, &$itemContent, array &$row) {
parent::preProcess_base($parentObject, $drawItem, $headerContent, $itemContent, $row);
}
Now I don't know if it's allowed to change the parent-object or not..., or to call functions of the parent object which change data inside the object permanently...
Updated by Christian Hernmarck over 10 years ago
addendum..:
until 4.5.34 there was no problem - the tt_contentData was not "zeroed"
removing/commenting the block
$this->tt_contentData = array(
'nextThree' =>array(),
'next' => array(),
'prev' => array(),
);
in function "generateTtContentDataArray" has also a positive effect...
Updated by Markus Klein over 10 years ago
What do you mean with "was not zeroed".
Now the data is properly initialized. Does the hook rely on some "dirty" data?
Updated by Christian Hernmarck over 10 years ago
Since 4.5.35 the array tt_contentData is initialized not only in the class definition but also with every call of the function "generateTtContentDataArray" - which is at least when getResult is called but also in getTable.
In 4.5.34 the values only changed in function getResult.
Now it's not easy for an "external" like me to see where the problem is. Is there some sort of funtional by chance and now it stopped or is it a conceptional problem or what...
I think if an axtension like multicolumn also uses the parental class "cmsLayout" to do some "next level display thing" then it should not happen that important values are changed...
Since this bug also concerned "gridelements" in >= 6 and the solution looks like this
https://forge.typo3.org/projects/extension-gridelements2/repository/revisions/b6813310fc0bc1dc9e8d6900557fbd461c4f1115
I think we have to save the data inside the extension....
... maybe other extensions might follow... or maybe not...
Updated by Markus Klein over 10 years ago
- Status changed from Needs Feedback to Accepted
- Is Regression changed from No to Yes
Thanks for the detailed analysis. I'm asking some of the authors of the original patch for their opinions.
Updated by Jigal van Hemert over 10 years ago
- Status changed from Accepted to Rejected
The fix that "caused" this problem was required to correct the behaviour of moving content elements in various situations. Unfortunately this changed the behaviour of internal variables. These internal variables and functions should not have public, but in old versions of the core everything was public by default.
As far as I can determine the only extension that currently has a problem with this change is "multicolumn". The author has marked it as 'obsolete'.
Although existing installations with multicolumn may show a regression it's not really worth it, nor correct to revert a bugfix which was really necessary to fix the behaviour of an obsolete extension.
After careful consideration and discussion this bug report is closed as "Rejected".
Updated by Christian Hernmarck over 10 years ago
Hi
I can live with this decision - I've spend so much time to dig into this that I also can fix it in the extension...
Just one thing: the extension did/does not write/read the variable directly, the difference from 4.5.34 to 4.5.35 is: the tt_contentData is now initialized (zeroed) with every call of getResult (in 4.5.34 there were only changes made in getResult).
Every extension which uses the class cmsLayout in a "nested way" may be affected by this change.
"gridelements" also had this problem (#60194)... so you never know if there are more.
multicolumn needs to be fixed for all < 6 installations.... - I'll contact the devs...
Updated by Wolfgang Klinger over 10 years ago
I can still confirm that this is a core bug in the 'Languages' view with TYPO3 6.2.4,
it works with and without the gridelements extension with TYPO3 6.2.3
so why has this been closed?
You ignored all the positive bug reports:
-------------------
Updated by Robert Heinig 19 days ago
With the gridlements-Fix this problem was only partially solved.
I uninstalled gridelements and I´m still experiencing this error in page module mode "languages" - it works in "columns" mode.
#4 Updated by Teamgeist Medien 18 days ago
Currently having the same problem. Even without gridelements the error still occurs in the language module, when clicking the edit icon. Directly clicking on an element oder rightclick and then "edit" does not show up this error.
Updated by Jigal van Hemert over 10 years ago
- Status changed from Rejected to Needs Feedback
Set to "Needs Feedback" to follow up with this issue.
We didn't ignore any comments, but later comments pointed to the extension "multicolumn". This extension has been declared 'obsolete' by the author.
In a clean install I haven't been able to see the effect described in the report. On a page with two content elements (text) which only exist in the secondary language every possibility to edit it (context menu, click on text, edit icon) works, saving works in all cases. I moved the content elements around and tried editing them, works also. In the language view it doesn't matter which language I select, editing content elements works.
Could you provide details to reproduce the problem?
- which third party extensions are installed? Are there extensions among them which modify the page module or provide new content elements?
- what is on the page, which module is used, which languages are present, which steps need to be taken to see the problem?
- anything else that can help to reproduce
Updated by Wolfgang Klinger over 10 years ago
I tried it in an empty installation (only system extensions installed, no setup, cleared all caches through the Install Tool) and it simply does not work, sorry …
TYPO3 6.2.3 source -> OK
TYPO3 6.2.4 source -> error message
I created a website language English,
created a translated page,
Web > Page > Languages (Default and English next to each other),
created a content element in the new language (no relation to default language content)
and tried to edit it with the pencil icon in the header section of the element
bumm
Sorry, you didn't have proper permissions to perform this change.
URL: /typo3/alt_doc.php?returnUrl=%2Ftypo3%2Fsysext%2Fcms%2Flayout%2Fdb_layout.php%3Fid%3D1%23element-tt_content-4&edit[tt_content][]=edit
Updated by Christian Hernmarck over 10 years ago
- File typo3-60199.png typo3-60199.png added
I can confirm this:
- 6.2.4
- default lang plus another language
- page/language view
- independant content (not "translated" content)
-> problem occurs.
With several content - one independant and others containing translations of default-language-content then the translated contents are normal, the independant content shows the probem.
Problem is:
- edit icon does not work (no id in parameter... "...edit[tt_content][]=edit...")
- moveup/down icons are not there....
in list view or page/columns the problem does not occur...
See screenshot - since ost icons only show up with mouseover it's not easy to show... :-)
The translated contents (above and below the independant content) do show the moveup/down icons.
Updated by Markus Klein over 10 years ago
- Status changed from Needs Feedback to Accepted
Updated by Christian Hernmarck over 10 years ago
Just a note: With 4.5.(.35) I could not reproduce the error.
Updated by Jigal van Hemert over 10 years ago
Thanks for the description and the screenshot! The essential part was having translated elements (with a 'parent' element) combined with elements without a counterpart in the original language. Now it's possible to investigate and hopefully fix it soon.
Updated by Christian Hernmarck over 10 years ago
More digging....
The difference to 4.5.35 is at least when calling tt_content_drawHeader (which draws the icons we discuss here) the structure tt_contentData is different. In 4.5.35 the structure always contains all uids of a column, in 6.2.4 the structure seems to miss the uids of unique foreign language elements (content elements in non-default language which have l18n_parent = 0).
Updated by Jigal van Hemert over 10 years ago
- Category set to Backend User Interface
- Assignee set to Jigal van Hemert
- Complexity set to hard
Debug session planned for tonight.
Updated by Markus Klein over 10 years ago
New report #60702 seems to be related.
Updated by Gerrit Code Review over 10 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/31929
Updated by Markus Klein over 10 years ago
We kindly ask everybody watching this issue to test the solution pushed to the review system.
Thanks for your feedback!
Updated by Gerrit Code Review over 10 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/31929
Updated by Gerwin Kramer over 10 years ago
The provided fix works for me. Content elements after a multicolumn element are editable again in the Page module when I use the pencil on the right. Thanks!
Updated by Jigal van Hemert over 10 years ago
@Gerwin Kramer: Can you review at https://review.typo3.org/31929 please? (Log in with your t3o username/password and use the "Reply" button on the top). Especially reviews by testing are valuable.
Updated by Christian Hernmarck over 10 years ago
btw:
if the same fix is applied also for 4.5.35 (in class.tx_cms_layout.php - line 2268) then there's no need for the ext "multicolumn" to change anything...
Since tt_contentData is initialized at the class-initialization there's no need to reinitialize it - except if the variable has been removed by another (external) program.
Now the behaviour is like before - the variable (array) never gets smaller - only larger...
I don't know the exact use of the array (when is it useful to change it etc) - so it's up to the developer to know the right way :-)
Updated by Gerrit Code Review over 10 years ago
Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32326
Updated by Gerrit Code Review over 10 years ago
Patch set 1 for branch TYPO3_6-1 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32327
Updated by Gerrit Code Review over 10 years ago
Patch set 1 for branch TYPO3_6-0 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32328
Updated by Gerrit Code Review over 10 years ago
Patch set 1 for branch TYPO3_4-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32329
Updated by Gerrit Code Review over 10 years ago
Patch set 1 for branch TYPO3_4-5 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/32330
Updated by Jigal van Hemert over 10 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 9ec2eaf6ef89a9c112022047ebed1ac48c08b89b.