You do NOT want one function per file.
Dog-slow.
You *MIGHT* want to group a bunch of functions logically into one
file, breaking up a monster file into several files.
On Fri, May 26, 2006 3:02 am, Mark Kelly wrote:
Hi
I'm writing a set of db abstraction functions for an internal app
which
On Fri, May 26, 2006 9:46 am, Mark Kelly wrote:
On Friday 26 May 2006 14:56, Matt Carlson wrote:
One note on include files. Usually it's best practice to not name
them
.inc
Name them .inc.php so that they cannot be opened by a webbrowser,
thus
giving more information to a potential
tedd wrote:
Name them .inc.php so that they cannot be opened by a webbrowser, thus
giving more information to a potential attacker.
As always, there's another side to that augment. If you give them the
.php suffix, then they can be ran via a browser as-is , which may not
be something
At 4:01 PM +0200 5/27/06, Jochem Maas wrote:
tedd wrote:
Name them .inc.php so that they cannot be opened by a webbrowser, thus
giving more information to a potential attacker.
As always, there's another side to that augment. If you give them
the .php suffix, then they can be ran via a
2006/5/27, Jochem Maas [EMAIL PROTECTED]:
2. any include file that does contain code that runs on inclusion contains
something
like the following as the first line of code:
if (!defined('MY_APP_IS_SETUP')) die('try
http://'.$SERVER['SERVER_NAME'].'/');
An enhancement to this strategy could
Mark,
I use one functions file per site, then I know that if I include it, and all
of my functions are available.
George
-Original Message-
From: Mark Kelly [mailto:[EMAIL PROTECTED]
Sent: 26 May 2006 9:02 am
To: php-general@lists.php.net
Subject: [PHP] Including Functions; one
At 9:02 AM +0100 5/26/06, Mark Kelly wrote:
Hi
I'm writing a set of db abstraction functions for an internal app which will
give us a set of simple function calls for dealing with the db, like
$result = db_AddEmployee($EmployeeData);
$EmployeeData = db_GetEmployee($EmployeeID);
etc.
There
At 9:02 AM +0100 5/26/06, Mark Kelly wrote:
TIA in advance for any advice,
And thanks in arrears to all who responded.
Since there appears to be no compelling reason to go either way, and we
already have subdivided include files for functions (to a limited extent)
I've decided to go with a
On Friday 26 May 2006 14:56, Matt Carlson wrote:
One note on include files. Usually it's best practice to not name them
.inc
Name them .inc.php so that they cannot be opened by a webbrowser, thus
giving more information to a potential attacker.
Is this still a concern when all include files
Mark Kelly wrote:
On Friday 26 May 2006 14:56, Matt Carlson wrote:
One note on include files. Usually it's best practice to not name them
.inc
Name them .inc.php so that they cannot be opened by a webbrowser, thus
giving more information to a potential attacker.
Is this still a concern
Mark Kelly wrote:
At 9:02 AM +0100 5/26/06, Mark Kelly wrote:
TIA in advance for any advice,
And thanks in arrears to all who responded.
Since there appears to be no compelling reason to go either way, and we
already have subdivided include files for functions (to a limited extent)
I've
On Friday 26 May 2006 16:41, Jochem Maas wrote:
besides .inc.php seems to be/becoming a sort of defacto std (no need for
filenaming jihad people ;-)
That's certainly worth considering (particularly as the project is still at
the very early stages), thank you both for mentioning it. My
Name them .inc.php so that they cannot be opened by a webbrowser, thus
giving more information to a potential attacker.
As always, there's another side to that augment. If you give them the
.php suffix, then they can be ran via a browser as-is , which may
not be something you want. Need
Since we're talking about include()ing functions specifically, I don't think
there's going to be much trouble to be had. Your file may be something like
this:
?php
function somefuncname() {
// some code
}
?
If that's executed by PHP by being called directly, it won't do anything.
14 matches
Mail list logo
