Role can't save changes in IE; fine in Firefox

I’ve created a "Content Editor" role (can create/edit pages, can’t delete pages or change anything else).

When I try and save changes using this role in IE (both IE6 and IE7) I get an error message:

An error occured while attempting to save the edited document. The generated SQL is: UPDATE [the rest of the UPDATE statement here]; .
Warning: Cannot modify header information - headers already sent by (output started at /var/www/vhost/mysite/manager/processors/save_content.processor.php:428) in /var/www/vhost/mysite/manager/processors/save_content.processor.php on line 563

However, in Firefox it works beautifully.

Any ideas?

(tearing hair out -- am supposed to train the client in two days and this is killing me.)

I’m sorry I can’t give you the exact explanation of why this error is occurring, but I always start off all my documentation and training of my clients to manage the sites I create with MODx with this simple rule: ALWAYS, ALWAYS, ALWAYS use FireFox to manage the site. IE doesn’t play well with MODx, so I walk my clients through the process of installing FireFox if they need the help b/c IE is too glitchy.

I hope someone else with a more advance understanding of the problem can help, but when errors come up in managing the site, that’s always the first question I ask my clients: Are you using FireFox? 9 out of 10 tens time they’ve accidentally used IE. When they use FF, issues rarely come up.

Sigh. I guess this is as good a stop-gap as any. Since my searching of the forums didn’t find an answer to this issue, I was coming to the realisation that this might be a simple "IE sucks" issue.

I was hoping this wouldn’t be the case, because it can be perceived as a strike against MODx -- not in *my* eyes, but to those people for whom the Internet *is* IE.

(Case in point -- I just dealt with someone who got a new Mac and wasted 1/2 an hour until she "realised that Safari was the ’Blue E’".)

Thanks.

(Case in point -- I just dealt with someone who got a new Mac and wasted 1/2 an hour until she "realised that Safari was the ’Blue E’".)

OMG....that’s so hilarious! I’ve had crazy stories like that as well.

About clients perceiving MODx and IE not working together as "a strike against MODx", I actually have been able to turn that argument around to MODx’s favor. How? I explain to my clients that since MODx is a very standards-compliant CMS, browsers like FF (FireFox) work great with it since FF "obeys" the rules of HTML whereas IE doesn’t. In other words, I point out the fact that MODx was built correctly and basically IE wasn’t. But then if the client becomes afraid that MODx sites may not render correctly in IE, that’s where I explain that I implement the coding necessary in the templates for the site to work across the major browsers and for the 2 major Operating Systems: Mac and PC.

I think they’ll understand. I’ve never had a complaint once from my clients about them having to use FF.

Just in case anyone cared, I discovered the solution to this problem.

I decided to test the SQL statment that the error message was popping up in IE. The SQL was choking on the fact that that is_folder was getting no value (neither 0 or 1). This was causing IE to throw its hands up in the air in disgust.

So I looked to the one area that I had customised that affects is_folder. I found it in the ManagerManager plugin, which I am using because my clients want a very simple editing interface. One of the config directives that I had in the plugin read: Firefox was fine with this.

IE was not.

I removed the line, problem went away.

Whew.

Might post this solution in the Manager Manager support thread.