running-php-on-rucs
including files
running on rucs: file-protections

Reminder: project groups; review local projects.

splitting into multiple files

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.)

This also lets us separate a program that uses blend from the test cases: some-web-page.php (src), and some-web-page.php (output).

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
nano — edit a file (also, vim and emacs are more powerful editors, but harder to learn).

If you want to brush up (or, learn) basic unix, this is a good tutorial (sections 1,2 on using teh 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.
- log in to rucs in a terminal-window, and edit locally (vim, emacs, or pico).

Running a php file via the web

Note:We won't demo this in class yet, since it is not required for hw01. (And hw01 doesn't do this because it's important to be able to run your php 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 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);

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 compatability. 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.
- <script type="text/javascript" src="foo.js"></script>— fine.
- <script type="text/javascript" >callSomeFunction();</script>— fine.
- <script type="text/javascript" src="foo.js" />— BAD; a browser may ignore the tag entirely!, which is an annoyingly difficult bug to track down.
There is no good reason for HTML to be defined like this!