Bug #22441

importExtInfo() does not sort versions correctly

Added by Daniel Minder about 11 years ago. Updated almost 11 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
-
Start date:
2010-04-13
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.3
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

This is a follow-up to solved bug #22378. showExtensionsToUpdate() does show correctly that there is a new version of an extension, but when clicking on the extension name importExtInfo() selects the wrong version due to the same problem.

The solution is similar: use natsort to sort the version numbers and use the last list entry as default since it is the highest one.

(issue imported from #M14090)


Files

em-patch.diff (692 Bytes) em-patch.diff Administrator Admin, 2010-04-13 11:43
14090.diff (692 Bytes) 14090.diff Administrator Admin, 2010-04-16 12:17
screenshot.png (27 KB) screenshot.png Administrator Admin, 2010-04-16 12:18

Related issues

Related to TYPO3 Core - Bug #22378: "Check for extension updates" does not always find latest versionClosedJeff Segars2010-04-05

Actions
Related to TYPO3 Core - Bug #17861: Extension Manager does not sort versions of an extension correctlyClosed2007-11-28

Actions
Related to TYPO3 Core - Bug #18640: EM considers 0.8.0 to be have a higher number than 1.0.0ClosedChris topher2008-04-19

Actions
Has duplicate TYPO3 Core - Bug #22433: "Check for extension updates" does not always do the updateClosedChristian Kuhn2010-04-12

Actions
#1

Updated by Christian Kuhn about 11 years ago

Set relation to #22378.

#2

Updated by Steffen Gebert about 11 years ago

You're absolutely right. I couldn't find your report, so I worked on the same issue and came to the exactly same solution.

Here are my insights of the EM's internals:
It currently happens for me with tinymce_rte, where it lists 0.0.10 as newest version, although 0.5.1 is.
The author stated that 0.5.1 was really the latest upload, not 0.0.10.

The search is done in SC_mod_tools_em_xmlhandler::searchExtensionsXML()
When I have a look at the database, the order is correct (0.0.10 first and then all releases till 0.5.1). But when I execute the SQL query like it's done by the EM (SELECT * FROM `cache_extensions` WHERE extkey LIKE 'tinymce_rte' ORDER BY category, title) then 0.0.10 is the last entry (although category and title didn't change).
In this (wrong) order, the exensions are saved in $this->extensionsXML[$row['extkey']]['versions']

I think this depends on how the data is saved by the DBMS. I couldn't reproduce this on a second system.

As there is no way to natsort() the array keys at this stage, I would stick to keeping them saved in wrong sorted order, but later sort them before showing the available versions in the extensions' detail page.

Will send your patch to the core list right now.

#3

Updated by Francois Suter about 11 years ago

Committed to trunk in revision 7374
Committed to 4.3 in revision 7375

Also available in: Atom PDF