Bug #91223
closed
Content element sorting is broken in the page module
Added by Michell Kalb over 4 years ago. Updated about 3 years ago.
100%
Description
Page module in the backend doesent respect the order/sorting of the content elements if a backend layout with multiple rows is used.
Changing the order via drag and drop is working as long as i dont reload. Once i reload i see the old ordering by uid in the backend but its working in frontend. This doesent happens without a custom backend layout.
- Install a fresh version of TYPO3 10.4.0
- Create some content elements in the backend (ordering is working now)
- Create a backend layout with 2 rows (see below)
- Try to rearrange the content elements
- Reload the frame/click on page and you see the old ordering by creation date/uid
Here is the backend layout i used:
mod.web_layout.BackendLayouts {
exampleKey {
title = Example
icon = EXT:example_extension/Resources/Public/Images/BackendLayouts/default.gif
config {
backend_layout {
colCount = 1
rowCount = 2
rows {
1 {
columns {
1 {
name = 0x0
colPos = 1
}
}
}
2 {
columns {
1 {
name = 0x1
colPos = 0
}
}
}
}
}
}
}
}
Files
| bug.png (121 KB) bug.png | Martin Weymayer, 2020-05-11 09:33 | ||
| Screenshot_20200807_163448.png (11.7 KB) Screenshot_20200807_163448.png | Jonas Eberle, 2020-08-07 16:35 |
Updated by Georg Ringer over 4 years ago
- Status changed from New to Needs Feedback
Thanks for your report! Which type of page module are you using? You can check that in Install Tool > Settings > Feature toggles > Fluid based page module > Is this enabled or disabled?
If it is enabled, can you please check if it works if it is disabled which uses then the "classic page module."
Updated by Michell Kalb over 4 years ago
Georg Ringer wrote:
Thanks for your report! Which type of page module are you using? You can check that in Install Tool > Settings > Feature toggles > Fluid based page module > Is this enabled or disabled?
If it is enabled, can you please check if it works if it is disabled which uses then the "classic page module."
It appears in both modes. Changing to classic doesent fix it but currently im using the new one.
Looks like this issue disappears at a certain amount of CEs. With one CE in col 1 and two CEs in col 0 the sorting isnt working but now i have about seven CEs in col 0 and its working...strange.
Updated by Sven Wiener over 4 years ago
Got the same Issue at TYPO3 10.4.1 in both modes, even if I use only one column.
Updated by Oliver Pfaff over 4 years ago
TYPO3: 10.4.1
Fluid based page module
PHP 7.3.12
I got the same bug. The output on the frontend side differs from that what we see in the module, but the frontend ordering respects the ordering saved in the DB. After the bug occurs, the ordering can't be changed anymore through the module and no change will be applied in the db .
Updated by Alessandro Schmitz over 4 years ago
Same issue for me.
Probably another useful information:
Creating a menu through a MenuProcessor for all content elements of the current page (e.g. for one pagers and so), the order in the menu differs from the order in the content.
Example:
Menu:
News - About us - Contact
Content:
1. Contact
2. News
3. About us
Updated by Sven Wiener over 4 years ago
In the case of Contentelements:
Even if the ordering is changed via drag and drop, the sorting in the db is changed correctly. Just the output in the BE-view is wrong. I got two reloads in that view. first the output is correct and after a second reload it is sorted back by uid.
Updated by Martin Weymayer over 4 years ago
- Priority changed from Should have to Must have
I have same problem in 10.4.1. Sorting in list view in backend is correct, also frontend rendering has correct sorting. only sorting in page view in backend is wrong. Strange is, that in subpages sorting seems working correct, only on root page sorting is wrong.
Updated by Martin Weymayer over 4 years ago
Hm ... this is realy strange ... I now changed some deleted elements in database (set visible and changed page id) and suddenly sorting is correct. I had same behaviour yesterday and after some other changes sorting was broken again???
Updated by Martin Weymayer over 4 years ago
realy, realy strange. I found out, that certain content elements break sorting. On screenshot - if I change marked element form page id 99 to 1, sorting is broken on page with id 1 in backend. change it to any other pid, sorting on page with id 1 in backend is correct. So I think the bug is concerning number of elements or/and number of sorting of certain elements?
I tried this also on other content elements. f.e. content element with id 9 -> change from pid 3 to pid 1 sorting is broken. change it back from 1 to 3 sorting is correct.
number of sorting in db seems also a little bit strange. 1,2,4,8 ... - normaly the numbers are higher, aren't they?
Updated by Martin Weymayer over 4 years ago
... it seems to be some combination with the number of content elements of page. In my case, if I have 16 or more content elments active, sorting is broken. 15 elements -> sorting is ok. But I do not know what it is depending. Because yesterday when see bug first time, there where only about 8 elements active and sorting was broken also.
Updated by Martin Weymayer over 4 years ago
I am not sure, if my hack is fine, but adding sorting in query builder seems to fix my problem. In file typo3/sysext/backend/Classes/View/BackendLayout/ContentFetcher.php I added in line 210 ->orderBy('sorting');
..
$queryBuilder
->select(...$fields)
->from('tt_content')
->orderBy('sorting');
$queryBuilder->andWhere(
...
Updated by Peter Bünemann over 4 years ago
I have an empty, new 10.4.1 installation. Sorting does not work in the page module. After adding "orderBy('sorting');" it works. After installation and activation of "gridelements" it does not work again. I created a simple single-column gridelement. All content elements moved into the grid. Sorting works within the grid. All content elements moved out of the grid again. Sorting does not work
Updated by
Updated by Jo Hasenau over 4 years ago
- Subject changed from Using backend layouts breaks content element sorting in backend to Content element sorting is broken in the page module
- Assignee set to Jo Hasenau
- Target version set to next-patchlevel
- PHP Version deleted (
7.3) - Complexity set to easy
- Is Regression set to Yes
You don't need to assign a backend layout at all, since the bug already appears with a completely fresh install.
Using D&D on a single page containing 3 default header elements in the normal column of the default layout you will get the correct sorting values in the DB but those are ignored by the page module view as soon as you reload.
Frontend works fine, so the bug is related to the page module only.
Happens with both, legacy and fluid based page module.
Updated by Jo Hasenau over 4 years ago
This seems to have been the regression for the legacy PageLayoutView, since the whole $addSorting section has been removed.
Later on the parameter was removed from the method parameters too, but sorting has not been reimplemented yet.
if ($addSorting) {
if ($this->sortField && in_array($this->sortField, $this->makeFieldList($table))) {
$queryBuilder->orderBy($this->sortField, $this->sortRev ? 'DESC' : 'ASC');
} else {
$orderBy = $GLOBALS['TCA'][$table]['ctrl']['sortby'] ?: $GLOBALS['TCA'][$table]['ctrl']['default_sortby'];
$orderBys = QueryHelper::parseOrderBy((string)$orderBy);
foreach ($orderBys as $orderBy) {
$queryBuilder->addOrderBy($orderBy[0], $orderBy[1]);
}
}
}
Since the ContentFetcher class has been created for the first time after that patch, the sorting part is missing in there too, because it was unknown to the team working on it, that the former $addSorting parameter did not exist anymore.
Updated by Gerrit Code Review over 4 years ago
- Status changed from Needs Feedback 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 https://review.typo3.org/c/Packages/TYPO3.CMS/+/64567
Updated by Gerrit Code Review over 4 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64567
Updated by Gerrit Code Review over 4 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64567
Updated by Jo Hasenau over 4 years ago
- Related to Bug #90235: Page module allows to break content of subpages added
Updated by Julian Stock over 4 years ago
I don't know if this is only a gridelements related problem which we're using on our pages, but if that's not the case, then I realized this unexpected behaviour in TYPO3 v9.5.17 & 9.5.18, too.
- We're placing a header and a text element inside a gridelement in a workspace environment (not PROD) and check this in the frontend: everything is looking fine.
- Then we're changing the order of the two elements via drag and drop: text first, header second. For a short time everything is looking like expected, then there's the autoreload and after that the ordering is the same as before (header first, text second). But in the frontend is the text first, header second.
Can anyone reproduce that behaviour? When NOT using a workspace, everything is working fine.
Update: The same is happening on TYPO3 v8.7.30 (& gridelements v8.5.2).
Updated by Peter Bünemann over 4 years ago
New TYPO3 version 10.4.4 LTS but the same problem. Sorting in the page module not possible. Version 10 is not usable at the moment.
Updated by Felix Holler over 4 years ago
The Same for me with TYPO3 10.4.4 together with gridelements version 10 and new_bootstrap_gridelements version 10. Ordering in page module is broken. You can reorder CEs but the visual Feedback is wrong.
The Patch (https://review.typo3.org/c/Packages/TYPO3.CMS/+/64567) is working fine. Thanks to all that worked on this patch!
Updated by Martin Weymayer over 4 years ago
Still problems in 10.4.4 with sorting. Gridelements and Mask installed.
Updated by Andre Koller over 4 years ago
Same here. Typo3 10.4.4, Mask 5.0.0, Gridelements 10.0.0
Updated by Markus Slaby over 4 years ago
Same problem here with TYPO3 10.4.4, gridelements and mask - but the Bugfix Jo presents seems to work for me
Updated by David Bascom over 4 years ago
Same problem still exists unter Typo3 10.4.5 - no matter which feature is selected. Using gridelements in v10 and normal tt_content-Elements. Typo3 unusable for the client at the moment. The patch mentioned above solves the problem! THX.
Updated by Gerrit Code Review over 4 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64567
Updated by Gerrit Code Review over 4 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64567
Updated by Jonas Eberle over 4 years ago
This was fixed for us in 10.4.6 (Non-Fluid based page module, PHP 7.3, MySQL 5.6) after re-creating the index tt_content.parent via DB analyzer (it was parent(pid, deleted, hidden) before). It seems to have been there forever https://github.com/TYPO3/TYPO3.CMS/blame/master/typo3/sysext/frontend/ext_tables.sql#L143 ; No idea why it shows up suddenly as being changed... I'll just leave that here - maybe this helps others, too while waiting for the patch?
Updated by Thomas Anders over 4 years ago
Recreation of the index didnt work for me in 10.4.6. The elements still jumps back after reload.
Updated by Stephan grass over 4 years ago
Same here in 10.4.6. The elements jumps back after reload. No chance to sort CE's in the page module.
Updated by Grégory Duchesnes over 4 years ago
same here with a fresh install of 10.4.6 and a clean index
Updated by Kim Christiansen about 4 years ago
Same with TYPO3 10.4.6 and PHP 7.4.2, no gridelements but with Container Extension.
If i add a new Content Element on the top of the Page, the Content Element will be ordered to the bottom of the page - but only in the Backend Page view.
Updated by Gerrit Code Review about 4 years ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64567
Updated by Gerrit Code Review about 4 years ago
Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64567
Updated by Gerrit Code Review about 4 years ago
Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/64567
Updated by Gerrit Code Review about 4 years ago
Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65427
Updated by Jo Hasenau about 4 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 0260f92c2a279ca0ab890e9dac0c47c98a71bfa3.
Updated by 
Updated by Julian Stock about 4 years ago
@Jo: Is this something that you can apply to TYOP3 v9 branch, too?
Updated by Jo Hasenau about 4 years ago
- Status changed from Closed to Accepted
Reopening this issue, since it seems that we have been missing another part of PageLayoutView, that still does not sort records properly.
\TYPO3\CMS\Backend\View\PageLayoutView::getContentRecordsPerColumn still just fires a query without adding orderBy.
Thus the columns in the side by side language view got no sorting at all, which results in some really weird sorting effects, because it can be completely different between each language.
The worst case scenario will return anything but a side by side view, because default language items and their translations will appear in random positions.
Updated by Jo Hasenau about 4 years ago
- Status changed from Accepted to Closed
Sorry - I just missed that getQueryBuilder will make use of prepareQueryBuilder too - so while the behaviour is still buggy, it does not seem to be caused by a missing orderBy.
Closing this issue again.
Updated by Anonymous over 3 years ago
Jo Hasenau wrote in #note-42:
Sorry - I just missed that getQueryBuilder will make use of prepareQueryBuilder too - so while the behaviour is still buggy, it does not seem to be caused by a missing orderBy.
Closing this issue again.
Still it bugs. Is there another issue going on?
Updated by Rainer Becker about 3 years ago
Any updates here? This is a major issue.