The typo3.org project

After the upload of my large extension failed several times, the result is this:

http://typo3.org/extensions/repository/view/gridelements

We got a current version 1.3.10, which should be 1.3.8 and the list shows 1.3.8 before 1.3.9 and 1.3.7 as predecessors.

Could someone please fix that, so that the current version will be 1.3.8 and the other versions are just removed?

Hi Jo

Jo Hasenau wrote:

After the upload of my large extension failed several times, the result is this:

Did you use the new extension manager for uploading? With that I also had/have troubles. Using the old EM worked fine for me.
The question now is: Is it a problem of the new typo3.org or the new EM

It's been both the new EM of 4.5 on my live server and the new EM of 4.6 on my local system.

The only difference was the content of the rror message. And actually it seems that the upload happened correctly but the error message was wrong.
Which is why I started the upload more than once, resulting in a new version 1.3.10 where 1.3.8 was the desired version number.

Jo Hasenau wrote:

It's been both the new EM of 4.5 on my live server and the new EM of 4.6 on my local system.

The only difference was the content of the rror message. And actually it seems that the upload happened correctly but the error message was wrong. Which is why I started the upload more than once, resulting in a new version 1.3.10 where 1.3.8 was the desired version number.

OK, so both times the new EM. Since I also ran into this but it worked fine with the old EM, I for now consider this a bug in the EM.

Is it OK for you if I move this to the Core project?

@Bas which extension manager do you use? Also the new EM?

Of course you can move the report to the core list, but the question was, if someone please could remove 1.3.10 and 1.3.9 from the TER, since these versions just don't exist.

Hi Helmut,

My opinion is that it has definitely to do with the new TYPO3.org web site. Cause I haven't changed our test servers from where I do updates and the problem started at the same day that the new TYPO3.org site went live.

I tried with old EM and new, but both show the same error:

Extension Manager
Extension: Multishop (multishop) Internal Server Error

My test server uses TYPO3 4.5.2. Also tried on TYPO3 4.5.11 and latest 4.6.x but no differences.

What does the error log of the TER web server reveal? There should be the key to a permanent fix?

I just had (again) a look at the log files: The access.log shows that requests to "index.php?id=ter" end up with error 500. However, I can't find any entry in other log files.

Bas, could you please upload your extension to some web space and post the URL so that we can do own tests?

Maybe it logs sth. helpful to devLog.

Steffen

This might be a duplicate of issue #35903.

But the response (text that is shown in EM) is Internal Server Error.

Sure, here you can download it:

https://www.typo3multishop.com/fileadmin/user_upload/beta/multishop.t3x

In the old TER this was also an issue for a while (<6 months ago).

At that time, the host master increased the memory limit to 38 MB to fix it. Hopefully they can increase the memory now again to that level, so we don't get into problems later (when the plugin gets a bit bigger).

Ah, thanks for spotting the error message. I expected it to happen somewhere before upload_max_filesize gets active.

I've set it to 64M now.

Bas, can you please try again?

Grrrrr.. I have no clue, what this should mean :-(

Okay, the next stage:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 280621 bytes) in typo3conf/ext/ter/class.tx_ter_api.php on line 515

Please give it another try ;-)

Yeah it works! Thanks guys for all the support, cheers!

I can't find any log entries written on 4/6/2012 at ~23.18

We have

max_execution_time = 300
max_input_time = 300
post_max_size = 50M
upload_max_filesize = 50M
memory_limit = 128M

Will increase memory_limit, please try again.

This could also be caused by missing fastcgi configs, if server is running php as fastcgi.
I post ours here. We noticed same problems on several servers, if the MaxRequestLen isn't set.

  FcgidIdleTimeout 400
  FcgidProcessLifeTime 300
  FcgidMaxProcesses 20
  FcgidMaxProcessesPerClass 8
  FcgidMinProcessesPerClass 0
  FcgidConnectTimeout 300
  FcgidIOTimeout 450
  FcgidInitialEnv RAILS_ENV production
  FcgidIdleScanInterval 10
  MaxRequestLen 52428800

Thanks, Boris. These timeouts are way higher than we had before. I've added them to our config. Bas, can you give it a try?