Project

General

Profile

Actions

Bug #59458

closed

Erroneous date sorting in File List

Added by Francois Suter over 9 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Backend User Interface
Target version:
Start date:
2014-06-10
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.1
PHP Version:
5.3
Tags:
Complexity:
medium
Is Regression:
No
Sprint Focus:

Description

The sorting by date fails in the Filelist module under some conditions.

The sorting happens in \TYPO3\CMS\Filelist\FileList::getTable(). For each file to be sorted, the value corresponding to the sorting parameter is fetched from the file object and used as the key in an associative array. This array is then sorted simply by using uksort(). The code takes into account the fact that several files may have the same value for the given property and hence provide the same key. To avoid overwriting existing entries, a number is appended to the key. It starts at 0 and is increased by 1 as long as there's already an entry with that key.

This solution is not good for numerical fields (like modification date), because it actually changes the numbers. This gets very bad when you have 10 or more files with the same value (modification date, for example, but it could be size). When we reach the 10th file with the same date, the number "10" gets appended to the timestamp, changing it by an order of magnitude.

Example:

Consider many files having "1386924065" as a modification date (Fri Dec 13 09:41:05 CET 2013). If you reach more than 10 files with the same date, the next file will have the following key "138692406510".

Now if you have another file with a modification date of "1401866024" (Wed Jun 4 09:13:44 CEST 2014). It's the only one with that date, so it will have the key "14018660240".

138692406510 > 14018660240 so the older file will appear first, as it if were more recent.

I propose that the number to append starts at a very large figure (e.g. 1'000'000) rather than 0. That way the same logic can be preserved and sorting errors can be avoided.

This bug exists at least in TYPO3 CMS 6.1 and 6.2. I haven't checked older versions.

Actions #1

Updated by Gerrit Code Review over 9 years ago

  • Status changed from New 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/30657

Actions #2

Updated by Francois Suter over 9 years ago

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

Updated by Gerrit Code Review over 9 years ago

  • Status changed from Resolved to Under Review

Patch set 1 for branch TYPO3_6-1 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/30711

Actions #4

Updated by Francois Suter over 9 years ago

  • Status changed from Under Review to Resolved
Actions #5

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF