[web-team] Volunteer

[Lisa]

On Wed, Jan 28, 2015 at 06:51:51PM -0800, Rick Moen wrote:

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

I seem to recall that WebFetch no longer worked, or we had no
one to support it -- or something like that.  I do remember that
I didn't feel like *I* was able/willing to support it. :-)
 
>> 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.

Well, the "includes" parts can certainly be de-PHP-ified easily
enough.

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

Ah... yes, THAT is the part I remember -- not everything on the
news and meetings pages gets reconstructed every time the page
gets loaded -- that is what I was referring to above.

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

Agreed 100%... I'd be willing to help solve this problem.  If
we're okay with all pages being rewritten by a cron script once
a day or manuall called when files are changed or something
similar, that should NOT be a serious task.

Do we have specific languages in mind?  Python?  Java?  What?

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

I believe that there is nothing on any of these sites that can't
be statically re-done (with a periodic running script).  The
only thing that currently changes load-to-load, IIRC, is the
"sponsor" logo that gets displayed -- I suspect that it would be
okay to change that once a day -- or every few hours.

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

Well, that sounds like I took the position of ramming it down
SVLUG's throat.  That doesn't sound like me.

AFAIK, I did nothing irreversable -- if it wasn't percieved to
be better than what was there before, it didn't have to stay.  I
likely just went PHP because it was what would cost me the least
amount of investment of my time.

But it's just not my nature to force something on anyone.

All that said, regardless... *how* it got to where it is is
irrelevant.  If some assistance is desired changing it, I can
put some time in -- as someone who can probably figure out what
*is* there fairly quickly.

If, OTOH, it's all well-in-hand, I'll stay out of the way and I
have NO complaints of moving from PHP :-)

Lisa