TYPO3 Core

Also applies to 4.5

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.

I experience this issue in 4.5.6 as well.

I have the same problem in 4.6.0

It still exists in 4.5.10 in case someone was wondering.

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.

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?

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

/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.

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.

Any news on this one?

Hi,

as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (4.5 or 6.1)?

Alexander Opitz wrote:

Hi,

as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (4.5 or 6.1)?

On every new installation of TYPO3, setting an unzip utility is one of the first things I do, so I have no idea. But if tx_em_Tools_Unzip is still used anywhere in the code, then the problem still exists (unless the class was drastically updated).

Riccardo De Contardi wrote:

Is this problem still valid in 6.2.12 or 7?

The answer I posted a year ago is still a valid answer.

@Oliver can you please supply a patch to Gerrit?

Markus Klein wrote:

@Oliver can you please supply a patch to Gerrit?

Sorry, but no. I was actively working on this issue 3 years ago. By now it no longer affects us due to aforementioned workaround. So the time it would take to get into the TYPO3 contribution process and writing a patch that's based on current TYPO3 versions is simply too much, given that we don't benefit from it.

If there is any value in the code I posted back then, then anyone is welcome to make use of it.

IMHO, if they still exist, PHP-based unzipping implementations should be completely removed from the TYPO3 code and PHP internal functions should be used, if no unzip binary is provided. IIRC, the PHP-based approach was only used back then because old versions of PHP did not have built-in unzip support. Given that those old versions of PHP are probably no longer supported by TYPO3 anyways, there is no need to have the faulty implementation.

Someone who is already a TYPO3 contributor and is familiar with the code base should be able to quickly determine if these changes are still necessary or if they were already implemented in the past 3 years, I am not.