Daniel0

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.

Where does it store it?

If you use Linux, then you can use ffmpeg.

Just convert them to flv on the server.

I think it's talking about how many of the total posts in that particular board are created by you. The two top ones for me are PHP XML (a temporary tutorial board) and Forum Maintenance (a recently created hidden board). For me it says respectively 100% and 28%. That fits perfectly with the percentage of posts I've created in those particular forums.

That will use twice as much bandwith. First your server will download it from the remote server, then it will upload it to the client requesting it.

Well, you just don't have direct access to them at least.

I'm sorry that I offended you. I still believe that you have that opinion because you lack the sufficient knowledge about the subject. I was, and am, trying to give you part of that knowledge. At the end of the day, what this site is essentially about is learning. I don't know if you use or have used Gmail, but if you try to compare the responsiveness and overall experience I'm certain you'd be much more pleased to use the Javascript version than using the basic HTML version.

Try http://cboard.cprogramming.com/

Well, I meant that just because there is something you cannot do, then it might not be the language's fault but your fault. As demonstrated above, the example script works both with and without Javascript, but it's more sleek with Javascript on.

We haven't dropped the competitions. Not permanently at least.

I prefer a terminal with access to the root user :-\ How did you come to that conclusion?

Copycat. Heh... I read your post as a question, not as a statement. I see now I was mistaken. Sorry about that. It depends on what you need to do. Generally a security issue consists of three things: an asset, a hacker and a vulnerability. All three has to be there... If there is no asset, then nobody bothers with you. If there is no hacker, then there is nobody to exploit your system. If there is no vulnerability, then there is obviously no way of exploiting it. What does this mean? It means that if all your users are completely trusted, then you don't have to bother with securing it and the level of trust should reflect the things users are allowed to enter into your textarea (or at least how it is represented when outputting it again). You could do various things. You could make a whitelist of HTML tags and attributes and convert everything which does not conform to that list to HTML entities. You could implement another language such as bbcodes. Generally though, if you're looking for just simple protection, then htmlentities() should do quite fine. When it gets complex (at least to some extent) is when you want users to be able to format the input but you do not trust them.

printf() is short for print formatted, i.e. it formats a string (so does the related functions in various manners). In itself it's not a tool for protection, but in your specific instance it does provide some level of security against SQL injections. %d signifies an integer which means that it will be substituted with and, if needed, converted to other an integer. Because integers do not pose any security risk regarding SQL queries, you have protected yourself from injections. Had you used %s, then you wouldn't have protected against anything at all. You might want to look into prepared statements (see: http://php.net/manual/en/pdo.prepare.php).

Well, obviously there are certain requirements that must be fulfilled. Simply wanting it (whether you express it openly or not) does not yield a promotion. It works like we have a topic in some hidden forum where members can be nominated. If enough people agree then a promotion will take place. The recommended position is not that easy to get it. That's also the reason why the last promotion to that was about half a year ago.

Tom told me we ran out of diskspace. We're trying to work out a good solution for backing up the database without using all the diskspace. We're sorry about that.

I could name a few people who does have a lot of posts but certainly are not good. Instead of getting inspired to get a new post count based rank you could get inspired to become a guru or even recommended.

The reflection classes can read DocBlock style comments. http://php.net/reflection

Right, so I forgot to tell WHY the above would be a good idea. By completely separating the Javascript and HTML you'll have easier maintainable code as it will not be all mixed up. Also, if you look at the Javascript and the link, then you'll see that the link actually has a href, but the Javascript attaches a click event to the link and returns false so the link will not be followed. This means that the users who have have Javascript off or are using browsers which are not capable of handling Javascript will still be able to use the application. However, the users who can use Javascript will experience the application as being more responsive and will probably have an overall better experience. It will also save some bandwidth seeing as in this case the response from the AJAX will be something like {"success":true,"new_number":18} which is 32 B long, where as a loading the page will be 551 B (approximately 1722% larger). On a very busy site with many such things, the savings could be significant.

Actually they'll be where moderation actions are located. I.e. if you see the blue bar where there is the "Jump to:" option, then the button is attached to the top of that bar.

I'll put up a live example later today. Edit: http://phpfreaks.com/daniel/unobtrusive_javascript/ Files/source of interest: http://phpfreaks.com/daniel/unobtrusive_javascript/index.txt http://phpfreaks.com/daniel/unobtrusive_javascript/lib.txt http://phpfreaks.com/daniel/unobtrusive_javascript/backend.txt http://phpfreaks.com/daniel/unobtrusive_javascript/script.js

As I said in the other topic, it depends on how the programmer uses it. Sure, if you program it in a way so the site is dependent on having Javascript on, then it's not a good thing, but as I also said, it's not the language's fault that the programmer uses it poorly. If you properly separate the layers (content (HTML), presentation (CSS), behavior (Javascript)) and use unobtrusive Javascript then I believe Javascript can lead to richer user interfaces. I believe that the picture redarrow has of Javascript is more a shortcoming of himself rather than of the language itself. If you want me to elaborate further, please say so and I'll be happy to give you a working example.