(ok 2.11.5) wrong error msg / no edit (Suhosin)

Logged In: YES
user_id=210714
Originator: NO

This is weird. I can reproduce it on the demo server (fast-cgi) but cannot on my server (mod_php).

I do "Check all" then "With selected Edit".

Logged In: YES
user_id=210714
Originator: NO

The message comes from the first "if" in tbl_row_action.php. Could you try to see which part of the "if" triggers the message in your case?

P.S. your file should be named 4csv_import.sql.

Logged In: YES
user_id=1383652
Originator: YES

I just happened to get that error when trying to help someone with csv import and creating a test db on the demo server
>P.S. your file should be named 4csv_import.sql.
why is that?
I just clicked "gzipped" and hit Go on the export page and uploaded it here in case the demo server gets purged.

I'll do some tests on the win/tux boxes that I have access to soon .....

Logged In: YES
user_id=210714
Originator: NO

The file you uploaded on this tracker is not compressed.

Logged In: YES
user_id=1383652
Originator: YES

sorry,
I didn't check the content,
must be a SeaMonkey 2.0a1pre download bug, FF2 works well ...
File Added: 4csv_import_bug1863326.sql.gz

test case from demo server (2 tables)

similar file with two cols and short strings NO BUG

Logged In: YES
user_id=1383652
Originator: YES

seems that the bug is only reproducable with many fields and/or big strings, resulting in very big $_REQUEST vars (the "old problem"), see db 1863326bug on demo and in the
File Added: 1863326bug.sql.gz

Logged In: YES
user_id=210714
Originator: NO

I reproduce the problem on demo server on the non-indexed table (with 2.11.4) but cannot reproduce it on my Linux server (mod_php) :(. What's your testing platform?

Logged In: YES
user_id=1383652
Originator: YES

I do all testing which doesn't require special config settings only on the demo server. But I can't reproduce this issue on my boxes either (tux/w2k, both apache226 php 5.2.5 as module). Must be a (Fast)CGI or lighttpd issue then.

Logged In: YES
user_id=192186
Originator: NO

JFYI: Not related to fast-cgi, but to the fact I run suhosin there with quite strict limits. Maybe I could increase them a bit...

Logged In: YES
user_id=192186
Originator: NO

Okay I increased limits, so this problem should not occur that often as before.

Logged In: YES
user_id=210714
Originator: NO

Can PMA directly detect that Suhosin is there? If not, maybe indirectly (like by putting the token as the last form parameter)?

Logged In: YES
user_id=1383652
Originator: YES

well,
well,
many users in the forum or on IRC report pma not working properly with the "suhosin" extension/patch. There should be a recommendation for the minimum settings in Documentation.html and in the wiki.

@Michal:
what about showing phpinfo() in (demo) main.php or - if you think it's not wise - showing some core (non default) settings of the demo server on http://pma.cihar.com/ ?

Logged In: YES
user_id=1383652
Originator: YES

>Can PMA directly detect that Suhosin is there?
if not possible via ini_get() you can extract the info at least like so:

ob_start();
phpinfo();
$pinfoArray = ob_get_contents();
//search for keywords "suhosin..." and extract the $key/$value from the table....

Logged In: YES
user_id=192186
Originator: NO

I enabled phpinfo(), it does not seem to expose anything critical (correct me if I'm wrong). I also added sentence about fact that Xcache and Suhosin are being used to main demo page.

Some indirect detection would work, but they you can either have XSS or some filtering such as Suhosin. I'm not sure whether there is some direct detection and quick googling did not reveal anything, but maybe I asked wrong question :-).

Logged In: YES
user_id=1383652
Originator: YES

just a wild guess:

define('SUHOSIN_MIN_REQUESTLENGTH', 128000); //or whatever
if ( !empty(@ini_get('suhosin.request.max_value_length'))
&& @ini_get('suhosin.request.max_value_length') <= SUHOSIN_MIN_REQUESTLENGTH) ) {
die('you have to increase the "suhosin.request.max_value_length" in your configuration');
}

(I don't have a suhosin enabled box for testing, sorry)

Logged In: YES
user_id=326580
Originator: NO

sorry for not seeing this bug report earlier (topic is misleading) ... i am aware of this problem and fixed this by myself last year already ... :-(

btw. i think in this case it is: suhosin.*.max_vars

see here: http://www.hardened-php.net/hphp/troubleshooting.html

Logged In: YES
user_id=210714
Originator: NO

I don't think we can base our testing on some correct value for this or other suhosin parameters that might be interfering with PMA.
So the best we can do is add a test in main.php:
if (@ini_get('suhosin.request.max_value_length')) {

and display a message that Suhosin is active on this server, with a link to our Documentation.html. In our doc we would give some examples of problems (like the table without a PK) and add a reference to the link mentionned by cybot_tm.

Logged In: YES
user_id=1383652
Originator: YES

agreed,
but the references in that link are a bit outdated, e.g.,
"hphp.post..." instead of "suhosin.post..." (like on Michal's demo server, see phpinfo)

Logged In: YES
user_id=210714
Originator: NO

Ok I'll add a note about this.