php-general Digest 11 Nov 2010 22:02:45 -0000 Issue 7033
Topics (messages 309443 through 309459):
Re: How do I convert the string "E_ALL & ~E_NOTICE" to the decimal equivalent
6135?
309443 by: Ford, Mike
Re: parse_ini_file() seems to be broken in PHP 5.2.4-2ubuntu5.12
309444 by: Tamara Temple
309445 by: Thijs Lensselink
Re: php running as module or cgi?
309446 by: Richard Quadling
309447 by: Richard Quadling
309454 by: Didier Gasser-Morlay
Re: Template engines
309448 by: Robert Cummings
309451 by: Daniel P. Brown
309452 by: Michael Shadle
309455 by: D. Dante Lorenso
309458 by: Bob McConnell
Re: Updating a GET variable
309449 by: Marc Guay
309450 by: Nathan Rixham
use of ini vs include file for configuration
309453 by: Tamara Temple
309456 by: João Cândido de Souza Neto
309457 by: Ashley Sheridan
309459 by: shiplu
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
> -----Original Message-----
> From: Daevid Vincent [mailto:dae...@daevid.com]
> Sent: 11 November 2010 04:06
> To: php-gene...@lists.php.net
>
> We're trying to move all of our configuration files for our
> DEV/TEST/PROD
> and various python scripts and such that all need the same DB
> connection
> parameters and pathing information to a common and simple config.ini
> file
> they all can share across languages.
>
> One snag I ran into is this:
>
> [dart]
> relative_url = /dart2
> absolute_path = /home/www/dart2
> log_level = E_ALL & ~E_NOTICE
>
> But when I read it in from the file, it's a string (of course)
That's odd -- parse_ini_file() should definitely translate those constants!
It certainly works on my v5.2.5 installation.
Cheers!
Mike
--
Mike Ford,
Electronic Information Developer, Libraries and Learning Innovation,
Leeds Metropolitan University, C507 City Campus,
Woodhouse Lane, LEEDS, LS1 3HE, United Kingdom
Email: m.f...@leedsmet.ac.uk
Tel: +44 113 812 4730
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--- End Message ---
--- Begin Message ---
On Nov 10, 2010, at 8:08 PM, Daevid Vincent wrote:
http://php.net/manual/en/function.parse-ini-file.php
Why doesn't PHP parse the 'null', 'true', 'false', etc into their
proper
equivalents? What's worse is that it does this mangling of my RAW
values to
be strings and sets them to "1" !!! WTF good does that do me?!
Here is my test.ini file:
---------------------------------------------------------------------------
---------------------------
[examples] ; this is a section
; this is a comment line
log_level = E_ALL & ~E_NOTICE
1 = intkey ; this is a int key
nullvalue = null ; this is NULL
truebool = true ; this is boolean (TRUE)
falsebool = false ; this is boolean (FALSE)
intvalue = -1 ; this is a integer (-1)
floatvalue = +1.4E-3 ; this is a float (0.0014)
stringvalue = Hello World ; this is a unquoted
string
quoted = "Hello World" ; this is a quoted string
apostrophed = 'Hello World' ; this is a apostrophed
string
quoted escaped = "it work's \"fine\"!" ; this is a quoted
string with
escaped quotes
apostrophed escaped = 'it work\'s "fine"!' ; this is a apostrophed
string
with escaped apostrophes
---------------------------------------------------------------------------
---------------------------
Here is my test.php page:
---------------------------------------------------------------------------
---------------------------
<?php
var_dump(parse_ini_file('./test.ini', true));
?>
---------------------------------------------------------------------------
---------------------------
Here is the output:
---------------------------------------------------------------------------
---------------------------
array
'examples' =>
array
'log_level' => string '6135' (length=4)
1 => string 'intkey' (length=6)
'nullvalue' => string '' (length=0)
'truebool' => string '1' (length=1)
'falsebool' => string '' (length=0)
'intvalue' => string '-1' (length=2)
'floatvalue' => string '+1.4E-3' (length=7)
'stringvalue' => string 'Hello World' (length=11)
'quoted' => string 'Hello World' (length=11)
'apostrophed' => string ''Hello World'' (length=13)
'quoted escaped' => string 'it work's \fine\!' (length=17)
'apostrophed escaped' => string ''it work\'sfine' (length=15)
---------------------------------------------------------------------------
---------------------------
develo...@mypse:~$ php -v
PHP 5.2.4-2ubuntu5.12 with Suhosin-Patch 0.9.6.2 (cli) (built: Sep
20 2010
13:18:10)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans
Maybe I'm missing something, but i thought that's what the constants
evaluated to....
--- End Message ---
--- Begin Message ---
On Wed, 10 Nov 2010 18:08:01 -0800, "Daevid Vincent"
<dae...@daevid.com> wrote:
http://php.net/manual/en/function.parse-ini-file.php
Why doesn't PHP parse the 'null', 'true', 'false', etc into their
proper
equivalents? What's worse is that it does this mangling of my RAW
values to
be strings and sets them to "1" !!! WTF good does that do me?!
Here is my test.ini file:
---------------------------------------------------------------------------
---------------------------
[examples] ; this is a section
; this is a comment line
log_level = E_ALL & ~E_NOTICE
1 = intkey ; this is a int key
nullvalue = null ; this is NULL
truebool = true ; this is boolean (TRUE)
falsebool = false ; this is boolean (FALSE)
intvalue = -1 ; this is a integer (-1)
floatvalue = +1.4E-3 ; this is a float
(0.0014)
stringvalue = Hello World ; this is a unquoted
string
quoted = "Hello World" ; this is a quoted string
apostrophed = 'Hello World' ; this is a apostrophed
string
quoted escaped = "it work's \"fine\"!" ; this is a quoted string
with
escaped quotes
apostrophed escaped = 'it work\'s "fine"!' ; this is a apostrophed
string
with escaped apostrophes
---------------------------------------------------------------------------
---------------------------
Here is my test.php page:
---------------------------------------------------------------------------
---------------------------
<?php
var_dump(parse_ini_file('./test.ini', true));
?>
---------------------------------------------------------------------------
---------------------------
Here is the output:
---------------------------------------------------------------------------
---------------------------
array
'examples' =>
array
'log_level' => string '6135' (length=4)
1 => string 'intkey' (length=6)
'nullvalue' => string '' (length=0)
'truebool' => string '1' (length=1)
'falsebool' => string '' (length=0)
'intvalue' => string '-1' (length=2)
'floatvalue' => string '+1.4E-3' (length=7)
'stringvalue' => string 'Hello World' (length=11)
'quoted' => string 'Hello World' (length=11)
'apostrophed' => string ''Hello World'' (length=13)
'quoted escaped' => string 'it work's \fine\!' (length=17)
'apostrophed escaped' => string ''it work\'sfine' (length=15)
---------------------------------------------------------------------------
---------------------------
Use the third parameter so the orignal values wil not get converted
(still strings though)
Besides that are you sure there are no whitespaces behind the ini
values?
var_dump(
parse_ini_file('./foo.ini', true, INI_SCANNER_RAW)
);
array(1) {
["examples"]=>
array(11) {
[1]=>
string(40) "intkey "
["nullvalue"]=>
string(32) "null "
["truebool"]=>
string(33) "TRUE "
["falsebool"]=>
string(32) "false "
["intvalue"]=>
string(33) "-1 "
["floatvalue"]=>
string(31) "+1.4E-3 "
["stringvalue"]=>
string(30) "Hello World "
["quoted"]=>
string(35) ""Hello World" "
["apostrophed"]=>
string(30) "'Hello World' "
["quoted escaped"]=>
string(27) ""it work's \"fine\"!" "
["apostrophed escaped"]=>
string(22) "'it work\'s "fine"!' "
}
}
develo...@mypse:~$ php -v
PHP 5.2.4-2ubuntu5.12 with Suhosin-Patch 0.9.6.2 (cli) (built: Sep 20
2010
13:18:10)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
with Xdebug v2.0.5, Copyright (c) 2002-2008, by Derick Rethans
--- End Message ---
--- Begin Message ---
On 11 November 2010 00:46, Al <n...@ridersite.org> wrote:
> Briefly, what are the trade offs on a typical shared host?
>
> I've done a little research and can't seem to find anything outstanding
> either way.
>
> Seems like as an Apache module is faster. This argument makes sense.
>
> CGI is more secure, this argument doesn't seem too persuasive to me. Maybe
> I'm missing something.
>
> Thanks....
I used to run PHP in ISAPI (on Windows with Sambar Server). Probably
the 1 big thing at the time was database connection persistence.
But that was a LONG time ago.
Everything is a LOT faster and now I use IIS+FastCGI+PHP and I no
longer use DB connection persistence as there were issues when
accessing multiple databases using the dbselect style functions.
I don't know if Apache supports fast cgi (I'd be surprised if it didn't).
But in a security vs speed contest, security should always win.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
On 11 November 2010 00:46, Al <n...@ridersite.org> wrote:
> Briefly, what are the trade offs on a typical shared host?
>
> I've done a little research and can't seem to find anything outstanding
> either way.
>
> Seems like as an Apache module is faster. This argument makes sense.
>
> CGI is more secure, this argument doesn't seem too persuasive to me. Maybe
> I'm missing something.
>
> Thanks....
As a module, any misbehaving script is running within the same space
as all the other scripts. If a script is able to knock out PHP (for
any reason), all the script go.
With CGI, they are run in separate spaces. No direct communication
(unless the scripts are sharing memory by some way). If a script
knocks out PHP, that script dies. Everything else keeps on going.
The main downside to CGI (as I understand things), is that for each
invocation of the script, PHP has to do the complete build up and tear
down every single time. For every single script.
With FastCGI, when the server starts, a pool of ready to go php
instances are created. So a script is called, the build up part is
already done.
In terms of speed, I'd guess you'd have to be working pretty hard to
see the difference between module/isapi and fast-cgi.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
On 11/11/2010 12:04 PM, Richard Quadling wrote:
On 11 November 2010 00:46, Al<n...@ridersite.org> wrote:
Briefly, what are the trade offs on a typical shared host?
I've done a little research and can't seem to find anything outstanding
either way.
Seems like as an Apache module is faster. This argument makes sense.
CGI is more secure, this argument doesn't seem too persuasive to me. Maybe
I'm missing something.
Thanks....
As a module, any misbehaving script is running within the same space
as all the other scripts. If a script is able to knock out PHP (for
any reason), all the script go.
With CGI, they are run in separate spaces. No direct communication
(unless the scripts are sharing memory by some way). If a script
knocks out PHP, that script dies. Everything else keeps on going.
The main downside to CGI (as I understand things), is that for each
invocation of the script, PHP has to do the complete build up and tear
down every single time. For every single script.
With FastCGI, when the server starts, a pool of ready to go php
instances are created. So a script is called, the build up part is
already done.
In terms of speed, I'd guess you'd have to be working pretty hard to
see the difference between module/isapi and fast-cgi.
If I am not mistaken, An apache module can even bring down the whole web
server if it really misbehaves.
So this leaves the choice between CGI & FatsCGI.
CGI setup/teardown is only an issue for site with a fairly high traffic.
It really depends on the type of site you intend to build.
--- End Message ---
--- Begin Message ---
On 10-11-11 03:49 AM, David Robley wrote:
On Thu, 11 Nov 2010, Robert Cummings wrote:
On 10-11-11 02:20 AM, David Robley wrote:
Daniel P. Brown wrote:
On Wed, Nov 10, 2010 at 20:59, Nathan Rixham<nrix...@gmail.com>
wrote:
I went back to using a pre hypertext processor, seemed like a
really powerful templating engine that was v familiar to use :p
Pre-hypertext preprocessor? Perl?
Pre Hypertext Processor - the acronym sounds familiar :-)
I think I saw something about that on someone's Personal Home Page!
Cheers,
Rob.
Perchance they were talking about a Form Interpreter ?
Yeah, that and some Gateway with a Common Interface.
Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.
--- End Message ---
--- Begin Message ---
On Thu, Nov 11, 2010 at 08:51, Robert Cummings <rob...@interjinn.com> wrote:
>
> Yeah, that and some Gateway with a Common Interface.
My point was that there is now and never was any such PHP project
known as pre-hypertext preprocessor. It originated as Personal Home
Page Tools (PHP Tools) and Forms Interpreter (FI) --- the former was a
series of C binaries, the latter was a CGI wrapper that actually
preprocessed straight HTML by hopping in and out of <!--HTML
Comments--> using SSI. For a short while, if memory serves me
correctly, a version of the package was also named Personal Home Page
Construction Kit. Eventually the packages merged into PHP/FI, and a
rewrite was done sometime during 1997, I believe, which became PHP/FI
2.0. I first started using it back in 1996 for quick and simple tasks
where Perl would be a bit overkill.
The part I can't remember clearly is whether PHP/FI2 was done in
1996 or 1997, though, because I do remember it was the fall of 1997
when PHP3 came out, and it blew me away. It sucked a bit having to
now learn how to use the new PHP to build a page, but damned if it
wasn't a trillion times easier to work with than Perl, right from the
get-go. I remember being excited by the fact that I could rewrite a
simple flat-file database Perl program I originally wrote in about
three days in under two hours with PHP. From that point on, I was
hooked on it, despite its quirky recursive-acronym name --- PHP:
Hypertext Preprocessor.
So when I asked if "pre-hypertext preprocessor" meant Perl, it
could well have been Python, C/C++ on SSI, Tcl/Tk, or anything....
anything, that is, that came "pre-" PHP.
That said, I have seen references to PHP being named
"Pre-Hypertext Preprocessor," but that would be incorrect anyway. The
HTML (HyperText Markup Language) could be preprocessed, so that much
is fine.... but "pre-hypertext" would be truly amusing. Any request
to a web page is presently made via HTTP (HyperText Transfer
Protocol), and any text displayed on any electronic device with
embedded references (also known as hyperlinks).
So any language that could pre-process pre-hypertext would either
have the unique ability to foresee the future, the mundane ability to
"pre-process" plain text (or request headers or anything prior to the
data being classified as hypertext), or the disconcerting ability to
modify reality as we know it. And why bother to do that when you
could just <%= go elsewhere. %>? ;-P
(It's felt like Friday all day.)
--
</Daniel P. Brown>
Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting
(866-) 725-4321
http://www.parasane.net/
--- End Message ---
--- Begin Message ---
Not to discredit this long post but the media here is now calling kids who text
often "hypertexting teens" which really irked me even more...
I bet some non-technical news guy thinks he is awesome for coming up with that
one.
On Nov 11, 2010, at 9:54 AM, "Daniel P. Brown" <daniel.br...@parasane.net>
wrote:
> On Thu, Nov 11, 2010 at 08:51, Robert Cummings <rob...@interjinn.com> wrote:
>>
>> Yeah, that and some Gateway with a Common Interface.
>
> My point was that there is now and never was any such PHP project
> known as pre-hypertext preprocessor. It originated as Personal Home
> Page Tools (PHP Tools) and Forms Interpreter (FI) --- the former was a
> series of C binaries, the latter was a CGI wrapper that actually
> preprocessed straight HTML by hopping in and out of <!--HTML
> Comments--> using SSI. For a short while, if memory serves me
> correctly, a version of the package was also named Personal Home Page
> Construction Kit. Eventually the packages merged into PHP/FI, and a
> rewrite was done sometime during 1997, I believe, which became PHP/FI
> 2.0. I first started using it back in 1996 for quick and simple tasks
> where Perl would be a bit overkill.
>
> The part I can't remember clearly is whether PHP/FI2 was done in
> 1996 or 1997, though, because I do remember it was the fall of 1997
> when PHP3 came out, and it blew me away. It sucked a bit having to
> now learn how to use the new PHP to build a page, but damned if it
> wasn't a trillion times easier to work with than Perl, right from the
> get-go. I remember being excited by the fact that I could rewrite a
> simple flat-file database Perl program I originally wrote in about
> three days in under two hours with PHP. From that point on, I was
> hooked on it, despite its quirky recursive-acronym name --- PHP:
> Hypertext Preprocessor.
>
> So when I asked if "pre-hypertext preprocessor" meant Perl, it
> could well have been Python, C/C++ on SSI, Tcl/Tk, or anything....
> anything, that is, that came "pre-" PHP.
>
> That said, I have seen references to PHP being named
> "Pre-Hypertext Preprocessor," but that would be incorrect anyway. The
> HTML (HyperText Markup Language) could be preprocessed, so that much
> is fine.... but "pre-hypertext" would be truly amusing. Any request
> to a web page is presently made via HTTP (HyperText Transfer
> Protocol), and any text displayed on any electronic device with
> embedded references (also known as hyperlinks).
>
> So any language that could pre-process pre-hypertext would either
> have the unique ability to foresee the future, the mundane ability to
> "pre-process" plain text (or request headers or anything prior to the
> data being classified as hypertext), or the disconcerting ability to
> modify reality as we know it. And why bother to do that when you
> could just <%= go elsewhere. %>? ;-P
>
>
>
> (It's felt like Friday all day.)
>
> --
> </Daniel P. Brown>
> Dedicated Servers, Cloud and Cloud Hybrid Solutions, VPS, Hosting
> (866-) 725-4321
> http://www.parasane.net/
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
On 11/11/10 12:04 PM, Michael Shadle wrote:
> Not to discredit this long post but the media here is now calling
> kids who text often "hypertexting teens" which really irked me
> even more...I bet some non-technical news guy thinks he is
> awesome for coming up with that one.
LOL! I too thought those kids were going around creating HTML pages
with their phones!
-- Dante
--- End Message ---
--- Begin Message ---
From: Daniel P. Brown
> On Thu, Nov 11, 2010 at 08:51, Robert Cummings <rob...@interjinn.com>
wrote:
>>
>> Yeah, that and some Gateway with a Common Interface.
>
> So any language that could pre-process pre-hypertext would either
> have the unique ability to foresee the future, the mundane ability to
> "pre-process" plain text (or request headers or anything prior to the
> data being classified as hypertext), or the disconcerting ability to
> modify reality as we know it. And why bother to do that when you
> could just <%= go elsewhere. %>? ;-P
One of the items at the top of our wish list for over two decades has
been a pre-causal response generator. Processing time for transactions
on point of sale systems has always been an issue for us, so we wanted
to have the response message ready before the transaction arrived. The
next item on that list is a neural interface specifically designed for
developers. Unfortunately, neither of those technologies has
materialized.
> (It's felt like Friday all day.)
It still feels like Monday here.
Bob McConnell
--- End Message ---
--- Begin Message ---
> So all you need to do, is take a look at $_SERVER['HTTP_ACCEPT_LANGUAGE'] to
> get a users language preferences.
Hi Nathan,
Yep, I'm using this var to set the default but I think it's nice to
allow the user to override it. Maybe someone using their computer is
more comfortable in a different language?
Marc
--- End Message ---
--- Begin Message ---
Marc Guay wrote:
So all you need to do, is take a look at $_SERVER['HTTP_ACCEPT_LANGUAGE'] to
get a users language preferences.
Hi Nathan,
Yep, I'm using this var to set the default but I think it's nice to
allow the user to override it. Maybe someone using their computer is
more comfortable in a different language?
So then surely that would be their default language?
However, there is of course the case where somebody wants to see both
english and german variations of the "same" page, so probabyl a good
use-case after all - session to the rescue!
--- End Message ---
--- Begin Message ---
I'm curious what the lists' opinions are regarding the use of an .ini
file versus an include configuration file in PHP code are?
I can see uses for either (or both).
To me, it seems that an .ini file would be ideal in the case where you
want to allow a simpler interface for people installing your app to
configure things that need configuring, and an included PHP code
configuration file for things you don't necessarily want the average
installer to change.
What do you think?
Tamara
--- End Message ---
--- Begin Message ---
Agreed.
--
João Cândido de Souza Neto
"Tamara Temple" <tamouse.li...@gmail.com> escreveu na mensagem
news:977f087c-bb11-4444-b851-21616ae9e...@gmail.com...
> I'm curious what the lists' opinions are regarding the use of an .ini
> file versus an include configuration file in PHP code are?
>
> I can see uses for either (or both).
>
> To me, it seems that an .ini file would be ideal in the case where you
> want to allow a simpler interface for people installing your app to
> configure things that need configuring, and an included PHP code
> configuration file for things you don't necessarily want the average
> installer to change.
>
> What do you think?
>
> Tamara
>
--- End Message ---
--- Begin Message ---
On Thu, 2010-11-11 at 17:16 -0200, Jo?o C?ndido de Souza Neto wrote:
> Agreed.
>
> --
> Joo Cndido de Souza Neto
>
> "Tamara Temple" <tamouse.li...@gmail.com> escreveu na mensagem
> news:977f087c-bb11-4444-b851-21616ae9e...@gmail.com...
> > I'm curious what the lists' opinions are regarding the use of an .ini
> > file versus an include configuration file in PHP code are?
> >
> > I can see uses for either (or both).
> >
> > To me, it seems that an .ini file would be ideal in the case where you
> > want to allow a simpler interface for people installing your app to
> > configure things that need configuring, and an included PHP code
> > configuration file for things you don't necessarily want the average
> > installer to change.
> >
> > What do you think?
> >
> > Tamara
> >
>
>
>
There are potential security concerns involved too. An .ini file will be
output as plain text by default by the web server if requested by a user
agent unless it is protected somehow (by a .htaccess file for example)
or it is outside of document root for the server. A PHP file on the
other hand will be parsed, so won't output it's variables.
It's all too easy to forget to protect an ini file from this sort of
thing, whereas if you've written a website in PHP, it becomes fairly
evident if your web server isn't configured for PHP without testing
specifically for it!
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
For configuration, I used to use .php file earlier.
I just used array syntax to keep the config values.
But now I use json syntax. Its easy like xml.
Ini file is much more user friendly than json though.
--
Shiplu Mokadd.im
My talks, http://talk.cmyweb.net
Follow me, http://twitter.com/shiplu
Innovation distinguishes bet ... ... (ask Steve Jobs the rest)
--- End Message ---
