[web-team] Volunteer

[Rick Moen]

Quoting Lisa Corsetti (svlug at flygirl.com):

> Yah, I know that a lot of the work was sloppy and not deeply
> thought through but, if you recall, we were in a rush to get
> things moved over (I forget why).  

Sort of yes.  My recollection is that you found it more practical to 
recode some of the odd page features (that had used odd little Perl
scripts like WebFetch - like the example below) into PHP.  One feature
of the previous pages _didn't_ have (IMO) any compelling reason to change
to PHP, that being the use of .shtml to process headers and footers as
include file.   If memory serves, you pretty much made the judgement
call, there, that .shtml was too '90s.

> That said, my not-so-good memory is that there was something
> about the PHP (which I would never use these days) that only
> runs once a day -- mostly just using includes unless it is run
> for the first time in a given day -- or the first time since a
> particular file is modified or something like that.

Unless I'm wildly misunderstanding, that is not the case.  _Almost_ all
of the pages are assembled at load time with an instance of the PHP 
interpreter.  Here's example header contents from page
http://www.svlug.org/farm.php :

<?php
include("header.php");
$head = "<META NAME = 'keywords' CONTENT='Linux Silicon Valley Apache Linus Torvalds'>\n";
$head .= "<META NAME = 'description' CONTENT='Linux Links'>"; svlugheader("SVLUG Link Farm... Moo.", $head);
?>

There are a couple (?) of pages that (rather magnifiently) get built as
PHP pages from separate PHP source.  I'm thinking in particular of 

http://www.svlug.org/  (SVLUGS News column), and 
http://www.svlug.org/news.php

Both of those PHP pages' PHP source contents are constructed at runtime
by include files shortnews.php and longnews.php (respectively) that both
parse formatted text file svlug-news.txt, which is the thing the Web
Team maintains manually to manage 'news' content.  I gather that the parser
detects when the svlug-news.txt changes on-disk.


But anyway, unless I'm missing something, pretty much every single
served page, maybe even without exception, requires the services of both
Lighty and of the PHP interpreter called via FastCGI.  Every single page
load is a PHP operation.

Which was not the case.  RAM and CPU load are _a_ point, but not
actually the significant ones.  Those are:

1.  PHP is a serious security risk.  Among other things, if there were a
PHP security meltdown, we couldn't easily temporarily disable just
PHP-generated pages and substitute static ones, because that's every
single page on the site.

A Web server with an inline PHP interpreter has a huge attack surface
compared to one without.  The bigger the attack surface, the greater
risk of security failure and the more time-sensitive and critical
software maintenance becomes.

2.  The rest of us found out about the PHP changeover only after it was
all done, with zero chance to discuss any issues, and at a time when we 
had been doing everything possible to skip avoidable inceases in RAM
footprint.