Bug #15817
closed
Retrieve/Update generates extensions.xml.gz file, but shows no extensions at all
Added by Thomas Kowtsch over 18 years ago.
Updated over 17 years ago.
Category:
Extension Manager
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)
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
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...
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();
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.
a memory_limit of 32 MB is what I use, and it works fine with that. 63 MB is definitely too much...
It seems its only a problem on php4 servers, not on php5
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.
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.
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...
Also available in: Atom
PDF