requinix

You have to link to the new URLs, not the old ones. In order: probably, yes, and I'm not sure what you're asking but the answer is probably "yes" too.

onmouseout and onmouseleave are two different events. It's not jQuery's fault you didn't know the difference.

Cookies have a very important drawback: the user can see and edit them. Don't put sensitive information in them because if there's a vulnerability on your site then a malicious user might be able to grab that information from an innocent user. Also don't assume that what you put in there will stay intact because things like user IDs and privilege levels could be changed, and unless you verify that the information is correct then it cannot be trusted. (Just like $_GET and $_POST.) Also keep in mind that you can only have one value for the entire site, so storing form values (for example) means you could only remember the one form at a time. If you're considering using a cookie for something, think harder and about whether it would be better/more appropriate/safer in a session value instead. Under 99% of configurations, session values are stored on the server and thus safe from tampering.

Actually no. There are two types of variables: superglobal variables and normal variables. The superglobals are true "global" variables; they are $_POST, $_GET, $_SESSION, and the other similar $_ arrays. They are accessible absolutely everywhere. Note that you cannot define your own superglobals. Everything else is just a normal variable. There are two levels of variable scope: function (inside a function) and file (outside a function). When you define a variable in one it's available to everything else afterwards but only while in the same scope. Variables outside a function are not available inside a function, and vice versa. This also includes nested functions such as closures. There are three exceptions to these rules. 1. Inside a function you can access a variable defined in the file scope with the "global" keyword or the $GLOBALS array (which is a superglobal). This is strongly discouraged. 2. Class functions can access class variables by using $this. Technically this isn't an exception but it looks like one. 3. Closures (aka anonymous functions) can access variables defined immediately outside it with the "use" keyword. Classes could be called a third scope but IMO they aren't. To answer the question, A. Each time PHP starts executing the first file (that is, only the very first file and not any others that may be included) it starts from scratch, creates the few automatically-defined things (like $_POST and $_GET), and runs your code. So even if you defined a variable earlier you can't get it because it was "lost". If PHP were drawing on a whiteboard, it would draw variables and functions and all that and then erase the whole board when it was done. The next time it starts drawing it has a clean slate. Sessions can emulate the B option. It is not actually that: the variables aren't preserved across each script. What PHP does is have a special $_SESSION array and, when the script is done, it (separately) stores everything you put in there. When PHP executes the next file it looks up what it remembered and reconstructs $_SESSION.

You named four.

[edit] Nevermind that. Only thing I can think of is TTF support on the server. phpinfo() should include a section on GD: what does it say?

Okay, the alternative: Save the image somewhere and open it with Notepad (or some other text editor). Do you see any error messages?

...and the second-most important part is the echo at the bottom. But leave off the htmlspecialchars() part, that shouldn't be there.

Without the header() you should only be seeing the raw binary data. You should not be seeing any image at all.

Personally I prefer outputting the XML manually, but that's irrelevant. The most important part of xyph's example is the header(). Without it the browser will think the output is HTML. Which it isn't.

The time is calculated according to your server. Not according to where the user is. The only way it would be like that is if your code specifically altered the timezone PHP was using to calculate dates. gmdate("YmdHis") for starters, making sure that the timezone is the server's timezone and not the user's.

Comment out the header() and look for error messages.

This topic has been FUS RO DAHed to PHP Regex. http://www.phpfreaks.com/forums/index.php?topic=358571.0 (I've got Skyrim open on the other monitor)

You need a $ anchor to ensure the expression matches the entire string, rather than just an initial length of it.

The problem isn't that you're not using CSRF tokens, That is the problem. As a user I find it distressing when the person/people maintaining a site I use simply don't care. You just shrug off spam? That shows you have no interest in the health of the forum, and if you don't care then why should I?

I don't see how that script could cause high load. Only if it was being used a lot - generating most of the traffic and taking most of the processing time. By the way, that script allows anyone to download any file on your server. MP3 or not. I can just change the file name to anything, like force-download.php?file=force-download.php

So the line of code is $this->error[] - "The E-Mail that you provided is not valid."; Take a closer look at it.

The first URL would be easy if /SS.php didn't actually exist (like it was in an include/ directory or something). RewriteEngine on # does not exist as a file RewriteCond %{REQUEST_FILENAME} !-f # does not exist as a directory RewriteCond %{REQUEST_FILENAME} !-d # rewrite any /*.php through index.php RewriteRule ^[^/]+\.php$ index.php?page=$0 [L] If it does exist then the second URL would be easier because then you could assume anything in /pages/ is supposed to go through /index.php. RewriteEngine on RewriteRule ^pages/(.*)$ index.php?page=$1 [L] And FYI, Your first try causes a loop. The first time through it will rewrite every file in the root to index.php. The next pass will rewrite index.php back onto itself. The next pass will do it again. And again. Contrary to popular belief, [L] does not stop rewriting entirely. The second one... I'm not sure what you expected it to do. The URL will still be "/page/file.html" - that won't change. Are you talking about how "/index.php?page=file.html" URL doesn't change?

Can't do it as you've stated. You have to give up one of the requirements. Either a) Use multiple queries (one for the question, one for the choices of each question). This is bad so don't do it. b) Allow the question information to be repeated in the results. Have the code deal with it. c) Another option which I won't mention because it's even worse than (a).

I can't tell if you answered my earlier question so I'll ask it again:

So does it work or does it not work?

Sessions are not for keeping things out of the URL. It's not what they're for. It's part of how they work and not why they work. Nothing in the URL? Then use a POSTed form.

Simple: don't use a session variable for it. Stick in the URL. script.php?dir=foo/bar/baz Be sure to validate it before you use it blindly.

Doing it beforehand is nice and all but is not a substitute for doing it on the server.

No. And it wouldn't make sense for there to be one either. It'd be a nightmare to work with in the code too. How many tables are you talking about? What are they for?