Project

General

Profile

Actions

Bug #15817

closed

Retrieve/Update generates extensions.xml.gz file, but shows no extensions at all

Added by Thomas Kowtsch about 18 years ago. Updated about 17 years ago.

Status:
Closed
Priority:
Should have
Category:
Extension Manager
Target version:
-
Start date:
2006-03-13
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.0
PHP Version:
4
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

When using the Retrieve/Update function, it takes a short while and then says "The extension has not changed remotely, it has thus not been fetched." The extensions.xml.gz is written fine to typo3temp/ directory, but the user still isn't able to view the list at all (and thus not able to add any new ones).

I wasn't able to resolve this problem with different combinations of "unsupported extension" and other options as decribed in ticket 0002742.

PHP 4.3.4
(issue imported from #M2858)


Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Feature #15751: Extension Manager "Look up" shows "No matching extensions found" when "Enable unsupported extensions" is not enabledClosedMichael Stucki2006-03-01

Actions
Is duplicate of TYPO3 Core - Bug #15663: EM2 need more than 32 MBClosedKarsten Dambekalns2006-02-17

Actions
Actions #1

Updated by Alexander Maringer about 18 years ago

Same problem on Debian etch with PHP 4.4.2.

After checking 'Enable unsupported extensions' it works fine.

Installation upgraded from 3.8.1 with installed extensions:
captcha
cc_awstats
pil_mailform
kickstarter
irfaq
extdeveval
realurl
t3quixplorer
th_mailformplus
tt_news

I played a little bit around. After gunzip and gzip it has a different size at my server. At the retrieve / update I get a blank white screen with a 'Allowed memory size of 33554432 bytes exhausted'.

By increasing the memory_limit to 48M the following procedure works fine:
#gunzip extensions.xml.gz
#gzip extensions.xml
ExtMan -> Import extensions -> Retrieve / Update

Actions #2

Updated by Thomas Kowtsch about 18 years ago

I re-tried a bit with deleting the extensions.xml file, increasing MemorySizeLimit to 58M and maxexecutiontime to 120 seconds.

Now, after import/update, I can see a "new" text - "(last update: 2006-03-17 07:02)", and a extensions.bin file has been created.

But the list doens't show up at all...

Actions #3

Updated by Thomas Soumarmon about 18 years ago

I had the same problem on Debian with error about memory allocation.
memory_limit=24M in php.ini was not enough, I made it 100M to be sure to have it parsed by the extension.

The other problem was that the em tool checks for md5 signature of the file, and does not see that the file was retrieved but NOT parsed.
What I've done is copy/paste lines 1089/1090 to line 1083 to have it parsed anyway (lines copyed at bottom of note).

Maybe a button 'parse again file' with those lines would be great.
Anyway, this function should be less memory hungry to have it work on regular configuration.

$content .= $this->xmlhandler->parseExtensionsXML(
implode(gzfile(PATH_site.'typo3temp/extensions.xml.gz')));
$this->xmlhandler->saveExtensionsXML();
Actions #4

Updated by Thomas Kowtsch about 18 years ago

Today, I tested again to find out where the memory limit is - for my server 63M is minimum to get it work. I haven't checked in detail what function needs that memory, if it is "only" for creating, validating and pre-formatting the downloaded extension list (not during painting the table on the screen), it might help to provide a function to download the entire file at once by a special button, generating the file on the download server once a day.

Actions #5

Updated by Karsten Dambekalns about 18 years ago

a memory_limit of 32 MB is what I use, and it works fine with that. 63 MB is definitely too much...

Actions #6

Updated by old_jelte about 18 years ago

It seems its only a problem on php4 servers, not on php5

Actions #7

Updated by old_jelte about 18 years ago

If you copy the extensions.xml.gz from a typo3 setup on a PHP5 server to a typo3 setup on a PHP4 server it works.

Actions #8

Updated by Peter Niederlag about 18 years ago

IMHO this is a real serious issue. Like Thomas has stated already on 03-20-06 raising the memory_limit is not even sufficient if extension.xml.gz has already been imported but couldn't be parsed due to memory-limit. If extension.xml.gz has not been changed it won't get parsed again and files are still missing leading to an "no extensions found" without any further notice/warning. :-<

IMHO there must be some check/error-handling somewhere to look for those *.bin files or recreate them.

It might really be better to distribute those preparsed files anyway? Since you seem to be at it again anyway I didn't create a patch for now.

Actions #9

Updated by Ingo Schmitt almost 18 years ago

See Bug 0003289

Actions #10

Updated by Michael Stucki over 17 years ago

I am closing this bug since it seems to be a duplicate of 2615. Please try out the extension he published and post your feedback there...

Actions

Also available in: Atom PDF