btherl

If that's what you believe the problem may be, try changing those variable names.

This has a good explanation of the problem: http://stackoverflow.com/questions/325933/determine-whether-two-date-ranges-overlap Take a look at the most popular answer starting "Let CondA ..."

The "official" example code for finishing a session is here: http://www.php.net/manual/en/function.session-destroy.php session_unset() is deprecated.

The probability of any two user ids matching would be 1 in 9,999,989,999 using that code, around 32 bits. But because of the birthday paradox, you would have a 50% chance of a collision after around 77,000 users have registered. ( http://en.wikipedia.org/wiki/Birthday_problem#Probability_table ). So the check for generating an already existing user id is important. For this to be effective, you'll have to make sure the real user id is well hidden, and doesn't appear in links on the site, even in the HTML source.

Try accessing $xml->make, $xml->model, etc etc. SimpleXML is exactly that - simple. It may not accurately represent the original XML structure but it works most of the time, and makes the resulting structure simpler in those cases that it does work.

Are you sure this line is correct? $error = ($user_class->level > 101 && $attack_person->level < 1) ? "You can't attack someone that is level 100 or below because you are higher than level 100." : $error; I find the way your code is written a bit confusing. I'm also not sure what you want here - can you give an example of what you expect a normal battle to go like? And what is the $wait variable for?

You really should be using sessions. The login method you are using allows your users to impersonate any other user just by changing the cookie value. I'm also a bit stumped as to why you would be putting the user id from the session into a cookie - if it's already in the session, what benefit is there to putting in a cookie as well?

Instead of var_dump($xml); can you try this please: print "<pre>"; var_dump($xml); print "</pre>"; That will make the structure much clearer.

Ok.. well there are a two main possiblities here: 1. The query you posted is running, and another query changes u_online later 2. The query you posted is not running, and instead another query is changing the other values. Here's some of the things I would try to debug it: 1. Have the script exit immediately after running the query, and see what u_online is set to 2. Comment out the query and see if any other code updates the other columns 3. Comment out all other code which changes u_online and see if u_online is 1 after the script runs.

Do you have another query which sets u_online to 0? In what circumstances is that other query executed?

$_SERVER['HTTP_USER_AGENT'] will usually contain "Firefox" (and other text) if the browser is firefox, so you can check that.

Results are numbered in the order they appear in the select. Since you put userid, parent_first_name and parent_last_name last in the list, they will be numbered 19, 20 and 21 respectively. Alternatively you can use mysql_fetch_array() and fetch columns by name instead of by number. This is generally a better approach, but I don't recommend changing it in your code now as you will end up having trouble due to columns with the same name, such as userid. If you used this approach you would have to use the sql "AS" to rename some columns to different names.

If your db password is plain text, there's no need to use md5 at all: # $password = md5($password); # Skip this if ($password != $password_db) Salts and rainbow tables are a topic on their own, I won't try to explain them here. If you want to find out more about them, you can look for "password salt" in google. The basic idea is that if you use salts, hackers cannot use a precomputed table of md5 passwords to look up the original password. Such a table is called a "rainbow table", so you can also look up that in google.

I think PHP_SELF might not be the right action for your form. What url do you see in the address bar when viewing the register script? You should be seeing the same url in the form action for submitting that script. Or at least the path portion, such as "/register.php"

Can you use this code to display the array instead please: echo "<pre>"; print_r($char_xml); echo "</pre>"; That'll make the structure much clearer.

Try setting this option with curl_setopt(): CURLOPT_RETURNTRANSFER TRUE to return the transfer as a string of the return value of curl_exec() instead of outputting it out directly.

clearVars() takes $j and $k as arguments, but it then modifies $workValue and $workType. Did you mean to have it take $workValue and $workType as arguments? Another alternative is to simply not set $workValue and $workType in the first place when $_POST['submit'] == "Clear". Then you don't need to call a function to clear them. Yet another option is to do the clearing in javascript.

Yes, you need to add md5() to your register script. Otherwise your login script is comparing an md5'd password ($password) to a plain text password ($password_db). The idea is that if someone accesses your database, it will be more difficult for them to recover the password. If you're serious about this you really should use a salt, otherwise rainbow tables can be used to reverse the md5 for some simple passwords.

Since you're using a hosting provider, the first step is to ask them why mail() isn't working.

You're welcome, and congratulations on getting it working

It depends on what you are doing.

I can see your code there .. but how are you refreshing? Are you using a meta tag to refresh? Another method is using header("Location: ")

It'll resume from that exact spot. But keep in mind that external resources like the connection to your database or connection to the web browser may time out if you sleep for too long. Apart from that you should have no problems.

$_SERVER has a special meaning - it contains "server variables". If you put other things inside there then you are changing its meaning. This will confuse other programmers who modify your code later. It also may break code written by other people which you integrate into yours, as they may assume that $_SERVER is used for its intended purpose only. If you will be the only programmer who ever uses your code, then I don't see any problem with using $_SERVER that way. But if I ever maintain your code, the first thing I will do is take those variables back out again It's a maintenance time bomb. If you want a global variable, you can create your own. There's no need to use an existing superglobal. It would be convenient if PHP allowed user defined superglobals, but probably a bad idea, as I think it's better if you're forced to declare globals in each function you use them, which clarifies what external variables that function needs.

Can you "view source" on the form on your register page, and see what this line looks like: <form method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>" It's the contents of the action field that I'm interested in.