Suggestion #60517
Changing backend layout does not respect inheritance
Status: | Resolved | Start date: | 2014-07-24 | |
---|---|---|---|---|
Priority: | Won't have this time | Due date: | ||
Assigned To: | - | % Done: | 100% |
|
Category: | UI & UX | Spent time: | - | |
Target version: | - | |||
TYPO3 Version: | 6.2 | Patch is reviewed: | No | |
PHP Version: | Reporter: | |||
Has patch: | No |
Description
When I change the backend layout of a page and this backend layout has not all columns of the previous one, the AfterDatabaseOperations::setUnusedElements() method moves content items which belong to these lost columns to colPos -2.
This is not a real problem (besides the fact that this changes the default behavior of TYPO3 significantly).
But when I update the backend_layout_next_level of a parent page, which brings the lost columns back, the moved content items are still gone (colPos -2).
Is it really necessary to move items in unused columns to colPos -2?
I don't like that. The change of backend layout of pages should not change the informations of the content items.
Now conditions in backend layouts are able. What happens if I want to hide a column for a certain user group in backend but not want to hide the items in frontend?
Related issues
Associated revisions
[BUGFIX] Respect different options for layouts being not set
Since the core switches between 0 and empty as default values for
backend_layout and backend_layout_next_level we have to tackle both
Change-Id: I938283b7037fcac2886300daa61f91772d1b4aaf
Resolves: #60517
Reviewed-on: http://review.typo3.org/31770
Reviewed-by: Armin Ruediger Vieweg <armin@v.ieweg.de>
Tested-by: Armin Ruediger Vieweg <armin@v.ieweg.de>
Reviewed-by: Jo Hasenau <info@cybercraft.de>
Tested-by: Jo Hasenau <info@cybercraft.de>
History
#1 Updated by Jo Hasenau about 1 year ago
- Tracker changed from Bug to Suggestion
- Category set to UI & UX
- Status changed from New to Needs Feedback
- Priority changed from Should have to Won't have this time
They are not gone, but in colPos -2, which can be easily solved by adding that particular column to your backend layout.
This resembles the "unused elements" of TV and currently is the only way to keep the items editable somehow after changes to the backend structures of pages and/or Gridelements.
IIRC you can disable columns for certain users, but still keep the items in there, without moving them to the "unused elements" column. You have to make sure that the column as such is available, but it can either be "not assigned" or "restricted". But AFAIK there is a bug report pending, since TSconfig stuff has been removed in the core without formal deprecation.
Currently there are no plans to change that behaviour with upcoming version 3.0, but we might discuss it for later GE versions, which would be available for TYPO3 version 6.3 and later then. Since 6.2 is LTS, we should not introduce changes of behaviour or other breaking changes there.
#2 Updated by Armin Ruediger Vieweg about 1 year ago
This resembles the "unused elements" of TV and currently is the only way to keep the items editable somehow after changes to the backend structures of pages and/or Gridelements.
I understand this. But by changing the colPos to -2 you also modify the display of items in frontend. And IMO this should not happen just to make the backend more userfriendly. Instead of in gridelements I would expect such feature (which is of course very useful) in core's page module.
In list module these items are currently visible, arent't they? Maybe with "INVALID VALUE" in colPos if you edit the item, but they are still accessible.
All these little features, which changes the backend and even frontend behavior are suboptimal for gridelements, IMO.
For example the drag & drop feature (besides the fact, that it is already migrated to core): If it wouldn't be migrated I would be forced to use gridelements to have drag & drop. Even if I don't need all the other features like grids or inline wizard on pages or Insert as reference link.
This is a big complete pack, which changes the user experience for TYPO3 backend too much. It goes further away from TYPO3 standard. For me gridelements looks like the new TemplaVoila. But in a bad way, because of the way how to handle the all-included-features.
Please don't missunderstand me. I really like gridelements! Very much! But just for creating grids. Not more, not less. I don't want all the other changes. Or if I want them I would like to be able to choose eg. by installing new extensions which provides them.
Hope you get my point ^^
#3 Updated by Jo Hasenau about 1 year ago
I won't discuss options for upcoming versions on the issue tracker, since this is not related to this issue. We can do some sessions about it at one of the Camps (will be in Bremen and Essen I guess), the CON or the next DEVDAYS.
#4 Updated by Jo Hasenau about 1 year ago
Back to the issue:
Inheritance should be respected.
Take a look at line 175 ff. of Classes/DataHandler/AfterDatabaseOperations.php
It reacts on backend_layout_next_level changes and modifies subpage content recursively.
#5 Updated by Jo Hasenau about 1 year ago
Armin Ruediger Vieweg wrote:
I understand this. But by changing the colPos to -2 you also modify the display of items in frontend. And IMO this should not happen just to make the backend more userfriendly. Instead of in gridelements I would expect such feature (which is of course very useful) in core's page module.
Exactly - and the core still does NOT provide such a feature, although backend layouts have been implemented more than 4(!) years ago AND gridelements are showing at least one possible option how to deal with that problem for 3(!) years now. #22903 is pending for almost the same time. Even though it might not be your preferred solution, at least it IS a solution for these problems.
In list module these items are currently visible, arent't they? Maybe with "INVALID VALUE" in colPos if you edit the item, but they are still accessible.
So people will see lots of "invalid values" IF they got access to the list module, or they just see nothing in the page module (for example because they are not allowed to access the list module) making them think they lost their content elements. IMHO Gridelements should deal with these problems at least until there is a proper solution provided by the core.
BTW: Most of the people who are using gridelements are using backend layouts for pages and content directly connected to a certain frontend output. So they definitely WANT to change the frontend output by changing the backend structures.
#6 Updated by Armin Ruediger Vieweg about 1 year ago
Take a look at line 175 ff. of Classes/DataHandler/AfterDatabaseOperations.php
$this->getSubpagesRecursively($this->getPageUid(), $subpages);$subpages is empty.
#7 Updated by Armin Ruediger Vieweg about 1 year ago
The problem is this in the getSubpageRecurively:
if ($page['backend_layout'] === 0) {}and
if ($page['backend_layout_next_level'] === 0) {}They are not zero (=== 0), they are empty. If I replace this condition with empty(...) it works.
#8 Updated by Jo Hasenau about 1 year ago
According to this patch https://review.typo3.org/#/c/25135/ actually none of the backend layout fields should be empty anymore.
If this is still the case, we need to change that in the core.
Still it would not hurt to use empty instead of 0 in Gridelements to be on the safe side.
#9 Updated by Jo Hasenau about 1 year ago
It seems they broke it again with this one https://review.typo3.org/#/c/24882 and it has not been reverted yet. :-(
#10 Updated by Gerrit Code Review about 1 year ago
- Status changed from Needs Feedback to Under Review
Patch set 1 for branch master of project TYPO3CMS/Extensions/gridelements has been pushed to the review server.
It is available at http://review.typo3.org/31770
#11 Updated by Gerrit Code Review about 1 year ago
Patch set 1 for branch master of project TYPO3CMS/Extensions/gridelements has been pushed to the review server.
It is available at http://review.typo3.org/31771
#12 Updated by Armin Ruediger Vieweg about 1 year ago
Well, empty() will fit 0 and '' and NULL, so whatever they do, this is save :)
#13 Updated by Jo Hasenau about 1 year ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 71cf658e6c800fe36bf453f0a969756173e8c4ca.