SitePoint Sponsor

User Tag List

Results 1 to 5 of 5
  1. #1
    SitePoint Member
    Join Date
    Jun 2005
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    PHP breaking in Firefox (does browser matter?)

    I operate a PHP/MySQL-based reviewing site for an academic textbook publisher. We post production-phase artwork for their books, and reviewers login and post critiques through a series of HTML text-entry forms (submitted to MySQL).

    When the site launched a year ago, I'd tested thoroughly in Windows 2000 and XP with Internet Explorer 5.0X, 5.5 and 6.0X (and 5.2.3-Mac) and Mozilla 1.7X (Win & Mac). As expected, most reviewers are Win-IE users so they've reported no serious problems.

    Of late, though, I'm getting more problems from Firefox (Win & Mac) and Safari users. Something is breaking my form "submit" function. Users are returned to an "empty" form page (no variables, PSP session & MySQL link broken), rather than proceeding to the scripted confirmation page.

    I'm able to reproduce this on my testing server with Firefox 1.0.3-7 and any version of Safari. PHP's error reporting returns a slew of "Notice:" errors for undefined indexes and variables, that when tracked down, all appear to be fine. When I add the "print" function to my scripts, every listed item successfully prints it's value.

    I've noticed that quite a few errors cleared up when I converted some form variables from the PHP shorthand syntax (value="<?=$foo?>") to the more formal (value="<?php echo $foo; ?>").

    Should I be using PHP's htmlspecialcharacters() function or define the HTML_ENTITIES constant to convert entities (value="&lt;?=$foo?&gt;") in my scripts nowadays to accommodate the stricter HTML compliance of newer browsers? My HTML doctype is 4.01 Transitional.

    I've been told that none of this make sense -- that with PHP and server-side scripting the work is essentially done before it's sent to the browser, so what browser is running shouldn't matter. All I know is that nothing breaks when IE is the browser.

    I can and should post some code, but was wondering if I'm even on the right track with this. Does the browser make a difference with PHP?

  2. #2
    SitePoint Guru enygmadae's Avatar
    Join Date
    Sep 2002
    Location
    Dallas, Tx.
    Posts
    795
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It could be a difference between how they're handling the values in $_GET and $_POST and what you're looking for. You mentioned a lot of "notice"s - are they for undefined indexes when the page submits?
    PHP News, Views and Community: http://www.phpdeveloper.org

  3. #3
    SitePoint Member
    Join Date
    Mar 2004
    Location
    NorthWest USA
    Posts
    19
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is your code valid with no errors according to http://validator.w3.org/?

  4. #4
    SitePoint Member
    Join Date
    Jun 2005
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by enygmadae
    It could be a difference between how they're handling the values in $_GET and $_POST and what you're looking for. You mentioned a lot of "notice"s - are they for undefined indexes when the page submits?

    Yes, undefined indexes and variables when the form is submitted, but I do know why I'm getting those notices, though. I'm using output buffering, and flushing the data before proceeding to the confirmation page on "submit"...

    <?php
    mysql_close();
    ob_end_flush();
    ?>

    So, when the connection breaks in Firefox or Safari and the form reloads, there's no data available. I've been using PHP's print function to check each variable and/or index, and can confirm that all of the data is loading as intended when the form loads initially. I just can't submit the form and have to figure out where it's breaking.

    The missing data in question loads from 1 MySQL table, which contains the artwork and associated text data being displayed with the form. My form uses the post method, set as...

    <form action="<?=$_SERVER['PHP_SELF']?>" method="post">

    On "submit", the data gets passed and processed through 3 other included scripts, so it must keep returning to the same form/page before it finally posts to MySQL and redirects to my confirmation page.

    Throughout the process, data is passed page to page (or script to script) as URL-appended strings, like so...

    check_answers.php?rvwr_id=$rid&fig_id=$sfigid&fig_no=$sfigkey...(etc.)

    But here's what I'm wondering about. My HTML syntax-checker (BBEdit) has always warned me about encoding HTML entities in URL strings and PHP code bits, but I've never been sure whether doing so will cause trouble for PHP.

    For better HTML compliance, should I be converting my PHP code to...

    <form action="&lt;?=$_SERVER['PHP_SELF']?&gt;" method="post">

    ...and...

    check_answers.php?rvwr_id=$rid&amp;fig_id=$sfigid&amp;fig_no=$sfigkey... ?

    I've already had to make use of PHP's str_replace() function (and "magic_quotes" more than I care to admit) to fix text oddities with MySQL -- but that's another issue. Right now, I'm more concerned with my PHP scripts working in the new breed of web browsers.

  5. #5
    SitePoint Member
    Join Date
    Jun 2005
    Posts
    8
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by bob9999
    Is your code valid with no errors according to http://validator.w3.org/?
    It's a file with a .php extension, so that didn't work...

    Result: Failed validation,
    File: quiz_v.php
    Encoding:
    Doctype:

    Sorry, I am unable to validate this document because its content type is application/x-php, which is not currently supported by this service.


Bookmarks

Posting Permissions

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