ansaurus

Question

Answer 1

+2 A:

There should be a module settings file in app/etc/modules/ with a boolean in it. Disabling a module output doesn't disable the module. Only its output. Removing the module from the community folder should do the job, but it could be dirty depending on whether this plugin has created tables on your database or not.

greg0ire 2010-07-12 20:35:05

Well, I tried deleting the plugin entirely, but that broke the entire site. I'll disable in app/etc and report back.

melee 2010-07-13 03:48:04

Looks like <enabled> is set to 0. This plugin is rather annoying.

melee 2010-07-13 14:43:37

@melee, are you sure you are looking at the good file? It should be ArtsOnIt_OfflineMaintenance.xml, and the setting should be set to <active>false</active>

greg0ire 2010-07-13 15:59:58

@greg0ire - Durf. I'm sorry, I didn't read all the way. I changed that to false, and the error still occurred after a cache refresh, just without the ArtsOnIt plugin in the trace.

melee 2010-07-13 17:00:50

Answer 2

+1 A:

Suspicious module disabled? Ok, let's go for another answer then. First, check whether you get any output before the error stack trace. An output provokes the sending of headers for this output.

greg0ire 2010-07-13 18:50:50

Hit add to cart -> public_html/checkout/cart/addmultiple/uenc/aHR0cDovL3d3dy50cnVtcGV0dGUuY29tL3dob2xlc2FsZS9iYWJ5LWJ1ZmZhbG8uaHRtbD9fX19TSUQ9VQ,,/product/1103/ -> Error page. Does this help?

melee 2010-07-13 19:21:23

@melee: yes it does! You can consider any output before the error message to be abnormal, since the headers are not supposed to be sent yet. You should find why this piece of text is output, and suppress this output. Check out a few of the billion question about "headers already sent errors" if this still seems unclear to you.

greg0ire 2010-07-13 19:53:01

Ok, so then there should be a hook on the "Add to Cart" button that is running the redirect, and since the AddMultiple extends that function and resends headers, then it would cause the error, am I correct?

melee 2010-07-14 14:51:38

I think I misinterpreted your first comment, I though this was the output you got before the error stack trace, but in fact now I think that you wanted to explain what happened without english sentences... to know why headers are sent before the one that AddMultiple attempts to send, just terminate the script before this attempt, by using die("some text") in /home/website/public_html/app/code/local/Perpetual/MultiAdd/controllers/Checkout/CartController.php on line 202. You should either be redirected, or get a blank page with some output before the "some text" string.

greg0ire 2010-07-14 21:57:23

put the die("Error); line on 202 and got output: 1Error. I'm looking into it now, I'll see if I can fix it.

melee 2010-07-15 02:19:10

OK! So, I found that there was a print $qty; - i commented that out, and everything seems to be working fine. Is this a clean fix for this issue?

melee 2010-07-15 02:36:21

If the print $qty was not in Magento's core, I think it is.

greg0ire 2010-07-15 08:12:28

Thank you very much for your persistence, greg0ire. I really appreciate it. If my logic is correct, the print $qty was rendering the page, then attempting to resend headers, which caused the issue?

melee 2010-07-15 14:08:39

Exactly, because you cannot print $qty without sending a header to tell the browser what you are sending.Whenever you output anything to the user's browser, you need to say what you are sending: html, css, js, images... etc. You also provide a status code : 200 OK, 404 Not found... etc, and a bunch of other informations which can be seen in Firebug's network tag.Happy Magento-ing!

greg0ire 2010-07-15 14:26:20

ansaurus

tags:

views:

answers:

Magento Error: Headers already sent

related questions