Hello Lukas,
Monday, May 15, 2006, 8:43:41 AM, you wrote:
> Derick Rethans wrote:
>> On Sun, 14 May 2006, Marcus Boerger wrote:
>>
>>> That said i am about to not remove E_STRICT from E_ALL and MFH the php
>>> 6.0 to item just now.
>>> See: http://oss.backendmedia.com/PhP60 (add E_STRICT to E_A
Hello Pierre,
Monday, May 15, 2006, 2:39:02 AM, you wrote:
> On Sun, 14 May 2006 20:59:03 +0200
> [EMAIL PROTECTED] (Marcus Boerger) wrote:
>> That said i am about to not remove E_STRICT from E_ALL and MFH the php
>> 6.0 to item just now.
>> See: http://oss.backendmedia.com/PhP60 (add E_STRICT
Marcus Boerger wrote:
Sorry i have to say that but PEAR is no argument here as still after
years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing
a PHP 5 version here.
PEAR is PHP5 compatible. But you probably meant E_STRICT compatible.
Yes, I agree that PEAR needs to become
Wouldn't it be nice to start a PEAR2 (or 5) then, with PHP5-ready code,
where PHP5 features will actually be used and backwards compatibility for
PHP4 is lacking. The current PEAR could gradually be ported into this, and
PHP4-users can continue to use PEAR (version 1, if you will).
Ron
"Lukas
Ron Korving wrote:
Wouldn't it be nice to start a PEAR2 (or 5) then, with PHP5-ready code,
where PHP5 features will actually be used and backwards compatibility for
PHP4 is lacking. The current PEAR could gradually be ported into this, and
PHP4-users can continue to use PEAR (version 1, if you
Hi Edin,
Most bugs were fixed before 5.1.4 release.
I tested PHP with isapi_fcgi.dll, mod_fastcgi and zend_enabler.
Seems all work fine, but I cannot be sure that it works in all cases.
Thanks. Dmitry.
> -Original Message-
> From: Edin Kadribasic [mailto:[EMAIL PROTECTED]
> Sent: Saturd
On 5/15/06, Marcus Boerger <[EMAIL PROTECTED]> wrote:
Sorry i have to say that but PEAR is no argument here as still after
years of PHP 5 there is no PHP 5 compatible PEAR. Yet we are discussing
a PHP 5 version here.
This is a pointless argument. First there is php5 only packages.
Second you
Steph Fox wrote:
> Marcus,
>
> FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL
> switched on anywhere but a dev box? - and when there is the option to
> switch on E_ALL without E_STRICT, it makes it much easier to miss
> useful information about the direction PHP is going
My opinion is that if we intend to make something stop working (give
fatal error) in future releases we need to provide some form of
notice be it E_STRICT or E_NOTICE to our users now, so they can
anticipate the change. As far as inclusion of E_STRICT into E_ALL, I
think this is a good idea
On Mon, 15 May 2006, Ilia Alshanetsky wrote:
> My opinion is that if we intend to make something stop working (give fatal
> error) in future releases we need to provide some form of notice be it
> E_STRICT or E_NOTICE to our users now, so they can anticipate the change. As
> far as inclusion of E_
I suggest that we add E_STRICT now, but not include E_STRICT into
E_ALL, so people who are not using E_STRICT error reporting level
don't have their applications start spewing strict messages.
We cannot force people to change their code, all we can reasonably do
is provide notification mechan
Hello,
okay, mistakes happen everyday but it really sucks that PHP.net
continues trying to hide mistakes.
1) PHP 5.1.4 was released with a nonsense announcement claiming that
there was only a problem with POST arrays or POST fileuploads.
-> In reality a paid Zend developer had destroyed the h
Why would anyone have E_ALL
switched on anywhere but a dev box?
Working with Phorum, I get to peer into lots of different hosting
companies setups when helping my users. I have seen many hosts that do
have E_ALL enabled and do not log errors because they have no way to
provide that log back
On 15-May-06, at 9:39 AM, Stefan Esser wrote:
Hello,
okay, mistakes happen everyday but it really sucks that PHP.net
continues trying to hide mistakes.
1) PHP 5.1.4 was released with a nonsense announcement claiming that
there was only a problem with POST arrays or POST fileuploads.
-> In
Hey,
>
> The code in the release did not change on bit, the only change was the
> inclusion of the missing phar file, this hardly warrants 5.1.5 or even
> 5.1.4pl1. This will have no impact of people who have already
> downloaded and installed PHP, nor will this impact people who have yet
> to down
On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote:
...
> Side note: calling functions statically that do not have a static
> modifier causes E_STRICT. Hello PEAR::isError()
>
> This is of course going to be a fatal in PHP 6, but it is now the most
> common E_STRICT I see in PHP4-based code.
Y
Ilia Alshanetsky wrote:
> The code in the release did not change on bit, the only change was the
> inclusion of the missing phar file, this hardly warrants 5.1.5 or even
> 5.1.4pl1. This will have no impact of people who have already downloaded
> and installed PHP, nor will this impact people who h
Stefan,
Ironically
after that incident another Zend man came forward and dares to say "I
don't trust our core testers anymore"
He dared to say it because there's a QA mechanism in place that isn't
working - AKA a bunch of application developers testing Release Candidates
on their real-world
Stefan,
I don't see why this attack is directed at Zend people working on
PHP, where the release process is completely a community driven
effort (and last time I checked, no enterprise was involved in that
process either).
I agree the release process isn't perfect yet, and it becomes
increasi
On 15-May-06, at 11:50 AM, Stefan Esser wrote:
Hey,
The code in the release did not change on bit, the only change was
the
inclusion of the missing phar file, this hardly warrants 5.1.5 or
even
5.1.4pl1. This will have no impact of people who have already
downloaded and installed PHP, no
I'm on the latest and greatest PHP 5.1.4. I can see the function I
think I want in the manual:
http://us3.php.net/manual/en/function.xmlwriter-write-raw.php
But the manual says it's only in CVS. I confirmed that I don't have it:
* Fatal error: Call to undefined function xmlwriter_write_
Hello Andi,
> I don't see why this attack is directed at Zend people working on PHP,
> where the release process is completely a community driven effort (and
> last time I checked, no enterprise was involved in that process either).
Well I don't see why Zend people commit code that obviously broke
Why would anyone have E_ALL switched on anywhere but a dev box?
Working with Phorum, I get to peer into lots of different hosting
companies setups when helping my users. I have seen many hosts that do
have E_ALL enabled and do not log errors because they have no way to
provide that log back
>
> I'm on the latest and greatest PHP 5.1.4. I can see the
> function I think I want in the manual:
>
>http://us3.php.net/manual/en/function.xmlwriter-write-raw.php
>
> But the manual says it's only in CVS. I confirmed that I
> don't have it:
>
> * Fatal error: Call to undefined
I find it hard to believe that anyone
involved - host or user - isn't aware that E_STRICT is on its way.
Honestly, I only heard about it in the last few weeks. And I run an
open source project based on PHP. I do PHP for a living. The average
web host and/or webmaster does not keep up with t
At 09:32 AM 5/15/2006, Stefan Esser wrote:
Hello Andi,
> I don't see why this attack is directed at Zend people working on PHP,
> where the release process is completely a community driven effort (and
> last time I checked, no enterprise was involved in that process either).
Well I don't see why
> -Original Message-
> From: Stefan Esser [mailto:[EMAIL PROTECTED]
> Sent: Monday, May 15, 2006 8:32 PM
> To: Andi Gutmans
> Cc: PHP internals
> Subject: Re: [PHP-DEV] PHP Release Process Sucks
>
>
> Hello Andi,
> > I don't see why this attack is directed at Zend people
> working on PH
Hey Andi
> My point was that this has nothing to do with Zend or not Zend.
My point is not that someone from Zend broke it, but that someone from
Zend blamed the community that THEY failed to find the problem. I
thought Zend is enough into PHP to test their own products against RC's,
too. It makes
Hello Dmitry,
> It was my bug.
> I am writing a lot of code for PHP and as result do some bugs.
> I don't know a man who never does bugs.
>
Exactly. I (we) appreciate your work and the point was not that you
broke it. Like I replied to Andi, I also broke unserialize() in one of
the 4.3 releases
Jared Williams wrote:
http://us3.php.net/manual/en/function.xmlwriter-write-raw.php
Anyone know the status of this function, if it does what I
want, and what version I can start using it?
I originally requested it. http://pecl.php.net/bugs/bug.php?id=6267 . I think
it'll appear in 5.2,
http:/
On 15.05.2006 21:10, Stefan Esser wrote:
Hey Andi
My point was that this has nothing to do with Zend or not Zend.
My point is not that someone from Zend broke it, but that someone from
Zend blamed the community that THEY failed to find the problem. I
thought Zend is enough into PHP to test thei
On 15.05.2006 21:17, Stefan Esser wrote:
Hello Dmitry,
It was my bug.
I am writing a lot of code for PHP and as result do some bugs.
I don't know a man who never does bugs.
Exactly. I (we) appreciate your work and the point was not that you
broke it. Like I replied to Andi, I also broke unse
I agree with Andi on that (surprise surprise :)
What does that give you that class constants don't?
Zeev
At 18:34 12/05/2006, Andi Gutmans wrote:
I can see where it could come in handy but I honestly think it'd be bloat.
We have to relax with the OO features because the increased code
size h
Strike that, I was smoking something strong :) Class constants are
not really relevant for this use case.
At 20:57 15/05/2006, Zeev Suraski wrote:
I agree with Andi on that (surprise surprise :)
What does that give you that class constants don't?
Zeev
At 18:34 12/05/2006, Andi Gutmans wrot
Antony Dovgal wrote:
> So it makes me a bit angry when someone who did nothing (except for a
> couple of mails to internals@) for PHP since December starts treating me
> and Dmitry (who's one of the most active PHP contributors) like a
> millionaires who earned their millions from poor PHP communit
> So it makes me a bit angry when someone who did nothing (except for a
> couple of mails to internals@) for PHP since December starts treating
> me and Dmitry (who's one of the most active PHP contributors) like a
> millionaires who earned their millions from poor PHP community.
Tony, you have ob
I have to say that in second thought (after realizing what you really
meant) it sounds like a very useful feature.
The main thing that worries me is the complexity to the end user,
which is already in a pretty bad shape as it is today, and many
people here care very little about it, because th
Sebastian Bergmann wrote:
> Now this is an unfair argument as Stefan cannot (for whatever reasons)
> commit his work to cvs.php.net.
Strike that, I was educated about this on IRC just now. My initial
point is still valid to some degree, IMHO: just because Stefan's work
does not go into cvs.php.
Stefan,
If anything, that was a good drill on why it's not a good idea to
write sarcastic, negative emails to people. Unless of course, your
aim is to annoy them into starting a heated threads. You've raised
some good points in your original email, and it's a shame you diluted
your message
Sebastian Bergmann wrote:
Now this is an unfair argument as Stefan cannot (for whatever reasons)
commit his work to cvs.php.net.
Strike that, I was educated about this on IRC just now. My initial
point is still valid to some degree, IMHO: just because Stefan's work
does not go into cvs.php.net
Hello Brian,
Monday, May 15, 2006, 6:40:58 PM, you wrote:
>> I find it hard to believe that anyone
>> involved - host or user - isn't aware that E_STRICT is on its way.
> Honestly, I only heard about it in the last few weeks. And I run an
> open source project based on PHP. I do PHP for a li
Hello Todd,
Monday, May 15, 2006, 6:03:14 PM, you wrote:
> On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote:
> ...
>> Side note: calling functions statically that do not have a static
>> modifier causes E_STRICT. Hello PEAR::isError()
>>
>> This is of course going to be a fatal in PHP 6, bu
Zeev,
> Instead of discussing the points, we're discussing these pointless
> topics of who contributes more. I suggest we stop here, I think it's
> absurd to question the level of contribution from any of you three.
You are right. The discussion can stop here. Antony once again proved
every single
Hello Ilia,
Monday, May 15, 2006, 3:23:18 PM, you wrote:
> I suggest that we add E_STRICT now, but not include E_STRICT into
> E_ALL,
We added E_STRICT in what 5.0 or or 5.1? Guess i checked it:
[EMAIL PROTECTED] /usr/src/php-cvs $ cvs annotate Zend/zend_errors.h|grep
E_STRICT
Annotations fo
Hello Greg,
Monday, May 15, 2006, 12:51:16 PM, you wrote:
> Steph Fox wrote:
>> Marcus,
>>
>> FWIW I'm with you (unusually) over E_STRICT. Why would anyone have E_ALL
>> switched on anywhere but a dev box? - and when there is the option to
>> switch on E_ALL without E_STRICT, it makes it much e
Hello Stefan,
Monday, May 15, 2006, 6:32:25 PM, you wrote:
> Hello Andi,
>> I don't see why this attack is directed at Zend people working on PHP,
>> where the release process is completely a community driven effort (and
>> last time I checked, no enterprise was involved in that process either).
Ones again E_ALL is for development. For example to move PEAR code to PHP
5.
It is not for running legacy apps. IF you guys want i'd be ok with adding
a
new mode say "E_RUN"...
You think that - I think that. After Brian Moon's response I went and
checked what the INI files distributed with P
Steph Fox wrote:
ini-dist is set at E_ALL & ~E_NOTICE
ini-recommended is set at E_ALL
I'd guess that's why Brian reports seeing E_ALL enabled on web hosts;
they're advised to use the settings in ini-recommended, after all.
Perhaps there should be an ini-development and an ini-production.
--
On 5/14/06, Steph Fox <[EMAIL PROTECTED]> wrote:
> Ones again E_ALL is for development. For example to move PEAR code to PHP
> 5.
> It is not for running legacy apps. IF you guys want i'd be ok with adding
> a
> new mode say "E_RUN"...
You think that - I think that. After Brian Moon's response
Hello Brian,
yeah we should simply rename the two files we have right now to that.
I never knew which one to take since their names are not helpful.
In production we would set something like E_ALL & ~E_STRICT & ~E_NOTICE.
While in development we would do E_ALL as in all.
Nice idea!
best regard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marcus Burger wrote:
> Ones again E_ALL is for development.
Is this the statement of all developers or only yours?
I have to enable E_ALL on live servers (display_errors to 0), because
whatever resource you have at your hand, you just can't make sure
Marcus Boerger wrote:
Hello Brian,
yeah we should simply rename the two files we have right now to that.
I never knew which one to take since their names are not helpful.
In production we would set something like E_ALL & ~E_STRICT & ~E_NOTICE.
While in development we would do E_ALL as in all.
Hello Markus,
Monday, May 15, 2006, 9:04:20 PM, you wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> Marcus Burger wrote:
>> Ones again E_ALL is for development.
> Is this the statement of all developers or only yours?
Probably mine, I mean i can only speak for myself here.
> I have
At 21:29 15/05/2006, Stefan Esser wrote:
Zeev,
> Instead of discussing the points, we're discussing these pointless
> topics of who contributes more. I suggest we stop here, I think it's
> absurd to question the level of contribution from any of you three.
You are right. The discussion can stop
On Mon, 2006-05-15 at 20:27 +0200, Marcus Boerger wrote:
> Monday, May 15, 2006, 6:03:14 PM, you wrote:
> > On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote:
> > ...
> >> Side note: calling functions statically that do not have a static
> >> modifier causes E_STRICT. Hello PEAR::isError()
> >>
Sorry for the delay.
But I think that a new type specifier could be introduced. If not you are
saying to extensions writers to duplicate the code below a hundred times:
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "t", &name, &name_len,
&name_type) == FAILURE) {
return;
}
if (name
Hello Todd,
Monday, May 15, 2006, 9:32:21 PM, you wrote:
> On Mon, 2006-05-15 at 20:27 +0200, Marcus Boerger wrote:
>> Monday, May 15, 2006, 6:03:14 PM, you wrote:
>> > On Mon, 2006-05-15 at 06:51 -0400, Greg Beaver wrote:
>> > ...
>> >> Side note: calling functions statically that do not have a
Todd Ruth wrote:
I don't see benefits of making semi-static fatal that make it
worth keeping those of us with large apps that depend on semi-
static from upgrading to php6.
My sentiments exactly. OO purity/strictness do now work well with PHP's
main strength -- its dynamicity.
Edin
--
PHP I
Edin Kadribasic wrote:
> OO purity/strictness do now work well with PHP's main strength -- its
> dynamicity.
You make it sound like OO and dynamicity were mutually exclusive; they
are not. Take a look at Smalltalk or CLOS to see what I mean.
--
Sebastian Bergmann http://ww
Sebastian Bergmann wrote:
Edin Kadribasic wrote:
OO purity/strictness do now work well with PHP's main strength -- its
dynamicity.
You make it sound like OO and dynamicity were mutually exclusive; they
are not. Take a look at Smalltalk or CLOS to see what I mean.
I know, but often the ar
One of our customers reports that 5.1.4 fastcgi does not work, but
that 5.2 does.
It sounds like this needs to be addressed and a 5.1.5 released quickly.
--Wez.
On 5/15/06, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
Hi Edin,
Most bugs were fixed before 5.1.4 release.
I tested PHP with isapi_fcgi
Zeev Suraski wrote:
What does that give you that class constants don't?
i on the other hand fail to see how it is related to class constants
at all?
--
Hartmut Holzgraefe, Senior Support Engineer.
MySQL AB, www.mysql.com
Are you certified? http://www.mysql.com/tra
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Steph Fox wrote:
>> Ones again E_ALL is for development. For example to move PEAR code to
>> PHP 5.
>> It is not for running legacy apps. IF you guys want i'd be ok with
>> adding a
>> new mode say "E_RUN"...
>
> You think that - I think that. A
That assumes there are a hundred places where you want to receive an
ASCII string. Are they really that prevalent?
-Andrei
On May 15, 2006, at 12:42 PM, Nuno Lopes wrote:
Sorry for the delay.
But I think that a new type specifier could be introduced. If not you
are saying to extensions write
On Mon, May 15, 2006 9:41 am, Brian Moon wrote:
>> Why would anyone have E_ALL
>> switched on anywhere but a dev box?
>
> Working with Phorum, I get to peer into lots of different hosting
> companies setups when helping my users. I have seen many hosts that
> do
> have E_ALL enabled and do not log
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Zeev Suraski wrote:
> I have to say that in second thought (after realizing what you really
> meant) it sounds like a very useful feature.
[snip]
> In order to push complexity down I'd avoid making this yet another
> modifier, and in fact make thi
Looking only to the tidy extension:
tidy_parse_string
tidy_parse_file
tidy_repair_string
tidy_repair_file
tidy_getopt
tidy::__constructor
tidy::parseFile
tidy::parseString
I would say that others extensions will need too. Think in charset names,
options names, options values, etc..
Nuno
That
A quick Google for common PHP error messages will almost for sure find
you a zillion sites with E_ALL in production servers.
2.1 million in fact.
http://www.google.com/search?q=notice+undefined+php
--
Brian Moon
-
http://dealnews.com/
Its good to be cheap =)
--
PHP Internals - PH
Are you sure want to generate a hard error if tidy_parse_string()
doesn't get an ASCII string?
-Andrei
On May 15, 2006, at 2:30 PM, Nuno Lopes wrote:
Looking only to the tidy extension:
tidy_parse_string
tidy_parse_file
tidy_repair_string
tidy_repair_file
tidy_getopt
tidy::__constructor
tidy:
Hello Zeev,
In the same way that public readonly properties would be useful
from the global scope, protected readonly properties would be just
as useful to those of us who spend their php-lives writing base
classes (like me) for others to extend and use.
I would imagine that the Zend Fr
I was not refering to the html/xhtml/xml input. I was talking about the
charset parameter, for example. I don't want a chinese string passed as the
charset name (the libtidy API isn't localized yet :) ). The same applies for
the other functions.
Nuno
Are you sure want to generate a hard error
On Mon, May 15, 2006 1:59 pm, Marcus Boerger wrote:
> yeah we should simply rename the two files we have right now to
> that.
> I never knew which one to take since their names are not helpful.
> In production we would set something like E_ALL & ~E_STRICT &
> ~E_NOTICE.
> While in development we
On Mon, 15 May 2006, Nuno Lopes wrote:
> I was not refering to the html/xhtml/xml input. I was talking about the
> charset parameter, for example. I don't want a chinese string passed as the
> charset name (the libtidy API isn't localized yet :) ). The same applies for
> the other functions.
Yeah
On Mon, May 15, 2006 2:19 pm, Marcus Boerger wrote:
> This is very true, yet i don't see a reason to include E_NOTICE and
> E_STRICT
> on a production machine.
You've got 100% code coverage with all possible inputs and boundary
conditions in your QA process?...
Cuz, if not, I really don't see why
On Mon, May 15, 2006 3:17 pm, Sebastian Bergmann wrote:
> Edin Kadribasic wrote:
>> OO purity/strictness do now work well with PHP's main strength --
>> its
>> dynamicity.
>
> You make it sound like OO and dynamicity were mutually exclusive;
> they
> are not. Take a look at Smalltalk or CLOS to s
Hartmut Holzgraefe wrote:
Zeev Suraski wrote:
What does that give you that class constants don't?
i on the other hand fail to see how it is related to class constants
at all?
hm ... this was not supposed to get out as i had seen your reply
to yourself ...
--
Hartmut Holzgraefe, Senior Suppo
On Mon, 15 May 2006, Nuno Lopes wrote:
I was not refering to the html/xhtml/xml input. I was talking about the
charset parameter, for example. I don't want a chinese string passed as
the
charset name (the libtidy API isn't localized yet :) ). The same applies
for
the other functions.
Yeah,
On Mon, May 15, 2006 4:19 pm, Andrei Zmievski wrote:
> That assumes there are a hundred places where you want to receive an
> ASCII string. Are they really that prevalent?
How many of the extension libraries are Unicode-ready?
You see an awful lot of users with quasi-Unicode data that gets into
t
On Mon, May 15, 2006 2:47 pm, Marcus Boerger wrote:
>> [...] Is there a significant performance
>> enhancement in the engine that depends on eliminating semi-static
>> or somesuch?
>
> Security. We might as well enable the crash function in non debug
> builds.
> Or just drop 'static' again and go
Derick,
The case we're talking about here is where a Unicode string containing
only ASCII characters is passed to an extension, not a binary string
with the same characters.
-Andrei
On May 15, 2006, at 2:53 PM, Derick Rethans wrote:
Yeah, but that doesnt mean you need to throw a hard error
Interesting, what os is this one and can they provide more info in
regard to what "does not work" ?
On 15-May-06, at 4:26 PM, Wez Furlong wrote:
One of our customers reports that 5.1.4 fastcgi does not work, but
that 5.2 does.
It sounds like this needs to be addressed and a 5.1.5 released
Erhm... I meant, add E_STRICT warning message to the code to the
deprecated oo code.
On 15-May-06, at 2:35 PM, Marcus Boerger wrote:
Hello Ilia,
Monday, May 15, 2006, 3:23:18 PM, you wrote:
I suggest that we add E_STRICT now, but not include E_STRICT into
E_ALL,
We added E_STRICT in wha
Marcus Boerger wrote:
To rephrase Andi "So people screw up. I prefer having the occasional
screw up then less people helping out." We are a community [...]
What we need is more helping hands and less comlaining notes. Actually
we are constantly working on increasing or QA efforts. And from my
po
Would a method be able to return a writable reference of this
readonly property? If not it'd actually be PITA to prevent this. This
is one of those questions which can turn a two second patch by
Marcus, to an ongoing patch where we continue to fix various places
and continue to bloat the langua
At 11:49 AM 5/15/2006, Brian Moon wrote:
Steph Fox wrote:
ini-dist is set at E_ALL & ~E_NOTICE
ini-recommended is set at E_ALL
I'd guess that's why Brian reports seeing E_ALL enabled on web
hosts; they're advised to use the settings in ini-recommended, after all.
Perhaps there should be an in
I don't see why it has to be a fatal error. If there's an instanceof
relationship we can keep $this. If not, we should not pass $this
(which I believe we already do in PHP 5), in which case the author
would have to pass $this if he wants to change public properties.
Andi
At 12:49 PM 5/15/2006
At 11:49 AM 5/15/2006, Brian Moon wrote:
Perhaps there should be an ini-development and an ini-production.
"recommended" was born after "dist" because we wanted to show how to run
PHP correctly (esp. BC breaking INI parameters such as
register_globals=off which are recommended). It's a bit di
If your production PHP code is generating so many entires in a log
file that it's a problem for the log file size, then, really, you've
got much bigger problems than the log file size...
At dealnews, we have been using PHP since PHP/FI. We have written A LOT
of code that never expected E_NOTIC
88 matches
Mail list logo
