| newbie question: Is config.php necessary? [message #170587] |
Tue, 09 November 2010 05:46  |
luxor1275bc
Messages: 1
Registered: November 2010
Karma: 0
|
Junior Member |
|
|
I found a website ( http://net.tutsplus.com/tutorials/php/organize-your-next-php-project-the-ri ght-way/
) where is suggests that config.php must be included in every webpage
when using require_once. Yet I cannot seem to find any info on how
config.php is supposed to be configured properly since the author (of
the above mentioned page) does not provide that information completely
as best as I can tell. What must I do in order to use require_once on
my web pages? If config.php is necessary, is there any website that
you could point me to in order to learn how to properly configure it?
I have php on OSX 10.6 and have uncommented the php module in /etc/
apache2/httpd.conf along with restarting apache so I should be set to
go other than perhaps the config.php and/or mysql.
One other question: Is mysql necessary? If so, why? What if I have
no need of it right now?
Thanks.
|
|
|
|
| Re: newbie question: Is config.php necessary? [message #170588 is a reply to message #170587] |
Tue, 09 November 2010 09:22  |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/9/2010 6:46 AM, luxor1275bc wrote:
> I found a website ( http://net.tutsplus.com/tutorials/php/organize-your-next-php-project-the-ri ght-way/
> ) where is suggests that config.php must be included in every webpage
> when using require_once. Yet I cannot seem to find any info on how
> config.php is supposed to be configured properly since the author (of
> the above mentioned page) does not provide that information completely
> as best as I can tell. What must I do in order to use require_once on
> my web pages? If config.php is necessary, is there any website that
> you could point me to in order to learn how to properly configure it?
Hello,
I checked what net.tutsplus.com is putting in theirs, and I always use
the same strategy.
I have 1 file that is included everywhere.
In such a file you can set up a lot of things that makes your life easier.
A few things I put in there:
// 1) Set up the rootdir of the application:
$rootDir = "/srv/hosting/www.example.nl";
// 2) Overriding certain php.ini settings with values you
// want in your current project:
$iniSettings = array (
// Avoid w3c validation errors
"arg_separator.output" => "&",
// magic quotes off please
"magic_quotes_gpc" => "",
"magic_quotes_runtime" => "",
// Includepath:
"include_path" =>
get_include_path().PATH_SEPARATOR.$rootDir.'/www/includes',
"default_mimetype" => "text/html",
"default_charset" => "UTF-8",
// errorhandling
"error_reporting" => E_ALL
);
// Set and test them
foreach ($iniSettings as $inikey => $inivalue){
ini_set($inikey, $inivalue);
// and test
if (ini_get($inikey) != $inivalue){
echo "UNRECOVERABLE INI-PROBLEM IN ini_settings.php.<br>";
echo "CANNOT SET $inikey to $inivalue. ini_get($inikey) =
".ini_get($inikey)."<br><h2>EXITING</h2>";
exit;
}
}
and
// 3)include certain files (with functions or classes) you want to
// have access to everywhere:
require 'myFunctions.php';
and
// 4) Set up an errorhandler
set_error_handler("errorHandler");
and
// 4) Include a databaseconnection
// outside the webroot
require_once("$rootDir/mydatabaseconnect.php");
if (!isset($connection)){
echo "Problem: No databaseconnection found.";
exit;
}
etc.
etc.
Whatever suits your needs.
That way you have 1 file where most of the control of your application
is managed.
If do that right, you must only modify this file when you deploy your
application elsewhere.
>
> I have php on OSX 10.6 and have uncommented the php module in /etc/
> apache2/httpd.conf along with restarting apache so I should be set to
> go other than perhaps the config.php and/or mysql.
Well, is PHP working?
A simple file that contains:
<?php
echo "This is PHP speaking!";
?>
should be enough.
>
> One other question: Is mysql necessary?
Not at all. I avoid mysql where I can, especially now it has that
uncanny Oracle-smell.
If you care, read this:
http://en.wikipedia.org/wiki/Mysql#Corporate_backing_history
Other (free) quality databases exist. (I prefer Postgres)
> If so, why? What if I have no need of it right now?
>
> Thanks.
Good luck.
Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
|
|
|
|
| Re: newbie question: Is config.php necessary? [message #170606 is a reply to message #170588] |
Tue, 09 November 2010 20:21 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller schrieb:
[Overriding PHP settings in an included config file]
> // magic quotes off please
> "magic_quotes_gpc" => "",
I'm afraid this cannot be set within a PHP script. The manual lists this
directive as PHP_INI_PERDIR (used to be PHP_INI_ALL up to PHP 4.2.3). I
think the filter functions provide a means of accessing the "unquoted"
raw input.
> // errorhandling
> "error_reporting" => E_ALL
I would use E_ALL | E_STRICT (unintuitively, E_STRICT is not included in
E_ALL, so E_ALL is actually "E_ALMOST_ALL").
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: newbie question: Is config.php necessary? [message #170611 is a reply to message #170606] |
Wed, 10 November 2010 08:53 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/9/2010 9:21 PM, Thomas Mlynarczyk wrote:
> Erwin Moller schrieb:
>
> [Overriding PHP settings in an included config file]
>> // magic quotes off please
>> "magic_quotes_gpc" => "",
>
> I'm afraid this cannot be set within a PHP script. The manual lists this
> directive as PHP_INI_PERDIR (used to be PHP_INI_ALL up to PHP 4.2.3). I
> think the filter functions provide a means of accessing the "unquoted"
> raw input.
Correct. That was confusing.
But it is there for a reason. ;-)
The reason it is there anyway is: the following block (that checks the
values) produces an error in case magic_quotes_gpc is on.
(I had a few more ini-values in there, but cut a lot out. The code was
only posted to show the idea of the kind of things you can do in a
'global config' file.)
>
>> // errorhandling
>> "error_reporting" => E_ALL
>
> I would use E_ALL | E_STRICT (unintuitively, E_STRICT is not included in
> E_ALL, so E_ALL is actually "E_ALMOST_ALL").
Yes, I am aware of E_ALL and E_STRICT: this examplecode comes from a
project where I didn't want strict errors to error out. The errorhandler
itself even returns if it is a strict error.
So in this case I ignore them two times. ;-)
Regards,
Erwin Moller
>
> Greetings,
> Thomas
>
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
|
|
|
|
| Re: newbie question: Is config.php necessary? [message #170623 is a reply to message #170611] |
Thu, 11 November 2010 18:40 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller schrieb:
[magic_quotes_gpc cannot be set at runtime]
> Correct. That was confusing.
> But it is there for a reason. ;-)
> The reason it is there anyway is: the following block (that checks the
> values) produces an error in case magic_quotes_gpc is on.
Okay, but actually, why bother since you can access the raw data using
filter_input() even with magic_quotes_gpc on:
// http://localhost/test.php?value=It's+a+"test"
var_dump( filter_input( INPUT_GET, 'value', FILTER_UNSAFE_RAW ) );
var_dump( @$_GET['value'] );
Output:
string 'It's a "test"' (length=13)
string 'It\'s a \"test\"' (length=16)
> (I had a few more ini-values in there, but cut a lot out. The code was
> only posted to show the idea of the kind of things you can do in a
> 'global config' file.)
Indeed, that gave me some inspiration for my own global setup stuff. :-)
[Use E_ALL | E_STRICT, not just E_ALL]
> Yes, I am aware of E_ALL and E_STRICT: this examplecode comes from a
> project where I didn't want strict errors to error out.
Yes, sometimes one has to work with projects like this (SimpleTest, for
example is not "strict proof"). :-(
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: newbie question: Is config.php necessary? [message #170633 is a reply to message #170623] |
Fri, 12 November 2010 10:27 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/11/2010 7:40 PM, Thomas Mlynarczyk wrote:
> Erwin Moller schrieb:
> [magic_quotes_gpc cannot be set at runtime]
>> Correct. That was confusing.
>> But it is there for a reason. ;-)
>> The reason it is there anyway is: the following block (that checks the
>> values) produces an error in case magic_quotes_gpc is on.
>
Hi Thomas,
> Okay, but actually, why bother since you can access the raw data using
> filter_input() even with magic_quotes_gpc on:
>
> // http://localhost/test.php?value=It's+a+"test"
> var_dump( filter_input( INPUT_GET, 'value', FILTER_UNSAFE_RAW ) );
> var_dump( @$_GET['value'] );
>
> Output:
> string 'It's a "test"' (length=13)
> string 'It\'s a \"test\"' (length=16)
Why?
Because I consider:
filter_input( INPUT_GET, 'value', FILTER_UNSAFE_RAW )
a horrible construct compared to:
$_GET["value"];
I prefer using the superglobals directly.
(But that might be just me: Each to his own of course!)
>> (I had a few more ini-values in there, but cut a lot out. The code was
>> only posted to show the idea of the kind of things you can do in a
>> 'global config' file.)
>
> Indeed, that gave me some inspiration for my own global setup stuff. :-)
>
Glad to hear something good came out of this thread, since I didn't hear
the OP respond. :-)
> [Use E_ALL | E_STRICT, not just E_ALL]
>> Yes, I am aware of E_ALL and E_STRICT: this examplecode comes from a
>> project where I didn't want strict errors to error out.
>
> Yes, sometimes one has to work with projects like this (SimpleTest, for
> example is not "strict proof"). :-(
Not to mention some of my own older code. :P
You probably know the situation: A huge website, written in PHP4.3 many
years ago, and the client doesn't understand why you want to rewrite the
whole thing, and says: "It works, doesn't it? So simply add this and
that functionality. I don't want to spend a lot of money on a rewrite.".
Sometimes I wished I could just ditch some old projects of mine.
But it pays for my pizza. ;-)
Regards,
Erwin Moller
>
> Greetings,
> Thomas
>
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
|
|
|
|
| Re: newbie question: Is config.php necessary? [message #170637 is a reply to message #170633] |
Fri, 12 November 2010 15:42 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller schrieb:
> Because I consider:
> filter_input( INPUT_GET, 'value', FILTER_UNSAFE_RAW )
> a horrible construct compared to:
> $_GET["value"];
Well, I would, of course, bury this "horrible construct" in a nice
little function or method, for example:
function get( $name, $default = null )
{
return isset( $_GET[$name] )
? filter_input( INPUT_GET, $name, FILTER_UNSAFE_RAW )
: $default;
}
Actually, I would add some check of the retrieved value etc. but the
above is just to give the general idea of hiding the ugly interface of
the filter extension behind some sweet syntactic sugar.
> I prefer using the superglobals directly.
> (But that might be just me: Each to his own of course!)
Agreed.
> You probably know the situation: A huge website, written in PHP4.3 many
> years ago, and the client doesn't understand why you want to rewrite the
> whole thing, and says: "It works, doesn't it? So simply add this and
> that functionality. I don't want to spend a lot of money on a rewrite.".
I feel you pain. Maybe you could tell the client that the current
architecture does not permit to add the requested functionality easily
and that that would cost much more than than a complete rewrite. Or that
the requested functionality *requires* PHP 5. Or: PHP 4 is no longer
supported, so if there's a problem with it, there will be no one to fix
it. Or: "The requested functionality will make your website so popular
that the increased number of visitors can no longer be handled by the
old server, so you'd have to get a new one and they don't make the PHP4
ones any more..." ;-) Or: "Since PHP4 is no longer supported, I must
charge an extra fee for dealing with legacy code..."
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: newbie question: Is config.php necessary? [message #170669 is a reply to message #170637] |
Sun, 14 November 2010 17:45 |
Twayne
Messages: 135
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In news:ibjn8e$a7p$00$1(at)news(dot)t-online(dot)com,
Thomas Mlynarczyk <thomas(at)mlynarczyk-webdesign(dot)de> typed:
> Erwin Moller schrieb:
>> Because I consider:
>> filter_input( INPUT_GET, 'value', FILTER_UNSAFE_RAW )
>> a horrible construct compared to:
>> $_GET["value"];
>
> Well, I would, of course, bury this "horrible construct" in
> a nice little function or method, for example:
>
> function get( $name, $default = null )
> {
> return isset( $_GET[$name] )
> ? filter_input( INPUT_GET, $name, FILTER_UNSAFE_RAW
> ) : $default;
> }
>
> Actually, I would add some check of the retrieved value
> etc. but the above is just to give the general idea of
> hiding the ugly interface of the filter extension behind
> some sweet syntactic sugar.
>> I prefer using the superglobals directly.
>> (But that might be just me: Each to his own of course!)
>
> Agreed.
>
>> You probably know the situation: A huge website, written
>> in PHP4.3 many years ago, and the client doesn't
>> understand why you want to rewrite the whole thing, and
>> says: "It works, doesn't it? So simply add this and that
>> functionality. I don't want to spend a lot of money on a
>> rewrite.".
>
> I feel you pain. Maybe you could tell the client that the
> current architecture does not permit to add the requested
> functionality easily and that that would cost much more
> than than a complete rewrite. Or that the requested
> functionality *requires* PHP 5. Or: PHP 4 is no longer
> supported, so if there's a problem with it, there will be
> no one to fix it. Or: "The requested functionality will
> make your website so popular that the increased number of
> visitors can no longer be handled by the old server, so
> you'd have to get a new one and they don't make the PHP4
> ones any more..." ;-) Or: "Since PHP4 is no longer
> supported, I must charge an extra fee for dealing with
> legacy code..."
> Greetings,
> Thomas
Dumb Question:
Why, really, does it matter whether it's 4.x or 5.x? 4 will continue,
with only a few finite exceptions, to work under 5 for quite some time to
come. I mean, are there any actual problems NOW? If not, there isn't likely
to be. What ARE the problems, if any? By the time you get past 5.3 it could
begin to matter, but ... AFAIK most servers still allow either setting for 4
OR 5.
I'm just trying to understand why it matters since the customer is
resisting, something I would expect to happen anyway. One thing I would NOT
do is lie or mislead the customer because if it's something he's mad about
it's something he'll talk about and you never know who he'll talk to. I know
the first time anyone is proven to lie to me, our association is done, even
if it's a paying customer. I also try to follow up any of what I consider to
be outrageous claims and so do some customers. Lyng is a dangerous rep to
get. I've picked up three accounts because of lies their previous authors
tried to give them.
HTH,
Twayne`
|
|
|
|
| Re: newbie question: Is config.php necessary? [message #170678 is a reply to message #170669] |
Sun, 14 November 2010 20:08 |
Thomas Mlynarczyk
Messages: 131
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Twayne schrieb:
> Dumb Question:
> Why, really, does it matter whether it's 4.x or 5.x? 4 will continue,
> with only a few finite exceptions, to work under 5 for quite some time to
> come. I mean, are there any actual problems NOW? If not, there isn't likely
> to be. What ARE the problems, if any? By the time you get past 5.3 it could
> begin to matter, but ... AFAIK most servers still allow either setting for 4
> OR 5.
In theory, a PHP4 app should run under PHP5 without any problems, true.
The php.ini file must be checked since some defaults were changed, but
otherwise it should run okay. I've done it myself. So, you're right, it
shouldn't matter.
> I'm just trying to understand why it matters since the customer is
> resisting, something I would expect to happen anyway. One thing I would NOT
> do is lie or mislead the customer because if it's something he's mad about
> it's something he'll talk about and you never know who he'll talk to. I know
> the first time anyone is proven to lie to me, our association is done, even
> if it's a paying customer. I also try to follow up any of what I consider to
> be outrageous claims and so do some customers. Lyng is a dangerous rep to
> get. I've picked up three accounts because of lies their previous authors
> tried to give them.
I was not suggesting to lie to a customer. I was merely pointing out
possible arguments which *may* apply in the given case. Of course
there's nothing wrong with just letting a working system run, but
personally I prefer not having to touch legacy code. Once you're used to
PHP5 it takes some extra effort to remember all the things that must be
done differently in PHP4.
Greetings,
Thomas
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!
(Coluche)
|
|
|
|
| Re: newbie question: Is config.php necessary? [message #170681 is a reply to message #170678] |
Sun, 14 November 2010 22:10 |
Twayne
Messages: 135
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In news:ibpfjn$4ni$03$1(at)news(dot)t-online(dot)com,
Thomas Mlynarczyk <thomas(at)mlynarczyk-webdesign(dot)de> typed:
> Twayne schrieb:
>> Dumb Question:
>> Why, really, does it matter whether it's 4.x or 5.x? 4
>> will continue, with only a few finite exceptions, to work
>> under 5 for quite some time to come. I mean, are there any
>> actual problems NOW? If not, there isn't likely to be.
>> What ARE the problems, if any? By the time you get past
>> 5.3 it could begin to matter, but ... AFAIK most servers
>> still allow either setting for 4 OR 5.
>
> In theory, a PHP4 app should run under PHP5 without any
> problems, true. The php.ini file must be checked since some
> defaults were changed, but otherwise it should run okay.
> I've done it myself. So, you're right, it shouldn't matter.
>
>> I'm just trying to understand why it matters since the
>> customer is resisting, something I would expect to happen
>> anyway. One thing I would NOT do is lie or mislead the
>> customer because if it's something he's mad about it's
>> something he'll talk about and you never know who he'll
>> talk to. I know the first time anyone is proven to lie to
>> me, our association is done, even if it's a paying
>> customer. I also try to follow up any of what I consider
>> to be outrageous claims and so do some customers. Lyng is
>> a dangerous rep to get. I've picked up three accounts
>> because of lies their previous authors tried to give them.
>
> I was not suggesting to lie to a customer. I was merely
> pointing out possible arguments which *may* apply in the
> given case. Of course there's nothing wrong with just
> letting a working system run, but personally I prefer not
> having to touch legacy code. Once you're used to PHP5 it
> takes some extra effort to remember all the things that
> must be done differently in PHP4.
Yeah, I wasn't addressing you so much as the public at large because my
first read intimated making things up for the customer; a definite no-no.
And yeah, it can be a big hassle if you've for instance used some of the 5.x
filters which 4 didn't have - gives new meaning to the value of archives,
doesn't it<g>?
Cheers,
Twayne`
>
> Greetings,
> Thomas
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]