www.webdeveloper.com
Results 1 to 10 of 10

Thread: IE9- and Empty Post Data

  1. #1
    Join Date
    Mar 2014
    Posts
    6

    IE9- and Empty Post Data

    Hi, so we developed a redesign and upgrade of our company's site over the past few months and everything worked fine.

    We swapped the servers for our domain, and now all of the sudden forms that post are not working in IE9 and below. Oddly, after putting the site live, we created a backup which runs on another server and all of the forms work on that site just fine.

    At first, I thought it was just the registration form and after some Googling I found that you can add a placeholder attribute to all of the fields and it will work fine, which it did. However, our checkout process has a section with two radio buttons and I can't do the same for those inputs so nobody on IE9 or below is able to checkout.

    I can't find any solutions, but it's a pretty major issue. Does anybody have ideas on how to fix this?

    I've checked the output from the form IMMEDIATELY after submitting, and it shows the form fields as having no data so I know it's not any javascript or anything altering the info. This has been driving me insane, I'm praying somebody can help me figure this out =(

  2. #2
    Join Date
    Mar 2011
    Posts
    1,133
    It's hard to tell from your message what you've done and in what order, or even how you tested things.

    Did you run the page through an HTML validator to look for errors?

    The 'placeholder' attribute is only valid on <input> types text, search, tel, and email. It's only supported on IE10 and higher.

    If you'll post a link to an example page, it would be much easier to help.
    Rick Trethewey
    Rainbo Design

  3. #3
    Join Date
    Mar 2014
    Posts
    6
    Sorry, I'll try and break down what I've done some more.

    Pre-issue:
    - Finished developing new website, no issue here.
    - Not quite sure how he went about it, but boss switched the development site's domain to the live domain. Essentially putting it live.
    - Enabled SSL
    - Issue arose

    Firstly, it's a Joomla site. So once I noticed the issue:

    - I copied all of the related files from the Development server (which works fine) to the live server.
    - I disabled the only javascript that attempts to validate the form input.
    - I used JLogger to output the $_POST data from the first function the data goes to, it printed all empty fields, e.g. "name_field = "

    After some googling I found this link: http://stackoverflow.com/questions/9...rs-form-fields which says adding placeholder attributes will fix it. Don't understand why or how since, as you said, placeholder isn't even supported in IE9 and below (unless it's related to the page being an HTML5 page on IE9?) although I do have a javascript function for adding "placeholders" to inputs in unsupported browsers.


    I have not yet run it through a validator, I'll do that now I suppose. I'll work on finding another form where it has the same issue. At the moment I have the placeholders on our registration form, and the next one with the issue is a checkout form which I don't think anyone wants to use to test.

  4. #4
    Join Date
    Mar 2014
    Posts
    6
    Couldn't find a way to edit the previous post... but anyways

    I took the placeholders off the registration form for now, weekends are slow traffic for our site anyways. So you can see what's happening here:
    https://www.borrellassociates.com/register/

    The post data is getting cleared when you submit so it thinks you didn't fill out any of the fields and thus tells you to enter your name.

  5. #5
    Join Date
    Feb 2014
    Location
    Canada
    Posts
    155
    Placeholder attributes shouldn't be a fix because it's akin to having the colour of the background change when you click on something. At the top of each PHP page, type the following 2 lines to show most of the errors in the browser. You can also check the error logs, however, the way you access them differs for each web server.

    PHP Code:
    error_reporting(E_ALL);
    ini_set('display_errors'1); 
    It's possible that the new server hasn't been configured properly, although you should see evidence of this in the error logs or through the above 2 lines of code. Based on the results this gives, you can make the appropriate changes or show the relevant snippets of code.

  6. #6
    Join Date
    Mar 2011
    Posts
    1,133
    The HTML for the register page has a lot of problems. Most of them stem from using multiple instances of the same code. For example, I counted 6 instances of the <form> tag. So the mystery isn't so much why it doesn't work with IE9 as it is why it works at all in other browsers. The page is a single form, so there should only be one <form> tag that encloses all of the <input> elements. You've also used the same value for the 'id' attribute on multiple elements, which is going to lead to problems at some point.

    Submit the page to the validator at http://validator.w3.org/ and you'll see what I mean. I'd suggest running it through following each attempt at repairing the code so you can check your progress. You can live with a few warnings, but you should eliminate all of the errors. Good luck!
    Rick Trethewey
    Rainbo Design

  7. #7
    Join Date
    Feb 2014
    Location
    Canada
    Posts
    155
    I just took a look at your website and the problem is you're using "/register" for the <form action = "afile.php">...</form> but it needs to be a path and that's the syntax for a folder! If all of it is meant to be passed to the same PHP file, then you only need 1 <form>.

  8. #8
    Join Date
    Mar 2014
    Posts
    6
    Quote Originally Posted by rtrethewey View Post
    The HTML for the register page has a lot of problems. Most of them stem from using multiple instances of the same code. For example, I counted 6 instances of the <form> tag. So the mystery isn't so much why it doesn't work with IE9 as it is why it works at all in other browsers. The page is a single form, so there should only be one <form> tag that encloses all of the <input> elements. You've also used the same value for the 'id' attribute on multiple elements, which is going to lead to problems at some point.

    Submit the page to the validator at http://validator.w3.org/ and you'll see what I mean. I'd suggest running it through following each attempt at repairing the code so you can check your progress. You can live with a few warnings, but you should eliminate all of the errors. Good luck!
    Ok, knocked all of the errors out but 1, which is completely irrelevant to the problem and in my opinion isn't really an error. There are 3 forms on the page now, all of which are necessary and are used for unrelated things. One for the login form, one for a search box, and one for the registration.

    Quote Originally Posted by Error404 View Post
    I just took a look at your website and the problem is you're using "/register" for the <form action = "afile.php">...</form> but it needs to be a path and that's the syntax for a folder! If all of it is meant to be passed to the same PHP file, then you only need 1 <form>.
    My understanding of the MVC structure of Joomla is that the "/register" really just posts to the plain index.php and the rest gets figured out from there using these hidden inputs:

    <input type="hidden" name="task" value="saveUser" />
    <input type="hidden" name="option" value="com_virtuemart" />
    <input type="hidden" name="controller" value="user" />

    This means that this is actually posting data to /components/com_virtuemart/controllers/user.php and then inside of that file calling the function saveUser(). Inside of this function is where I print to a log, and the post data is empty when sent from IE9 or below.

  9. #9
    Join Date
    Feb 2014
    Location
    Canada
    Posts
    155
    Quote Originally Posted by newsomjk View Post
    My understanding of the MVC structure of Joomla is that the "/register" really just posts to the plain index.php and the rest gets figured out from there using these hidden inputs:

    <input type="hidden" name="task" value="saveUser" />
    <input type="hidden" name="option" value="com_virtuemart" />
    <input type="hidden" name="controller" value="user" />

    This means that this is actually posting data to /components/com_virtuemart/controllers/user.php and then inside of that file calling the function saveUser(). Inside of this function is where I print to a log, and the post data is empty when sent from IE9 or below.
    I haven't used Joomla before but my guess is that it probably wouldn't look through files recursively until it finds a matching file name. If you had /components/com_virtuemart/controllers/user.php and /components/com_virtuemart/controllers/additionalStuff/user.php, then it would only find a match for the former. I would suspect that it'd look within only 1 directory level based on whatever the root is where the files are contained.

    If it works for other browsers other than IE, then perhaps Joomla is using a newer feature, in which case, you're blocking access to a very large audience. It wouldn't hurt to try specifying the file path and see if that resolves the issue. If it doesn't, then it's time to look in detail at each step along the way.

  10. #10
    Join Date
    Mar 2014
    Posts
    6
    No, the index.php file in the root directly takes the values from task, option, and controller and explicitly loads files based on proper naming conventions. It's not just searching recursively. If the files weren't named properly it would just go to an error page.

    if option is set, it looks in that component folder... so that puts us in root/components/com_virtuemart/
    if controller is set, it goes to that controller php file... puts us in root/components/com_virtuemart/controllers/user.php
    if task is set, it runs that function... so root/components/com_virtuemart/controllers/user.php -> function saveUser();

    If you set the form to post directly to the file, you get a restricted access page. That's how Joomla works. None of these files are intended to be accessed directly. I think it's something with the server configuration but I don't know which configurations would cause this.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles