running-php-via-web
running php on rucs (not using a web server)
Reminder: project groups; review local projects.
We will look at:
How to connect to rucs;
How to run a php program from the command line
How to run a php program via php.radford.edu.
How to connect to rucs
Linux Review
You'll want to be familiar with the main options for the following:
ls -lF — list files in long format (show permissions/timestamp);
use -d to show directories themselves (rather than their contents).
cd — change directory
mkdir — make a directory
chmod — change (permission) mode
Optionally, any editor that can be run through a terminal window:
nano — not a great editor, but most of its commands are listed
at the bottom of the screen, making it easy to learn;
emacs — the kitchen sink of editors — great, but
it involves memorizing commands like
ctrl-S to search,
ctrl-X ctrl-S to save,
ctrl-C ctrl-C to compile and run the Java program you are editing,
and
ctrl-u tetris to play a game (seriously).
vim — an editor which can let you edit extremely quickly,
once you master the fact that it has “input mode” (where your keystrokes add
characters to your file, just like you'd expect), and “command mode” (where each
keystroke is an editing command — e.g.j moves down a line
and k moves up a line … a keybinding that also happens
to work in gmail when viewing your list of messages, btw).
Tutorials for any of these editors are easily searchable.
If you want to brush up (or, learn) basic unix,
this is a good
tutorial
(sections 1,2 on using the command-line for file basics,
and section 5 for file permissions).
Accessing rucs
Before we even revisit the code, let's talk about rucs
(“radford university computer science”; it's a machine managed by the ITEC department,
not the campus IT division):
How to log on to rucs, so you can run php on it:
First, start the VPN, if you are off campus.
Then, either
use ssh yourUserName@rucs.radford.edu
or
run putty.
Note that if rucs is down, then ruacad.radford.edu can also be used.
Be aware: rucs and ruacad are not the
campus web server, nor the php server!
You don't have accounts on those machines
(although your H: drive is shared by those machines).
In particular: the version of php you run from
rucs's command-line is slightly different than the
version run by php.radford.edu!-o
How to run a php file:
Either php -a for a quick interactive session;
or
from the command-line, php filename.php.
How to edit files on rucs:
Either
From your PC, mount your H: drive and then edit locally
(using Notepad or JEdit or eclipse... but not Word).
Each time you save your file, it's writing to your H: drive.
Or:
log in to rucs in a terminal-window,
and edit locally (vim, emacs, or pico).
We can take
blend.php (src),
and separate the code from the test-cases:
utils.php (src), and separately
utils-test.php (src).
The directive require-once is a run-time instruction
which just goes to the require'd file and
(effectively) splices it into the current file,
and continues evaluating line-by-line.
(So it's reminiscent of java's import, but
require-once significantly more simple-minded.
Beware trampling on identifiers, and it's poor practice to
have any dangling tags / code in the require'd file.)
Note:This is not to be used for hw01.
(That's intentional: Before having a web-server configured to run your programs,
you should be clear on how to run your programs without using the web at all,
for debugging purposes.)
Recall that when a web-server gets a request, it decides how to respond.
For php.radford.edu, some of the configuration rules:
For requests of the form ~userName/somePath/someFile.php,
it looks on
userName's H-drive,
for the file
dynamic_php/somePath/someFile.php,
and it runs that .php program.
The program's printed output becomes the response sent back to the browser.
The .php file must be readable by everybody (since it's being served up to the www),
and it must be non-writable by group,other
(as a security measure: other users can't implant malware into your php program).
Apache runs php with the privileges of the file's owner (su).
php.radford.edu only accepts secure (https) connections.
Let's put our php program on the web!
Place the .php file inside dynamic_php/ on your H: drive.
You may have to create that directory if it doesn't already exist, using mkdir.
Make sure the file is world-readable, but not group-writable:
chmod o+r g-w blend.php.
(This makes it other-readable, non-group-writable, without changing any other permissions.
You could instead use go-w ugo+r to additionally ensure that it
is non-group-writable, and readable by user,group,other;
however those are usually already part of the standard default.)
Make sure all the folders enclosing your file
are other-executable-and-executable but not group-writable:
chmod o+rx g-w . .., chmod o+x . ...
One crude way to get things to work:
Set every file to be rwx r-x r-x
(whether or not it's a folder, .html file, or .php file):
Recursively change permissions:
chmod -R u=rwx go=rx ~/dynamic_php/
or (using the octal representation of the user/group/other permissions, 111 101 101) just
chmod -R 755 ~/dynamic_php/
If the php interpreter hits an error, the program terminates with no output
(so nothing is sent back to the client —
status code 500: internal server error)!
To change this default, include at the top of your php program:
error_reporting(E_ALL);
Here is a quick check-list of common problems, if you try running your program via the web but
get an error:
Error 404 (Not Found):
Recall from quizzes:
Given the URL
http://php.radford.edu/~someUser/someDir/someFile.php,
the web-servers php.radford.edu will look for someUser's H: drive,
and within that look for dynamic_php/someDir/someFile.php.
(Remember to (a) put someDir/ inside your ~/dynamic_php/,
and (b) don't include “dynamic_php/” in your URL.)
Error 403 (Forbidden):
Make sure the permissions are correct on (a) the file itself, and
(b) its enclosing folder, and (c) the next-higher enclosing folder, (d) …
(y) the next-heigher-yet enclosing folder,
(z) the enclosing ~/dynamic_php.
For example, check:
ls -ld ~/dynamic_php/itec325/hw00/someFile.php
ls -ld ~/dynamic_php/itec325/hw00/
ls -ld ~/dynamic_php/itec325/
ls -ld ~/dynamic_php/
and make sure that each of the files is readable/executable by others,
and not writable by group/others (e.g.rwxr-xr-x).
Error 500 (Server Error):
This is almost certainly due to your php program not being a valid PHP program
(perhaps it's missing a semicolon somewhere).
Solve this by running your program from the command-line (not via the web at all),
and seeing what the error-message is.
XHTML
xhtml:
Even though original HTML doesn't require the following,
they are best practices, and they are required for this class:
Tag names are case-sensitive
(with a preference for lower-case and camelCase).
quote all attribute-values, even if it looks numeric;
well-formed (duh):
each open-tag must be eventually followed by a corresponding close-tag,
and if a tag's body contains another open-tag it must
also contain the corresponding close-tag.
Bad: This is <em>not <strong>at all</em> legal</strong> XML.
Good:This is <em>actually <strong>very</strong> good</em> practice.
Another way of viewing this: The open/close tags must correspond to a tree.
The most common (non-X)HTML example using improperly nested tags
is <p>, which (in HTML) doesn't need to be closed;
the browser auto-closes the tag when it reaches the next <p>
(or more precisely: when it reaches the next block-level open-tag,
or a close-tag which is terminating the enclosing block, e.g. if the paragraph
was already inside an itemized list).
Browsers tend to go to great lengths to try to make sense of tag soup;
just because a page looks fine in your browser doesn't mean it's legal.
The result is that many people learned their HTML by doing a show-source on bad, illegal examples,
and then propagating that bad HTML, and never realizing it because most browsers still did
something reasonable
(although the details of how a browser handled bad HTML are of course entirely non-standard).
Note that xhtml is always valid html5 (but not vice versa — for example, unclosed p tags
are allowed in html5).
Self-closing tags:
<br></br>— fine, but long-winded.
<br/>— self-closing tag, allowed by XML.
<br />— Used for backwards compatibility.
The original HTML required a space before the /,
and it's conceivable (if unlikely) that a modern browser will insist on
using the HTML standard.
We will not worry about such archaic cruft for this class,
but your future employers might well care about customers who use
old browsers.
<br> </br>— (note the space inside the tag)
this version is
not equivalent
(and, not valid HTML) — spaces are part of your XML text,
even if an HTML browser chooses often ignore them for layout purposes.
Important:
In HTML (and actually enforced! by most modern browsers),
you can only use the self-closing tag for those tags which never
are allowed a body.
For tags that may or may not have a body (notably: script),
you cannot use the self-closing version even when you want an empty
body.
<hr />— fine; hr never has a body.
<img src="foo.jpg" />— fine; img never has a body.
radford.edu