requinix

Yep.

Really? Because there's actually a problem: timer is always null. Move the var timer outside the click() handler and rename it to something more specific than "timer".

clearInterval() needs the timer to stop it, not the code to execute. Including a couple other fixes, $("#play-pause-button").click(function(){ var timer = null; if(timer == null){ timer = setInterval(goForward, 5000); $("#play-pause-button").html("").load(function(){ $("#play-pause-button").val("on"); }); } else { clearInterval(timer); timer = null; $("#play-pause-button").html("").load(function(){ $("#play-pause-button").val("off"); }); } return false; });

Ah, the other way. Besides Psycho's code (which is how I'd do it), you can UNION two queries: SELECT the ones that are 0000-00-00 and tack on the ones that aren't (and are before today's date).

That's weird but not impossible (clearly). Before we start looking at the more unusual explanations, can you post the code you're having problems with?

border isn't deprecated. cellspacing can be expressed in CSS with border-spacing: border-spacing: 0px; However you might be looking to "collapse" the borders, for which you'd use border-collapse: collapse; instead.

This topic's house has been seized by the bank and it now lives in MySQL Help until it can get back on its feet. http://www.phpfreaks.com/forums/index.php?topic=358035.0

Add a condition for the date: either it's "0000-00-00" or it's on/after today's date. Then a normal ORDER BY should take care of the rest.

stripslashes() is about making sure PHP's old magic_quotes setting (if present) does not screw up the submitted value. If you don't stripslashes() and magic_quotes is on then characters like apostrophes and quotation marks will have backslashes to "escape" them. But you do your own escaping so it ends up that the backslashes come in literally and you end up with people's names like "O\'Brien". mysql_real_escape_string() makes a string safe for inclusion directly into a SQL query, so long as you put it in quotes. It does not affect what the data is - only how it is represented in the query. Those two happen on the input side of things. When you're inserting data into your database. When the data comes out and you output it into something like HTML or XML, it might not be safe. For instance, it could contain s and at the worst means someone can insert arbitrary HTML into your page. Just like how MySQL has mysql_real_escape_string() there is the htmlspecialchars() function for HTML (and XML). That escapes s and quotes so that the string couldn't possibly affect the markup of a page. That's a good function but for HTML (only, not XML) there's a better function: htmlentities(). Besides doing everything the other function does, when used properly this one will make sure the output doesn't contain any "invalid" characters. For example: á. Your page might not use a character encoding that supports that character so htmlentities() will turn it into á - something that will always work because it represents the á character not as bytes but as "an 'a' with an acute". Correct, and do it just before you echo it into the HTML as a code safety measure. Databases should contain raw values in their original form. Using htmlentities() means you've corrupted the data and turned it into an HTML-safe string. For a lot of purposes that's okay because the data will only go back into HTML later on, but it's not okay because of the other things you might want to do to it. Common examples: - Insert the data into an RSS feed (which is XML). XML doesn't support HTML entities like á and will barf if you try to use one* - Measure the string length. If you were to impose a maximum string length of 10 characters, and someone enters "páginas" the length check will incorrectly fail because it measures "páginas" (14 characters) instead of "páginas" (7 characters) - Use the value in AJAX. If the code treats the AJAX results as text strings (as opposed to HTML strings) then you might end up with "páginas" literally in the HTML. * It's possible to include a definition of HTML entities, and that would allow you to use entities, but it's work that you don't really need to do. There's also a risk of XML parsers that aren't aware this kind of thing is possible.

You can do it inline. Most of the time you should use classes and selectors to get what you need, such as naming the table with class="controle", but occasionally it makes sense to do a bit of styling inline with the element. Like now. "</pre> <table style="'background:" forminputs>"</

It's the quoting you have on those HTML strings, not the HTML itself. PHP allows you to embed variables in strings because it can use the "$" to recognize there's a variable. JavaScript has no such feature. To put a value into a string you have to stop the string, add the value, and begin the string again. "</pre> <table bgcolor=" + formInputs[" farg>"</ There are a couple other things I should point out now (there are a couple things that aren't as important to mention yet): - Don't use the language attribute on script tags. Using the type is enough. - document.write() will do weird things. If you want to create the table inside the div#table (because it shouldn't go inside the p#tableID) then actually put it in there; the cheap way to do that is using .innerHTML: var table = "</pre> <table bgcolor=" + formInputs[" farg>...</table>";<br>document.getElementById("table").innerHTML = - bgcolor is deprecated. Use CSS's background(-color) instead.

That's JSON. decode it then loop through the stats array doing whatever you want.

Put the name and whatever else you may want into the session, then redirect to the certificate page. That page then uses the name and whatever else you put into the session to display the certificate. Have you used sessions before?

If you want to call an object's function you have to use $this-> (for instance methods). $this->deposit($dep);

What you said in your first post made it sound like you didn't want to use any event handlers at all, not that you simply didn't want them on the . What's the structure of your HTML and where can you make changes?

So... you want to detect keypresses without using anything that will let you detect keypresses?

- stripslashes() at the beginning but only if magic_quotes is enabled. - mysql_real_escape_string() for string values just before you stick them into the query. Use typecasting or numeric functions (eg, intval() and is_numeric()) for non-string values. Or you can validate the input to ensure it couldn't possibly contain any SQL injection. - htmlentities() or htmlspecialchars() right when you output stuff into HTML. - json_encode() right when you output stuff into JavaScript (or as JSON). Note how addslashes() did not make that list.

From inside your network you should use your internal address. Or even better, the hostname of the computer. Set up port forwarding on your router: have it forward port 80 to your computer. Note that you may need to give your computer a static address lest DHCP change it up and break the forwarding, but whether you need to do so depends on your router and what it lets you do.

The easiest solution would be to simply whitelist the address the emails are coming from. Beyond that, email filtering is a complicated beast. Switching to code that constructs emails properly (for example, PHPMailer) will probably make the emails look legitimate enough to get through.

Then I would bet there actually are errors. Did you also make sure that display_errors is on?

The line with formInputs is fine, but the stuff after it isn't. 1. formInputs is a variable. It is not located inside document so document.formInputs won't work. Just call it by its name. 2. formInputs is already the elements collection. You don't need another .elements[] on it.

'$path' Variables don't work inside single-quoted strings. Not that you need them at all... include('SimpleImage.php'); $image = new SimpleImage(); $image->load($path); $image->resize(60,60); $image->save($path);

Or the more direct round($number, 2)

And there's yet another method. Since URLs look kinda like file paths, basename(trim($url, "/")) (Of course this doesn't validate the rest of the URL. Only grabs the last component of the path.)

Just a question about the SQL, or is there a problem with the HTML form(s) too? Exactly what you do depends how you handle blank answers. If you store them then just use a normal JOIN since the data does necessarily exist. SELECT q.question_text, a.answer_text FROM question q JOIN answer a ON q.id = a.question_id... If you don't store the answer at all then you'd need a LEFT JOIN because the data might not exist and you still want to know the question. SELECT q.question_text, a.answer_text FROM question q LEFT JOIN answer a ON q.id = a.question_id... (Note how they're identical except for the added "LEFT")