So it turns out that if you take a notion to create a crossword puzzle, put it on your blog, and include a “submit” button so that solvers can send you their answers, then — at least if your skill set is similar to mine — writing the code to make that “submit” button work will be about twice as difficult and three times as time-consuming (but perhaps also several times as educational) as actually creating the crossword puzzle. I certainly learned some hard lessons about the difference between POST and GET. But it’s done and (I think) it works.
To do the puzzle online click here. For a printable version, click here. If you do this on line and want to submit your answer, use the spiffy “Submit” button! (And do feel free to compliment the author of that button!). The clues are subject to pretty much the same rules that you’d find in, say, the London Times or the Guardian.
I will gather the submissions and eventually give proper public credit to the most accurate and fastest solvers. Feel free to submit partial solutions; it’s not impossible that nobody will solve the whole thing.
Let’s try to keep spoilers out of the comments, at least for a week or so.
I have one very geeky addendum to all this, leading to a second Monday puzzle — one that might be easy to solve for a reader or two, but most definitely not for me. Unless you’re a very particular brand of geek, you’ll probably want to stop reading right here. But:
Edited to add: Never mind! The problem is solved! See comments at bottom.
***********
Those who are attuned to these things might notice that this puzzle is hosted at my account on panix.com, not here at The Big Questions like everything else on this blog. There’s a reason for that: My code works on the panix server, but not on The Big Questions server. I’d love to understand why.
Please keep in mind that as a coder I am a rank amateur, I know almost nothing, and I am groping my way in the dark. That said, the issue comes down to this:
1) I have a file called, say, foo.php, which contains the following (except that I’ve substituted round parentheses for pointy brackets so this won’t render in your browser):
(form method=POST action=foo2.php)
Enter your nickname: (input name=”nick”)
(input type=”hidden” name=”prog” value=(? echo $prog ?) )
(/form)
2) Let’s suppose a user enters the url “foo.php?prog=abc”
3) Now foo.php believes that the value of $prog is “abc” (and I can confirm this by having it echo $prog)
4) Now foo2.php pops up. At this point, what does foo2.php believe the value of $prog to be?
Answer: When I put my code on the panix server, foo2.php believes the value of $prog to be “abc”. When I put the exact same code on a different server, foo2.php believes the value of $prog to be an empty string. (I can confirm this by inserting multiple echos, fwrites, etc.)
Question 1: WTF? What’s causing the discrepancy? Is this a result of the two servers running different versions of php, or of something else in the general environment? Is one of these “right” and the other “wrong” in some absolute sense, or does the definition of “right” vary from server to server?
Question 2: I really want foo2.php to believe that the value of $prog is “abc”. How can I rewrite so that this will happen on both servers, not just one of them?
Thanks for any geeky assistance you can give.
Edited to add: Problem solved! It turns out to have had nothing whatever to do with passing variable values from foo to foo2, and everything to do with passing variable values from the address bar to foo. Contrary to what I reported above, foo was *not* thinking that $prog had the value abc. To make it think this, I needed to insert, in foo.php, the line
$prog=$_GET[‘prog’]; .
Very sorry to have misled people about where the problem lay. When I said that foo.php believes $prog has the value $abc, I thought I’d checked this on both servers, but apparently I’d checked it only on the one where everything was working anyway.
Steve, the style of PHP coding you are using where URL parameters (like your ?prog=…) are translated to PHP variables is insecure. See http://php.net/manual/en/security.globals.php for more details.
In recent versions of PHP, that style of coding does not work with the default PHP configurations, hence the discrepancy across servers.
If you substitute in your code
$_GET[‘prog’]
anywhere you would use $prog, that will work.
I am absolutely no PHP-expert, but a quick search points to this:
http://php.net/manual/en/security.globals.php .
Do you have different settings for register_globals on the two servers? This might be caused by different PHP versions on the two servers.
Question 1: The behavior where a number of variables from external sources are automatically dumped into the global environment is called ‘register_globals’. This feature has been deprecated and removed, but it was also configurable at the server level (as opposed to configurable by the script), so it could either be a difference in PHP versions or a difference in server configuration. See: http://php.net/manual/en/security.globals.php
Question 2: You should use $_POST[‘prog’] (or $_GET, or $_REQUEST if you don’t care whether the variable came from a GET or POST). You can of course start off the script with:
$prog = $_POST[‘prog’];
See: http://php.net/manual/en/language.variables.external.php
The more technically correct answer to your question is that to get register_globals enabled on both servers, you need both servers to be running PHP 5.3 or *earlier*, and you need it to be enabled in the server configuration. This would be a matter for the system administrator.
When someone calls foo.php?prog=abc, they are calling it with a GET variable valued at “abc” ; and the foo.php programs reads this foo variable and stores it in its GET parameters (the $_GET array).
Now as JaredS said, there is a deprecated (because dangerous and confusing) configuration parameter called register_globas which, in short, makes all the GET and POST variables easiliy accessible as regular variables (those starting with a dollar sign).
In your case, it means that the pannix configuration made PHP read foo as a GET variable, vlaue it as ‘abc’, and then create a $foo variable with the same value.
Instead another server doesn’t know any $foo variable (which means it whil display blank if you call it), it knows $_GET[‘foo’] but considers it two different things.
My advice : assuming you cannot change the panix PHP condifguration, write your code as if this feature was turned off. If you want to access a variable from the URL (a GET) or from a POST submission, call it with the $_POST or the $_GET array.
Many thanks to JustAnotherTechie, RasmusFaber, JaredS and Xorph. I understand this now. But I still can’t seem to fix the problem.
That is, I now understand the bit about “register_globals” (which I cannot change). But I’ve tried inserting $prog=$_POST[‘prog’]; near the top of foo2.php, and when that didn’t work I tried $prog=$_GET[‘prog’]; . Each time, $prog continued to be treated as a blank string.
Uh … thanks? This sounds like damning by faint praise, but I can’t really tell yet.
Maybe it is time to use the almighty var_dump :
var_dump($_GET);
var_dump($_POST);
and if your PHP version is very old, you might also want to look at their obsolote counterparts, just in case :
var_dump($HTTP_GET_VARS);
var_dump($HTTP_POST_VARS);
Var_dump() will display the content of those variables. There’s nothing like it to really see where is your error.
And to be sure you can also write at the top of your php code this instruction :
error_reporting(-1);
which will tell PHP to explicitely display any warning, error or fatal error it finds.
As long as you have a form with an input with a “name” attribute, when the form is posted the target page should have an entry with that name in the GET or the POST vars, depending how the form was posted. Of course be sure that there isn’t another element in your form with the same name (“prog”).
Also in the code example you showed us :
(form method=POST action=foo2.php)
Enter your nickname: (input name=”nick”)
(input type=”hidden” name=”prog” value=(? echo $prog ?) )
(/form)
I assume this code is in foo.php. So when PHP processes this code, it display an HTML form with a hidden input whose value is whatever the value of the variable $prog was… in foo.php, not foo2.php.
Then when you submit your HTML form, the values of its input HTML fields are sent to foo2.php, which transforms them into those $_GET / $_POST variables that you can then use.
I’ve submitted an answer to the crossword – although looking at it again, I think I left out 27 down (easy to overlook a two letter word).
On that note, although I used the “Save” button, I don’t see a way to get back my saved answers.
Looking at it again, I realise I missed out more than just one answer, and I got a few wrong! So I’ve re-submitted a fresh answer.
Xorph:
*Many* thanks for your efforts. The problem is now solved; see the addendum at the bottom of the post.
Here’s a clue for you:
“Strange turn of events – larva’s gone back under ground” noted professor (6,9)
#11 I got that one. Not so much luck with the rest. I thought I had 22 across, but my answer doesn’t quite fit.
EricK: :)
This is a test.