addHeaderItem breaks form submission in IE only

Permalink
So, I'm at a loss for what is going on with my code and thought I would run it by the masses.

Basically I am setting up Single Pages which include a form that updates custom user attributes.

The form posts back to the controller with
action="<?=$this->action('update_personal_info')?>">


The controller grabs the UI info
$u = new User();
      $ui = UserInfo::getByID($u->getUserID());

and pulls the POST values and sets the attributes
$ui->setAttribute('first_name', $this->post('first_name'));


Finally, the update_personal_info function invokes the view function
$this->view( );


and the view function assigns the UI to $profile
$profile = UserInfo::getByID($u->getUserID());
and sets the variables for the page
$this->set('first_name', $profile->getUserFirst_name());

so that they can be displayed in the "value=" attribute of the various input elements of the form..

This all works perfectly in FF, my development platform, today I decide to give it a look over on IE to make sure my form looks okay, and it doesn't work!

When I post the form within IE it reloads the page and everything looks like it worked. All the posted values are in the form like they should be. The problem is. none of that data is in the database, and when I navigate away from the page and come back none of the values are there.

I have verified that the POST data looks like it should with fiddler, I have verified that the controller is invoking my update function and that the post data is still intact within that function as well, but it's just not working within IE.

I'm sure it is something stupid I have overlooked, but I just can't get a handle on it.

Anyone have any ideas?

Full controller is posted below:
<?php 
defined('C5_EXECUTE') or die(_("Access Denied."));
Loader::model('user_attributes');
class AccountSetupController extends Controller {
   public function view($userID = 0) {
      $html = Loader::helper('html');
      $canEdit = false;
      $u = new User();
      if ($userID > 0) {
         $profile = UserInfo::getByID($userID);
         if (!is_object($profile)) {
            throw new Exception('Invalid User ID.');
         }
      } else if ($u->isRegistered()) {
         $profile = UserInfo::getByID($u->getUserID());

guythomas
 
guythomas replied on at Permalink Reply
guythomas
Also, feel free to visit the page itself and take a look at the behavior.

The login and password is:

c5_forums@c5.org

Url is:

http://bit.ly/4GfS4p
jordanlev replied on at Permalink Reply
jordanlev
Wow, that is weird. Works fine in firefox but submitting the form in IE8 clears out the data somehow (after you submit the form, it shows the data you entered, but it's only there because your controller is re-populating it from the POST data -- it is not coming from the database -- because if you navigate to that page again by going to the URL [as opposed to hitting refresh/reload], the entire form is empty).

Hmm... that is so bizarre that the client would affect how the data is being handled by the server. Do you have any way of stepping through the code with a debugger (xdebug with NetBeans or KomodoEdit sometimes works on WIndows, or on Mac I've had good luck with MacGDBp (http://www.bluestatic.org/software/macgdbp/... ). Perhaps that Exception is being thrown but it's not being displayed in a proper fashion? If you can't get a debugger working, can you check the logs?

If you still can't figure it out, try starting from a clean installation again (in a different directory of course -- don't delete what you've already got), and add back in 1 feature or piece of code functionality at a time and find out at what point it's not working anymore.

Good luck!
guythomas replied on at Permalink Reply
guythomas
Thanks for looking at it.

I have found the problem, but I am still trying to create the fix..

When I comment out the following line within my controller everything works..

$this->addHeaderItem($css);


For some reason with IE, it doesn't not like this item. I'm not sure if there is a problem in the stylesheet or what, but I still don't understand how that could possible affect the server side handling.. The javascript addHeaderItem works just fine and does not interfere.

So, right now I'm searching for an alternative way to link the stylesheet to the single page.

I suppose I should also look at my CSS.
jordanlev replied on at Permalink Reply
jordanlev
What is the value of that $css variable?
Is it supposed to be pointing to this file:
http://www.victorvalley.biz/index.php/tools/css/themes/VVBIZ/main.c...

If so, there's a problem with the CSS file, not the concrete5 or php code, because if you try to open that file in IE it shows an error "Internet Explorer cannot download main.css fromwww.www.victorvalley.biz".... I suspect this:

@charset "utf-8";

might be the problem -- I've never seen that before in a css file.
guythomas replied on at Permalink Reply
guythomas
No. The $css variable is
$css = $html->css('account_setup.css');


which is a file located in the root/css directory. I went ahead and used the CSS validator and everything is good to go there, so I'm really not sure what is going on.

Does anyone know an alternate way to include this CSS file without hardcoding it into my view.php?
jordanlev replied on at Permalink Reply
jordanlev
Is there a reason you don't want to include it from the view? You can use:

<link rel="stylesheet" type="text/css" href="<?php echo $this->getStyleSheet('account_setup.css'); ?>" />

...which seems to be a standard practice for C5 sites.
guythomas replied on at Permalink Reply
guythomas
I don't really want to hardcode it into the view.php file, when it is only going to be used on 4 single pages. I suppose I could create 4 separate pages within the theme directory with the page names.. but I guess the real issue is the peculiarity of the issue, and wondering why the addHeaderItem technique breaks the form in IE.
ScottC replied on at Permalink Reply
ScottC
i always post to a method in the controller using method ="post" action="<?php echo $this->url('/path-to-controller','update-whatever');" > note second parameter.

on_start is a better place to check post if you aren't going to check until you hit the view method.
guythomas replied on at Permalink Reply
guythomas
ScottC,

Thanks for the tip. I think what you are telling me is that the current way I am attempting to post the data means that the view() method is called first (hence the input values get populated) immediately afterwards the update_personal_info() is called and the attributes are updated. Because the problem line addHeaderItem is in the view(), maybe it is causing a problem that keeps the update function from happening.

You are recommending that I make it post the values to the db before the invoking the view()..

So I managed to get it to work with a bastardization of your two points..

When I attempted to change the action to
action="<?php echo $this->url('/controllers/account_setup.php', 'update_personal_info')?>">

I got accessed denied. I guess this was because I was trying to access the controller directly.. So I figured you didn't mean path to the controller directly, but just path to the single page. I changed it to..

action="<?php echo $this->url('/account_setup.php', 'update_personal_info')?>">

But this didn't run my update_personal_info() method at all.. So finally I decided to try the on_start() method. I switched the form's action to simply

action="<?php echo $this->url('/account_setup.php')?>">

and added a the on_start() method in the controller
public function on_start() {
   if ($this->post('submit')) {
   $this->update_personal_info();
   }
   }


This did the trick and now my form is working correctly in both FF and IE. Of course, I would still like to know why my initial way wasn't working in IE, but this is a good work around.

Thanks again to both jordanlev and ScottC.
moth replied on at Permalink Reply
moth
I'm having the same issue and, having read through this thread, I've not had the same luck in getting this to work.

Something very funny going on with IE here.

I wonder is anyone else has spotted this?
moth replied on at Permalink Reply
moth
A few more bits of insight, although I don't know what it means yet.

The details ARE being written to the DB, since after I've set them using setAttribute or even saveAttributeForm I can do this;

$ui->getUserMiddleName();


and it returns the values I'd expect.

I'm getting no errors in my error logs, however, looking at the Apache access_log reveals that when using IE, you get a rogue 404;

192.168.0.7 - - [30/Jan/2011:10:47:39 +0000] "GET /index.php/profile/step2 HTTP/1.1" 200 123130
192.168.0.7 - - [30/Jan/2011:10:47:40 +0000] "GET /index.php/profile/none HTTP/1.1" 404 1728


What is "profile/none"?

Using any other browser doesn't return this.

Somewhere, all the attributes in my form are getting chomped with empty values.
moth replied on at Permalink Reply
moth
It seems that "something" is happening in my script (or more worryingly C5?) upon redirect once the "save" method is completed.

- The values get written to the DB (in this case User Profiles), and then mysteriously get overwritten with blank values (completely deleted - but only the values in my form - not the whole User profile).

I'm managed to "fix" it in my case by using a manual PHP redirect at the end of my "save" method where I know that the values have been written.

header("Location:/profile/step2");


I hope this might help someone else, but I'd still like to know what's going on.