requinix

"Range" how? You're hashing the only thing in there that's random so you're not even getting a number out of it.

You just said a lot of stuff that's just mumbo jumbo without context. Update what? XML? Login where?

Either that or use a shebang at the very beginning: #!/usr/bin/php <?php // ...(Your path to the php binary may vary.)

LeadData_Optional corresponds to an object in the WSDL, not a string. It needs to be an (empty) array. By the way that error message is coming from the service, not from PHP. Their code is triggering that error, but it's because of invalid input so they don't care.

What does echo mb_detect_encoding($str, "UTF-8,ASCII"); output? (Before you try this conversion.)

This page may be more useful. Spoiler alert: it's not "UCS2".

Ah, great, then now I can explain what happened. The MultiViews option allows you to omit file extensions (from file types known to Apache) in your URLs. Like "/developers-blog" will automatically map to developers-blog.php. Thing is that Apache doesn't require a directory structure, so "/developers-blog/123" will map to "/developers-blog.php/123" (which is a very valid CGI path). Problem is (1) you have RewriteConds that (rightfully) demand that the requested file not exist, which in this case it does, which could be okay but (2) developers-blog.php can't interpret CGI paths and needs traditional query string variables. Presumably. -MultiViews to turn that feature off, "/developers-blog/123" tries to map to a file 123.* in the developers-blog directory, Apache can't find it, and your URL rewriting rules kick in as you want them to.

Yep, it's displaying the PHP rather than executing it. PHP's not installed/set up. Did you check the instructions or manual for whatever it is you installed?

Odds are it will work with 5.3 too. Have you tried?

The fact that you aren't using one pattern does not make the one you are using an anti-pattern.

You sure it's not already case-insensitive?

What does a SHOW CREATE TABLE members query output?

Escape the quotes. echo '<a href="#login" onclick="popup(\'popUpDiv\')">Login</a>'; echo "<a href=\"#login\" onclick=\"popup('popUpDiv')\">Login</a>";Or concatenate like you almost had. echo '<a href="#login" onclick="popup(' . "'popUpDiv'" . ')">Login</a>';Or don't echo it. ?> <a href="#login" onclick="popup('popUpDiv')">Login</a> <?php

One loop for the rows in the resultset, another loop inside for the different columns in $all_pats. There is probably a cleverer way that I'm not thinking of. [edit] I'm a little concerned about the whole "someone is providing the column names in an uploaded text file" bit. Can you elaborate on that?

file_get_contents() works just fine with URLs. json_decode(file_get_contents("URL"))

Since you want to use existing data you have to say what that data is. Otherwise it'll give you new values.

Okay. Without actually checking it I think the problem is your use of substr(). hexdec(substr($getSKEY,0,), hexdec(substr($getSKEY,8,16)), hexdec(substr($getSKEY,16,24)), hexdec(substr($getSKEY,24,32))The third argument is a length, not an offset.

Try an INSERT...SELECT statement.

Why are you converting from the string into numbers and back into a string? echo implode("::", str_split($getSKEY, ); // possibly with strtolower()

Try with Options +FollowSymlinks -MultiViewsAlso worth noting, # Blog articles. TEST TEST RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^/?developers-blog/([^/]+)/(\d+)/(\d+)$ developers-blog.php?title=$1&id=$2&reply_to=$3 [L,S=1] RewriteRule ^/?developers-blog/([^/]+)/(\d+)$ developers-blog.php?title=$1&id=$2 [L]That won't behave they way I think you think it will behave. RewriteConds only apply to the next RewriteRule so what you have there is not equivalent to # Blog articles. TEST TEST RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^/?developers-blog/([^/]+)/(\d+)/(\d+)$ developers-blog.php?title=$1&id=$2&reply_to=$3 [L,S=1] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^/?developers-blog/([^/]+)/(\d+)$ developers-blog.php?title=$1&id=$2 [L]

None of that code has anything to do with a "user" table...

Because you deleted the old record and you specifically told MySQL to use id=1 again. If you had an auto_increment column (like your example does not show) and you didn't specify the new id value, MySQL would have used id=3.

That's the way to do it. There's something else going wrong.

1. Aren't you outputting the username multiple times too? Shouldn't it just be the stars? If you mean only one of those spans to be outputted you have to use else-ifs so that only one branch works at a time and then rearrange the branches so that the most specific (gold >= 5000) happens before the least specific (gold >= 100). Because if I have 5000 gold then I definitely have >=100 gold too. 2. SHA1 is less secure than it used to be. If you're redoing this then you should switch to a better algorithm like SHA512 or bcrypt. As for the salt, it should be an entirely random string - not some predetermined value already associated with the user. Yes, you do have to store the salt. I strongly disagree with lemmin's comments that SHA1 is "completely fine" and that you "can use the same salt for every password and be safe". I can't let that go.

if ($dow == 0) { $dow = $day + 1;You don't have anything that wraps the last day of the month on Sunday to be the Monday in the next month. Same way you don't have anything that wraps the first day of the month on Saturday to be the Friday of the previous month.