Project

General

Profile

Actions

Bug #30918

closed

update process language has false indication

Added by Ben van 't Ende over 12 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Language Manager (backend)
Target version:
-
Start date:
2011-10-14
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.6
PHP Version:
5.3
Tags:
Complexity:
easy
Is Regression:
No
Sprint Focus:

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.


Files

language-not-available.png (48.6 KB) language-not-available.png Ben van 't Ende, 2011-10-14 10:38
language-not-available1.png (45.5 KB) language-not-available1.png Language seems to be updated after all. Ben van 't Ende, 2011-10-14 10:39
class.tx_em_tools.php (37.1 KB) class.tx_em_tools.php Oliver Salzburg, 2012-02-20 13:44

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #35340: Error updating translations in extension managerClosed2012-03-28

Actions
Actions #2

Updated by Markus Klein over 12 years ago

Also applies to 4.5

Actions #3

Updated by Xavier Perseguers over 12 years ago

  • Status changed from New to Needs Feedback

Does it really still apply to 4.6? Cannot reproduce!

Actions #4

Updated by Markus Klein over 12 years 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.

Actions #5

Updated by Chris topher over 12 years ago

  • Target version changed from 4.6.0 to 4.6.1
Actions #6

Updated by Oliver Salzburg over 12 years ago

I experience this issue in 4.5.6 as well.

Actions #7

Updated by Stephan Großberndt over 12 years ago

I have the same problem in 4.6.0

Actions #8

Updated by Chris topher over 12 years ago

  • Target version changed from 4.6.1 to 4.6.2
Actions #9

Updated by Oliver Salzburg over 12 years ago

It still exists in 4.5.10 in case someone was wondering.

Actions #10

Updated by Oliver Salzburg over 12 years 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.

Actions #11

Updated by Markus Klein over 12 years 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?

Actions #12

Updated by Oliver Salzburg over 12 years 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.

Actions #13

Updated by Oliver Salzburg over 12 years 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.

Actions #14

Updated by Xavier Perseguers about 12 years ago

  • Target version deleted (4.6.2)
Actions #15

Updated by Markus Klein about 12 years ago

Any news on this one?

Actions #16

Updated by Oliver Salzburg about 12 years 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.

Actions #17

Updated by Alexander Opitz over 10 years ago

Hi,

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

Actions #18

Updated by Oliver Salzburg over 10 years ago

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

Actions #19

Updated by Alexander Opitz about 10 years ago

  • Status changed from Needs Feedback to New
  • Is Regression set to No
Actions #20

Updated by Susanne Moog over 9 years ago

  • Category changed from Extension Manager to Language Manager (backend)
Actions #21

Updated by Riccardo De Contardi almost 9 years ago

  • Status changed from New to Needs Feedback
  • Assignee set to Ben van 't Ende

Is this problem still valid in 6.2.12 or 7?

Actions #22

Updated by Oliver Salzburg almost 9 years ago

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.

Actions #23

Updated by Riccardo De Contardi almost 9 years ago

  • Status changed from Needs Feedback to New
Actions #24

Updated by Markus Klein almost 9 years ago

@Oliver can you please supply a patch to Gerrit?

Actions #25

Updated by Oliver Salzburg almost 9 years ago

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.

Actions #26

Updated by Markus Klein almost 9 years ago

  • Assignee deleted (Ben van 't Ende)
Actions #27

Updated by Wouter Wolters about 8 years ago

  • Status changed from New to Closed

Language update does not use this own zip implementation anymore, but relies on php functions.
This is at least the case for current master and 7.6 version.

I close this issue as solved now.

Actions

Also available in: Atom PDF