[FX.php List] Planning ahead for inactive processes

[Steve Winter]

Hi Jonathan...

Your suggestion below is an excellent one, and one which I've employed
previously... it works really well where a solution has lots and lots of
pages within it that get called directly...

Other solutions which I've implemented include;
 - for small solutions, only use one file, index.php, quick and easy to
'turn off' at a later date, not so good for big solutions...
 - index.php is the only page that ever gets called directly, it includes a
series of logic which loads the required sub-page, so as above, it's easy to
turn off... works okay for medium sized solutions...
 - 'few' root pages... in a recent solution the logic was getting way out of
control for my brain to handle it all in just one index.php file, so that
solution has 5 root level pages, quick enough to 'turn-off' if required
 - similar to your suggestion, one server of ours has an actual 'control'
database on it... the server has about 35 'little bits' of web functionality
that get set-up for short-term exhibitions/activities... we have a master db
on that server which is called at the head of every page...it checks in the
db to see when the programme ends (the master db has programme name,
programme description, start date and end date) if the current date is > end
date, then a default 'message' page is loaded, in which the user is told
that the programme 'blah' with description' blah blah blah' ended on
'endDate'.

The other option that you could look into is using your server to redirect
all calls to a specific folder/site to a 'closed' page (never done that, but
know it's possible)

Food for thought...

Cheers
Steve


-----Original Message-----
From: fx.php_list-bounces at mail.iviking.org
[mailto:fx.php_list-bounces at mail.iviking.org] On Behalf Of Jonathan Schwartz
Sent: 25 February 2008 15:02
To: FX.php Discussion List
Subject: [FX.php List] Planning ahead for inactive processes

Hi Folks,

At an increasing rate, I'm seeing that bots and past visitors with 
bookmarks (?) are attempting to re-visit processes that have long 
been retired.  The purpose for the original pages has expired.  The 
original database might not even be running.

I'm looking for how I can best plan ahead during development, to deal 
with the day that the pages are no longer valid.  It's no fun opening 
up the code after 6 months and re-learning.

Obviously, simply removing the link to the start of the process isn't 
the solution.

I'm thinking that one good option is to create a variable in 
server_data that serves as an on off switch or data limiter.  Page 
handling code at the top of each page could check for the variable to 
decide if the pages are still valid or not. I'd rather do it while 
the code is fresh in my mind rather than after.

What do other folks do?

J
-- 
Jonathan Schwartz
Exit 445 Group
jonathan at exit445.com
http://www.exit445.com
415-381-1852
_______________________________________________
FX.php_List mailing list
FX.php_List at mail.iviking.org
http://www.iviking.org/mailman/listinfo/fx.php_list