Bug #22441
closed
importExtInfo() does not sort versions correctly
0%
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
Updated by 
Updated by Steffen Gebert over 14 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.
Updated by Francois Suter over 14 years ago
Committed to trunk in revision 7374
Committed to 4.3 in revision 7375