Daniel0

I don't understand...

Yes, it's turned off by default in PHP5 and completely removed in PHP6 (not released yet).

Add ORDER BY field DESC to your query. Replace field with the field you want it ordered by.

Take a look at these documents: http://www.php.net/manual/en/migration5.php http://www.php.net/ChangeLog-5.php http://www.php.net/ChangeLog-4.php

It does run when it's loading...

It appears the reason is that all other browsers except for FF2 makes a linebreak at the hyphen in <span style="text-decoration:underline">underline</span>. This forces the table to be wider in FF2. There probably isn't anything I can do about it and seeing as this is a problem uniquely belonging to that specific table I won't do anything about it. It's an internal page meant for authors (i.e. not the general public) so those few persons who are authors and using FF2 will have to live with it. Btw, I had to switch back to FF2 to diagnose the problem. All I can say is, if you haven't upgraded to FF3 yet, do it, even when it's only an RC. Much faster, looks better and has better OS integration and handles memory more efficiently than any other browser. Anyways, this topic is not supposed to be a browser debate.

The issues with staying logged in should be fixed. The reason was that SMF was overriding the PHPSESSID cookie thus logging people out on the main site. I fixed this by changing the name of the cookie the sessions use to phpfreaks_session for the main site. Edit: Duplicate headers have been removed as well.

Oh those... I thought it looked ugly if I removed either :-\

I'm aware of that. I'm not sure why it's doing that. It doesn't happen on the development server, nor on my localhost. I'm working on figuring out why. I'm not sure I follow...

That's strange. I'm using FF3, so it must be due to changes in the rendering engine. I'll take a look at the CSS later.

Looks fine here. Could you provide a screenshot?

Oops... It has something to do with how content is organized in the database and how the search algorithm indexes it. Anyways, it's fixed now.

Hmm... that could work. I'm also planning on making a code snippet repository which will be open for user submissions as well. Actually it's already half-developed.

Sorry, that will not happen. This is also related to the guru discussion and the thing about removing post-based ranks. We would like to ensure that good content is being posted to the main site and we cannot ensure that by allowing everybody to post. By only allowing people who we have selected ourselves, then we can be more or less certain of the level of quality. I'm not saying that anybody who is not in a special group is crap, but it's the best solution we've been able to come up with.

http://recaptcha.net/ That's an API though, but still very good.

It should be fixed now. By the way, don't even bother reporting layout issues for Internet Explorer 6 and below. They will not be fixed (not by me at least).

Release post

Nice find. I'll sticky this for further reference.

Those two functions will counteract each other It accomplishes nothing except wasting resources.

And turn them off when the script is running on a live site. Expose as little information as possible to potential attackers.

Try $encrypted_password = (string) $db->getOne("SELECT password FROM users WHERE username = '$_POST[username]'"); If that doesn't work, then (on your original code), try to put var_dump($encrypted_password); before the if and post what it says here.

No offense, but I find it rather strange when people have a question like "What did company X do to do Y?" and then decide to ask us instead of the company.

That is essentially what a cookie is. Take a look at the HTTP protocol again and try to monitor the headers sent between your browser and the server. You'll notice that when initializing a session, the server will have a Set-Cookie header which sets a cookie called PHPSESSID. On the following requests your browser will send a header called Cookie containing that (and possibly other) cookies. If cookies are not available, then it will be passed in the URL.

Not quite. See my post above and then check out my stats. If it was like you explained, then I have used over 100% time on PHP Freaks - something which is not possible.

Whether there is an error or not depends on what the expected behavior is seeing as there is nothing syntactically wrong with the snippet. Sometimes infinite loops are what you want, so they are not per definition errors. However, in this case it would be questionable whether an infinite amount of "Hello"s should be outputted. Furthermore, the usage of the HTML line break tag indicates it's to be on a web server and be served to a web browser. Seeing as the response would never be able to be sent to the client if the code never stops executing one can conclude that, yes, there is an error in the script.