Error when editing payment module settings

When trying to setup authorize.net I get this error

Warning: Variable passed to each() is not an array or object in /admin/modules.php on line 56

Warning: Cannot modify header information - headers already sent by (output started at /admin/modules.php:56) in /admin/includes/functions/general.php on line 21


line 56 on modules.php

while (list($key, $value) = each($_POST['configuration'])) {

line 21 on general.php

header('Location: ' . $url);


Not sure what is causing the problem by examining the code, anyone have any ideas?

witch type of account are you setting up AIM or SIM, did you try disabling the module and setting it up again? and are you sure the Information from Authorize.net is correct.

did you check the similar threads at the bottom of the screen.

pete

I am setting up a SIM all the passwords are correct

and I tried relaoding the module. The only thing I can think of is installing zencart again and see if it was because of a coruput install

I just got the same error when trying to setup the UPS module.

I re-installed zen cart and I am still getting the same error. Any1 have any ideas?

Please stop posting the same issue all over the forum.


Sounds like something wrong with your server or your browser, which is causing the POST values submitted by the form to be broken.

I only posted in 2 other catagories.

I just figured out the problem just in case someone else gets this error

by the way I have SSL installed on my server and automaticlly forward http traffic to https

If you get the same error I did change:

/www/admin/includes/configure.php

edit the lines and make sure lines 27 - 32 are set to these values

* If you desire your *entire* admin to be SSL-protected, make sure you use a "https:" URL for all 4 of the following:
*/
define('HTTP_SERVER', 'https://yourdomain.com');
define('HTTPS_SERVER', 'https://yourdomain.com');
define('HTTP_CATALOG_SERVER', 'https://yourdomain.com');
define('HTTPS_CATALOG_SERVER', 'https://yourdomain..com');

If you had an automated redirect (such as via .htaccess) to force all http traffic to go to a https address, that could cause the submitted data to be dropped.

Thus, setting your Admin to actually use the https directly is the safer approach, as you indicated.