Project

General

Profile

Actions

Bug #91223

closed

Content element sorting is broken in the page module

Added by Michell Kalb almost 4 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Must have
Assignee:
Category:
Backend User Interface
Target version:
Start date:
2020-04-28
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
10
PHP Version:
Tags:
Complexity:
easy
Is Regression:
Yes
Sprint Focus:

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.

Steps to reproduce:
  1. Install a fresh version of TYPO3 10.4.0
  2. Create some content elements in the backend (ordering is working now)
  3. Create a backend layout with 2 rows (see below)
  4. Try to rearrange the content elements
  5. 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

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #90235: Page module allows to break content of subpagesClosedBenni Mack2020-01-28

Actions
Actions #1

Updated by Georg Ringer almost 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."

Actions #2

Updated by Michell Kalb almost 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.

Actions #3

Updated by Sven Wiener almost 4 years ago

Got the same Issue at TYPO3 10.4.1 in both modes, even if I use only one column.

Actions #4

Updated by Oliver Pfaff almost 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 .

Actions #5

Updated by Alessandro Schmitz almost 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

Actions #6

Updated by Sven Wiener almost 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.

Actions #7

Updated by Martin Weymayer almost 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.

Actions #8

Updated by Martin Weymayer almost 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???

Actions #9

Updated by Martin Weymayer almost 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?

Actions #10

Updated by Martin Weymayer almost 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.

Actions #11

Updated by Martin Weymayer almost 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(
...

Actions #12

Updated by Peter Bünemann almost 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

Actions #13

Updated by Oliver Kurth almost 4 years ago

I have the same Problem!

Actions #14

Updated by Jo Hasenau almost 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.

Actions #15

Updated by Jo Hasenau almost 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.

https://review.typo3.org/c/Packages/TYPO3.CMS/+/63063/9/typo3/sysext/backend/Classes/View/PageLayoutView.php#b3032

        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.

Actions #16

Updated by Gerrit Code Review almost 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

Actions #17

Updated by Gerrit Code Review almost 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

Actions #18

Updated by Gerrit Code Review almost 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

Actions #19

Updated by Jo Hasenau almost 4 years ago

  • Related to Bug #90235: Page module allows to break content of subpages added
Actions #20

Updated by Julian Stock almost 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).

Actions #21

Updated by Peter Bünemann almost 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.

Actions #22

Updated by Felix Holler almost 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!

Actions #23

Updated by Martin Weymayer almost 4 years ago

Still problems in 10.4.4 with sorting. Gridelements and Mask installed.

Actions #24

Updated by Andre Koller almost 4 years ago

Same here. Typo3 10.4.4, Mask 5.0.0, Gridelements 10.0.0

Actions #25

Updated by Markus Slaby almost 4 years ago

Same problem here with TYPO3 10.4.4, gridelements and mask - but the Bugfix Jo presents seems to work for me

Actions #26

Updated by David Bascom almost 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.

Actions #27

Updated by Gerrit Code Review over 3 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

Actions #28

Updated by Gerrit Code Review over 3 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

Actions #29

Updated by Jonas Eberle over 3 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?

Actions #30

Updated by Thomas Anders over 3 years ago

Recreation of the index didnt work for me in 10.4.6. The elements still jumps back after reload.

Actions #31

Updated by Stephan grass over 3 years ago

Same here in 10.4.6. The elements jumps back after reload. No chance to sort CE's in the page module.

Actions #32

Updated by Grégory Duchesnes over 3 years ago

same here with a fresh install of 10.4.6 and a clean index

Actions #33

Updated by Kim Christiansen over 3 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.

Actions #34

Updated by Gerrit Code Review over 3 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

Actions #35

Updated by Gerrit Code Review over 3 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

Actions #36

Updated by Gerrit Code Review over 3 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

Actions #37

Updated by Gerrit Code Review over 3 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

Actions #38

Updated by Jo Hasenau over 3 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #39

Updated by Benni Mack over 3 years ago

  • Status changed from Resolved to Closed
Actions #40

Updated by Julian Stock over 3 years ago

@Jo: Is this something that you can apply to TYOP3 v9 branch, too?

Actions #41

Updated by Jo Hasenau over 3 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.

Actions #42

Updated by Jo Hasenau over 3 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.

Actions #43

Updated by Anonymous about 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?

Actions #44

Updated by Rainer Becker over 2 years ago

Any updates here? This is a major issue.

Actions

Also available in: Atom PDF