Strange PHP/MySQL behavior

[Kyle James Matthews]

I am working with the following script for a weblog that manipulates any
combination of two variables: $postauthor and $archive.

if (isset($HTTP_GE T_VARS['archive'])) {
$archive = $HTTP_GET_VARS['archive'];
if (strlen($archiv e) > 15) {
die("Sorry, the system cannot process your request. Please contact the
webmaster.");
}
} elseif ((isset($HTTP_P OST_VARS['archive'])) &&
($HTTP_POST_VAR S['archive'] != "")) {
$archive = $HTTP_POST_VARS['archive'];
$archive = str_replace("_" , " ", $archive);
}

if ((isset($HTTP_P OST_VARS['author'])) && ($HTTP_POST_VAR S['author'] !=
"")) {
$postauthor = $HTTP_POST_VARS['author'];
}

if ((isset($archiv e)) && (strlen($archiv e) == 4)) {
include "./archives/$archive.php";
} else {
if ((isset($archiv e)) && (isset($posauth or))) {
$postquery = "select authors.name, posts.postid, posts.date,
posts.time, posts.subject, posts.text
from authors, posts
where authors.authori d = posts.authorid
and posts.date like '%".$archive. "'
and authors.name = '".$author." '";
} elseif (isset($archive )) {
$postquery = "select authors.name, posts.postid, posts.date,
posts.time, posts.subject, posts.text
from authors, posts
where authors.authori d = posts.authorid
and posts.date like '%".$archive."' ";
} elseif (isset($postaut hor)) {
$postquery = "select authors.name, posts.postid, posts.date,
posts.time, posts.subject, posts.text
from authors, posts
where authors.authori d = posts.authorid
and authors.name = '".$author." '";
} else {
$postquery = "select authors.name, posts.postid, posts.date,
posts.time, posts.subject, posts.text
from authors, posts
where authors.authori d = posts.authorid
order by posts.postid desc
limit 10";
}
getPosts($postq uery);
}


The variables are assigned via drop-down menus. Each menu has an option
whose value is "".

This all works very well. The first time the page loads it recognizes
that neither variable is set and does the appropriate thing. Setting
either or both of the variables returns the correct items as well.
However, if you load the page, set neither variable, and click "Go" it
returns every post in the database (only 2 months) in ascending order.

When I echo the query it is using, I find that it is using the query as
though $archive were set, and coming up with the string:
"select authors.name, posts.postid, posts.date, posts.time,
posts.subject, posts.text
from authors, posts
where authors.authori d = posts.authorid
and posts.date like '%'"

Thus the behavior is expected, but I don't understand why the script
acts as though $archive had some value, or why the same problem never
occurs with $postauthor despite being set by an almost equivalent
statement, or why it works correctly the first time the page loads! As
you can see, when the value "" is chosen, the script is told not to
assign any value to the corresponding variable.

This behavior can be observed at http://www.digitalovertone.com/weblog/

Many thanks,

Kyle

[Kyle James Matthews]

Re: Strange PHP/MySQL behavior

So, ignoring the misspelled variable 'posauthor' (which breaks something
else and is now fixed), I have corrected this the long way. The problem
occurred on my web-hosting server, but not on my localhost. I would
still be interested in know why the variable ever gets set on my server,
if anyone can explain.

Thanks,

Kyle

[Brion Vibber]

Re: Strange PHP/MySQL behavior

Kyle James Matthews wrote:
[snip][color=blue]
> Thus the behavior is expected, but I don't understand why the script
> acts as though $archive had some value, or why the same problem never
> occurs with $postauthor despite being set by an almost equivalent
> statement, or why it works correctly the first time the page loads! As
> you can see, when the value "" is chosen, the script is told not to
> assign any value to the corresponding variable.[/color]

Looks like you have register_global s on: when an empty 'archive'
parameter is submitted in the form posting, the global variable $archive
is set to "". This is ignored by your first if statement, so the later
check for isset($archive) comes up true.

-- brion vibber (brion @ pobox.com)