My company's website has run into a peculiar issue.

On our quote form we have an HTML5 drag and drop file upload. On modern browsers (>=IE10) everything submits via AJAX with FormData and everything is amazing. However, in crappy browsers and mobile devices (since there is no drag and drop), we simply just provide a standard file upload and submit like a normal form (no AJAX).

if(modern_browser)
{
    // Do modern things
}
else
{
    $('#theformid').submit();
}

The PHP code on the page that's presenting the form checks for the server request method (POST) and then processes the form. Works fine on our local development server and on my localhost.

HOWEVER

On the production server the request method is always GET, even though the form's method attribute is set to post, so the check fails and the page simply just reloads. Not only is it GET, but it doesn't have any of the form's data stored (so I can't even tell the code to take all the GET values and keep moving forward). No PHP errors, no console errors.

We thought it may be a PHP thing since the production server was running 5.4.45, and our development server and my localhost were running 5.5.6 and 5.6.15, respectively. But we upgraded the PHP version on the production server to 5.6.17 and problem persisted. I even thought maybe it was a jQuery issue and tried referencing and submitting the form with vanilla JavaScript but it didn't matter.

The way we got around it was to submit the form via AJAX anyway but instead of using FormData we're simply just submitting regular key:value pairs and removing the file upload option.

Googling has revealed nothing other than a bunch of people telling me to double check the form's method attribute.

Any thoughts? Even though the issue has been "solved" I am still curious what the hell was going on.

Thanks in advance!

    Thanks guys for your replies!

    dalecosp;11053319 wrote:

    The browser's debugger should tell you if it is POSTing or GETting, yes? Any clues from that?

    The page submits and therefore reloads, so any info in the debugger is lost. The only thing I have to go on is what the server receives.

    dalecosp;11053319 wrote:

    On the server, check variables_order and request_order in PHP.ini?

    The variable order was something I compared between the php.ini files and they're identical. Didn't think about the request order, but I am not using $_REQUEST so it shouldn't matter, right?

    Unfortunately the click function already has a .preventDefault() call, so no dice there.

      Bonesnap wrote:

      The page submits and therefore reloads, so any info in the debugger is lost. The only thing I have to go on is what the server receives.

      There should be a config switch in the debugger to make the log persist.

        Bonesnap;11053327 wrote:

        The variable order was something I compared between the php.ini files and they're identical. Didn't think about the request order, but I am not using $_REQUEST so it shouldn't matter, right?

        I suppose not; OTOH, I guess you could use $_REQUEST and say the problem was solved (would feel At Least As Dirty(tm) as the solution you've already said was in place, methinks....)

        Weedpacket;11053331 wrote:

        There should be a config switch in the debugger to make the log persist.

        Chrome's:
        http://i.stack.imgur.com/cFuNP.png

        Firebug's:
        http://i.stack.imgur.com/zlyWY.png

          I've been pulled off this since it's Working As Intended(TM) and probably won't have a chance to revisit it for a while. We are really keen on redoing our site but we just have too much on our plates right now. A good problem to have, I guess.

          Weedpacket;11053331 wrote:

          There should be a config switch in the debugger to make the log persist.

          dalecosp;11053339 wrote:

          Chrome's:
          http://i.stack.imgur.com/cFuNP.png

          Firebug's:
          http://i.stack.imgur.com/zlyWY.png

          I didn't know this existed; thanks for the info!

            Write a Reply...