Very Basic Login Script
 

Hey guys, I have this simple Login script which I have recently converted from asp. It worked fine as ASP but there are a lot of problems with the PHP.

There are quite a few errors in it, the message I get at the moment is Parse error: syntax error, unexpected T_ELSE

I can definitely tell this was converted from a vB style language.
PHP is a C based language, the syntax you have isn't correct. Anytime you make a comparison, you must use ==, as = in PHP is an assignment operator.
The other thing is the lack of braces. PHP allows non-braced branches, but will only apply for the next processing instruction or contained branch. Use full braces always to prevent confusion or ambiguity especially while reading. Alternatively (though I don't actually recommend this since PHP should reflect a C based language), you may use the alternative syntax in PHP which will more closely resemble the ASP code (though the comparisons will not be changeable).

Next, variables in PHP are case sensitive: $_SESSION is not the same as $_Session. The array accessing is correct, you should always write associative indexing in strings, though I will suggest to always use single quotations when using a constant string since its faster than double quotations which require parsing; however, $varname($offset) is not actually an array access, it is a variable function (asp may have them called under delegates), which isn't what you want.

Since PHP is datatype weak, you needn't actually check a resulting boolean in a branch if you don't want to. if ($var == true) is the same as if ($var), assuming $var is a boolean.

Finally, you must use session_start(), preferably at the start of every PHP page you intend to use sessions on.

that was true maybe 5 years ago, but nowadays there is no significant difference when using either quotation mark.

Agreed with what Fou-Lu said.

Dormilich, why would that no longer be true? Granted I don't have any documentation but it seems logical to me that using single quotes instead of double quotes would be slightly more efficient. Particularly when dealing with a string constant because the PHP Parser would know that the data between the quotes is not a variable and thereby not attempt to convert it to it's value before parsing.

some folks have just tested it: http://phpbench.com/ (last-but-one section)

You had made me curious so I decided to write a test of my own before I saw your post. You can see the code below and view the results at http://www.distortedperception.org/t...wer/quotes.php

you’re comparing apples with pears. doing an actual replacement must take longer than just parsing the string. what Fou-Lu said was "string" vs. 'string'.

I stand corrected that I my test code was not quite for the same issue, was on the phone while writing it... After adjusting the test script accordingly it would seem that there is not a measurable difference between the two.

reality always wins over theory.

That was a bit spiteful don't you think? If that's how you react when someone asks a valid question I'd hate to see how you treat a n00b that doesn't know how to use the [code] tags.

it wasn’t directed to you (or someone from this thred) specifically, it just sounded like something worth citing (only I didn’t have real content to append it to)

there’s always the report button to make a moderator fix them

Thanks. I did everything you suggested & my browser says there are no errors, but it does not work. when I enter in my details to the login field and press submit, it just gives a blank area where it is meant to say my website is at www.stick-webs.99k.org

what does the updated script look like?

The tests do indicate that any double quoted text is still slower than single quoted text, but that is to be expected. There is really no way to get around this, as long as PHP persists in expanding double quoted strings, it will always take more cycles to process. Personally, I'd prefer that PHP took double quotations as straight strings (non-expanded, though still continue to expand escaped chars), and single quotations as chars only, but that would also never happen (PHP is a string based language, it doesn't really have the concept of just a char, which of course is the exact opposite of its C driven engine which has no string).
The difference of course being that machines are much more powerful nowadays than they were 10, and even 5 years ago, and really don't need to worry about this; is saving 3 - 30 nano-seconds of processing really worthwhile? Nope, definitely not. The most interesting benches there are the last two of the single vs double tests. I'm a little surprised that \$ indicates a slower parse than the $ alone, which almost looks like they are evaluating it from the inside out instead of the outside in.

So really, it simply comes down to a personal preference on this; choose one and stick with it. Chances are you'll never need to script PHP on a legacy machine. Mine is to stick with the single quotations (I remember back to my 16MB web server back in the day on a P2 300, optimization really did a lot back then), and so I will continue to recommend the use of single.

One thing to mention about these benches. Some of them need to be taken with a grain of salt. They have a test for $obj = $someClass->f() vs. $obj =& $someClass->f() , but the usage of return by reference isn't acknowledge as the reasoning. If the result is returned by reference, than it must act as a reference. Since they don't mention the PHP version in use, the & should for sure be omitted in PHP5 UNLESS the method itself is slated as a return-by-reference method (ie: public function &f()); the only thing that is always returned by reference in PHP5+ is objects; PHP4 on the other hand would need to act a reference even if the returned result is an object. Otherwise, PHP's copy-on-write techniques make standard non-reference assignments as references useless as there will be no extra consumed memory until the variable has been rewritten (if that makes sense >.<).

That out of the way, as Dormilich mentioned, we do need to see your updated code to determine where the problem now lies.

This is the updated script