Bug #30918

update process language has false indication

Added by Ben van 't Ende over 1 year ago. Updated over 1 year ago.

Status:Needs Feedback Start date:2011-10-14
Priority:Should have Due date:
Assignee:- % Done:

0%

Category:Extension Manager
Target version:-
TYPO3 Version:4.6 Complexity:easy
PHP Version:5.3
Votes: 3 (View)

Description

When updating the language through the extension manager I get indication everywhere that the update has failed (language-not-available.png).

When I check again after the update it seems the update was succesfull anyway (language-not-available1.png).

It looks like the status when updating is not correct.

language-not-available.png (48.6 kB) Ben van 't Ende, 2011-10-14 10:38

language-not-available1.png - Language seems to be updated after all. (45.5 kB) Ben van 't Ende, 2011-10-14 10:39

class.tx_em_tools.php (37.1 kB) Oliver Salzburg, 2012-02-20 13:44

History

Updated by Markus Klein over 1 year ago

Also applies to 4.5

Updated by Xavier Perseguers over 1 year ago

  • Status changed from New to Needs Feedback

Does it really still apply to 4.6? Cannot reproduce!

Updated by Markus Klein over 1 year ago

It seems to happen only when there is already an existing translation.

If I clear the typo3temp folder first, it works without a problem.

Side note: I'm testing on a server with a slow connection.

Updated by Chris topher over 1 year ago

  • Target version changed from 4.6.0 to 4.6.1

Updated by Oliver Salzburg over 1 year ago

I experience this issue in 4.5.6 as well.

Updated by Stephan Großberndt over 1 year ago

I have the same problem in 4.6.0

Updated by Chris topher over 1 year ago

  • Target version changed from 4.6.1 to 4.6.2

Updated by Oliver Salzburg over 1 year ago

It still exists in 4.5.10 in case someone was wondering.

Updated by Oliver Salzburg over 1 year ago

So I did a little digging myself and here is what I found.

The core problem here is the tx_em_Tools_Unzip class.
tx_em_Connection_Ter::updateTranslation will call tx_em_Tools::unzip
tx_em_Tools::unzip sees that I did not supply a path to the unzip utility and decides to use the internal class tx_em_Tools_Unzip.

It will now assume that the return value of tx_em_Tools_Unzip::unzip is an array when it completes successfully. This assumption seems to be false.
This results in tx_em_Tools::unzip returning false and tx_em_Connection_Ter::updateTranslation returning FALSE. Thus, it appears as if the process failed.

So a workaround is just to supply $GLOBALS['TYPO3_CONF_VARS']['BE']['unzip_path'] with a path to the unzip utility and everything works great again.

Updated by Markus Klein over 1 year ago

Thanks Oliver for diggin'.

The workaround is pretty nice, still I'd like to see that fixed properly.
Do have a patch suggestions, which you could push to gerrit?

Updated by Oliver Salzburg over 1 year ago

Sadly, I have no patch yet. But I was looking a bit more into the tx_em_Tools_Unzip class and noticed that it logs errors. So I had a look at the error that causes it to behave as observed. For the extensions I have installed in the test environment I get these errors:

ARCHIVE_ZIP_ERR_BAD_FORMAT (-10) : Fail to find the right signature
ARCHIVE_ZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature

Most interesting might be the fact that 1 update succeeds.
/powermail-l10n-de.zip NoName (1) :

So, back to the errors. To my understanding, they are generated at the end of the extraction process (in _readEndCentralDir). But there's a little too much magic going on for me to tell if there is a problem in the code or if the zip file is actually damaged. In which case it might be a problem with the downloading of the file maybe.

Updated by Oliver Salzburg over 1 year ago

I'm pretty confident that the issue is with the tx_em_Tools_Unzip class. It is based on an older version of pclzip.lib.php. I looked at the latest version of that library at http://www.phpconcept.net/pclzip and compared both versions.
pclzip has two modifications in the _readEndCentralDir method (turns out one of the returned errors is simply not valid). Now all "Fail to find the right signature" errors are gone (yay). Sadly, most archives produce the "Unable to find End of Central Dir Record signature" error.

Updated by Xavier Perseguers over 1 year ago

  • Target version deleted (4.6.2)

Updated by Markus Klein over 1 year ago

Any news on this one?

Updated by Oliver Salzburg over 1 year ago

Personally, I would like to see all of PHPs internal zip functionality exhausted before the broken tx_em_Tools_Unzip is used. I took the liberty of hacking the changes into tx_em_tools. Haven't tested any of this, but the idea should be clear.

Also available in: Atom PDF