Under a specific condition, session variables declared in templates exhibit unexpected behavior

[dougwaltman]

I believe I have discovered a very peculiar bug that occurred when I tried to set a single session variable in a template file, "header.php", and call it again after refreshing the page. I have written a quick snippet of code that can be used to replicate the issue. This code will:

• Start the session
• Display some HTML
• Create an array of values
• Shuffle the values
• Display the first value as "new"
• Display the session variable of the last stored value
• Set the session variable to the "new" one

Add the following code to the top of "header.php" in any template:

<?php
session_start();
?>
<link rel="icon" href="<? bloginfo('template_url') ?>/images/x" />
<?php
  $myarray = array(
    'a','b','c','d','e'
  );
  shuffle($myarray);
  echo "<pre>New: ".$myarray[0];
  echo "\nOld: ".$_SESSION['last_one_displayed'];
  $_SESSION['last_one_displayed'] = $myarray[0];
  exit;
?>

After refreshing the page several times, you will notice that the value for "old" isn't matching the "new" value from the previous refresh. The code will behave as expected if you do any number of things, including:

• Change 'rel="icon"' to anything else, suchas 'rel="icons"' or 'rely="icon"'
• Remove the 'rel="icon"' attribute entirely
• Remove the 'x' from the end of the url
• Remove the '<? bloginfo('template_url') ?>' snippet
• Move the '<link...' line below the rest of the code

I suspect that this bug has something to do with the code that compiles and displays the template.

[johnbillion]

I'm going to go ahead and say that you need to try to debug this a bit more Doug. Changing the HTML markup in the page (for example, removing attributes of the link as you suggest) does not and will not affect the value of the $_SESSION variable. Therefore your problem must lie elsewhere.

Additionally, WordPress does not use PHP sessions therefore it won't be interfering with your session variable.

You should disable all your plugins and try the code on a fresh install of WordPress. Posting on the ​Support Forums is also better suited to this as people will be able to offer suggestions and discuss your problem.

[johnbillion]

Also note that I did try your code in header.php of the Twenty Ten theme and couldn't reproduce the issue.

[dougwaltman]

After testing this on multiple WordPress websites with mixed results, I discovered that the issue only occurred on sites using mod rewrite in their .htaccess files.

This led to the realization that the "<link rel.." line of code was referencing a file/directory that did not exist. This was causing WordPress to call the 404 template, which in turn was firing off the code in 'header.php' a second time.

Changing the html to invalidate the tag/properties was causing the browser not to request the file causing the 404, hence seemingly "fixing" the problem.

Developers can avoid this issue by using the "is_404()" conditional.

Please accept my apologies for jumping the gun on a bug report. A little more diligence was required on my part.