f



Migrate PHP 2.0 code to PHP 5.x

Hello ppl,

I have old php code that is written in PHP 2 version... now i want to
move/ migrate the whole code into latest version of PHP.
Is there any tool or tips and tracks to migrate code.


~thanks
Vijay.
0
8/7/2009 2:33:33 PM
comp.lang.php 32646 articles. 0 followers. Post Follow

32 Replies
1209 Views

Similar Articles

[PageSpeed] 3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vm wrote:
> Hello ppl,
> 
> I have old php code that is written in PHP 2 version... now i want to
> move/ migrate the whole code into latest version of PHP.
> Is there any tool or tips and tracks to migrate code.
> 
> 
> ~thanks
> Vijay.

Hello,

well, have a look at the register gloabls settings and other gloabl vars.

then I would use the following in the old code:


ini_set('error_reporting',8191); // E_ALL & E_STRICT
ini_set('display_errors',true);

and then just run it and have a look at the error messages which will come up.

I don't know about any automated way to make this.
It will be try and fix errors, to solve this.

regards,
johannes ke�ler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkp8PCQACgkQE++2Zdc7Etc3xwCgqMEGEkrSbcBpV5xUl3UerZ7K
YQQAn12Fk+bg0lQ+lo0CxaxysqPwPOaE
=Oq26
-----END PGP SIGNATURE-----
0
mail1382 (206)
8/7/2009 2:37:24 PM
On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
wrote: 

> Vm wrote:
>> Hello ppl,
>> 
>> I have old php code that is written in PHP 2 version... now i
>> want to move/ migrate the whole code into latest version of
>> PHP. Is there any tool or tips and tracks to migrate code.
> 
> Hello,
> 
> well, have a look at the register gloabls settings and other
> gloabl vars. 
> 
> then I would use the following in the old code:
> 
> 
> ini_set('error_reporting',8191); // E_ALL & E_STRICT

No need to hard code the int value.  Also, E_ALL & E_STRICT is 
probably not what you meant:

  /* Reports all errors, warnings, and strict warnings */
  ini_set('error_reporting', E_ALL | E_STRICT);

@OP:  use this error_reporting value in your php.ini in your 
development environment along with display_errors.

> ini_set('display_errors',true);

In the production environment, do not enable display_errors, log 
them instead.

> and then just run it and have a look at the error messages which
> will come up. 
> 
> I don't know about any automated way to make this.
> It will be try and fix errors, to solve this.

In the PHP docs, there are migration pages that help move from PHP 4 
to 5, and PHP 5 to PHP 5.3.

Some of the biggest issues will be not relying on register_globals, 
magic_quotes, and using the superglobals.

From 4 to 5:  <http://php.net/manual/en/migration5.php>
From 5.0.x to 5.1.x: <http://php.net/manual/en/migration51.php>
....

-- 
~Curtis Dyer
<? $x='<? $x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>
0
dyer85 (342)
8/8/2009 5:43:04 AM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Curtis Dyer wrote:
> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
> wrote: 
> 
>> Vm wrote:
>>> Hello ppl,
>>>
>>> I have old php code that is written in PHP 2 version... now i
>>> want to move/ migrate the whole code into latest version of
>>> PHP. Is there any tool or tips and tracks to migrate code.
>> Hello,
>>
>> well, have a look at the register gloabls settings and other
>> gloabl vars. 
>>
>> then I would use the following in the old code:
>>
>>
>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
> 
> No need to hard code the int value.  Also, E_ALL & E_STRICT is 
> probably not what you meant:
Wrong. I meant it the way I said it.
Also I do not see anything why I should not use the int value...
> 
>   /* Reports all errors, warnings, and strict warnings */
>   ini_set('error_reporting', E_ALL | E_STRICT);
> 
> @OP:  use this error_reporting value in your php.ini in your 
> development environment along with display_errors.
> 
>> ini_set('display_errors',true);
> 
> In the production environment, do not enable display_errors, log 
> them instead.
That is true, I just wanted to show a way to get all the errors and fix them.
> 
>> and then just run it and have a look at the error messages which
>> will come up. 
>>
>> I don't know about any automated way to make this.
>> It will be try and fix errors, to solve this.
> 
> In the PHP docs, there are migration pages that help move from PHP 4 
> to 5, and PHP 5 to PHP 5.3.
> 
> Some of the biggest issues will be not relying on register_globals, 
> magic_quotes, and using the superglobals.
> 
> From 4 to 5:  <http://php.net/manual/en/migration5.php>
> From 5.0.x to 5.1.x: <http://php.net/manual/en/migration51.php>
> ...
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkp/tT8ACgkQE++2Zdc7EtecvACggCvvF/qrJaG1GAIqKPKoj7Za
G64AnRY+fVIDBSZI/gqLNq1agF04r+mF
=Qah0
-----END PGP SIGNATURE-----
0
mail1382 (206)
8/10/2009 5:50:55 AM
johannes keßler schreef:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Curtis Dyer wrote:
>> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
>> wrote: 
>>
>>> Vm wrote:
>>>> Hello ppl,
>>>>
>>>> I have old php code that is written in PHP 2 version... now i
>>>> want to move/ migrate the whole code into latest version of
>>>> PHP. Is there any tool or tips and tracks to migrate code.
>>> Hello,
>>>
>>> well, have a look at the register gloabls settings and other
>>> gloabl vars. 
>>>
>>> then I would use the following in the old code:
>>>
>>>
>>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
>> No need to hard code the int value.  Also, E_ALL & E_STRICT is 
>> probably not what you meant:
> Wrong. I meant it the way I said it.
> Also I do not see anything why I should not use the int value...


The actual values of constants may be subject to change in the future. 
If you actually use the constants, then you don't need to worry about that.

-- 
Amygdala
http://amygdala.110mb.com/
0
example (178)
8/10/2009 6:00:00 AM
Vm escribi�:
> I have old php code that is written in PHP 2 version... now i want to
>  move/ migrate the whole code into latest version of PHP. Is there 
> any tool or tips and tracks to migrate code.

Do you really mean version 2? Good old PHP/FI 2.0 released in 1997? As 
far as I know, it hardly resembles current PHP. To all effects, they're 
completely different languages.



-- 
-- http://alvaro.es - �lvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programaci�n web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
0
8/10/2009 6:49:10 AM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

amygdala wrote:
> johannes keßler schreef:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Curtis Dyer wrote:
>>> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
>>> wrote:
>>>> Vm wrote:
>>>>> Hello ppl,
>>>>>
>>>>> I have old php code that is written in PHP 2 version... now i
>>>>> want to move/ migrate the whole code into latest version of
>>>>> PHP. Is there any tool or tips and tracks to migrate code.
>>>> Hello,
>>>>
>>>> well, have a look at the register gloabls settings and other
>>>> gloabl vars.
>>>> then I would use the following in the old code:
>>>>
>>>>
>>>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
>>> No need to hard code the int value.  Also, E_ALL & E_STRICT is
>>> probably not what you meant:
>> Wrong. I meant it the way I said it.
>> Also I do not see anything why I should not use the int value...
> 
> 
> The actual values of constants may be subject to change in the future.
> If you actually use the constants, then you don't need to worry about that.
> 
Ok fine, but until then It will work. And if the change will be ready, there
will be a error for it ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkp/2yEACgkQE++2Zdc7EteCQwCfQgzGImfyRkqpa8I599C8FZP2
zwsAnjza3vlQSBREqVMMI/kaiofxFoIB
=mB8w
-----END PGP SIGNATURE-----
0
mail1382 (206)
8/10/2009 8:32:33 AM
On 09 Aug 2009, <mail@bananas-playground.net> wrote: 

> Curtis Dyer wrote:
>> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
>> wrote: 
>> 
>>> Vm wrote:

<snip>

>>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
>> 
>> No need to hard code the int value.  Also, E_ALL & E_STRICT is 
>> probably not what you meant:
> 
> Wrong. I meant it the way I said it.

Perhaps I misread your comment as showing the equivalent bitwise 
expression, in which case you intended to use "&" as a 
conjunction.  However, due to the ambiguity there, it was hard to 
tell what you meant.

> Also I do not see anything why I should not use the int value...

Your assumption that "8191" is the same as E_ALL | E_STRICT is 
only valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP 5.1.x, 
PHP 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change again in 
PHP 6.

Another portable way to enable all levels of error reporting is to 
pass `-1' to error_reporting().  This should also work with Apache 
PHP config directives (where the E_* constants aren't available).

  ini_set('error_reporting', -1);

So, at best, your answer is unnecessarily unportable or, at worst, 
just plain wrong.

<snip>

-- 
~Curtis Dyer
<? $x='<? $x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>
0
dyer85 (342)
8/10/2009 10:19:17 AM
amygdala wrote:
> johannes keßler schreef:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Curtis Dyer wrote:
>>> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
>>> wrote:
>>>> Vm wrote:
>>>>> Hello ppl,
>>>>>
>>>>> I have old php code that is written in PHP 2 version... now i
>>>>> want to move/ migrate the whole code into latest version of
>>>>> PHP. Is there any tool or tips and tracks to migrate code.
>>>> Hello,
>>>>
>>>> well, have a look at the register gloabls settings and other
>>>> gloabl vars.
>>>> then I would use the following in the old code:
>>>>
>>>>
>>>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
>>> No need to hard code the int value.  Also, E_ALL & E_STRICT is 
>>> probably not what you meant:
>> Wrong. I meant it the way I said it.
>> Also I do not see anything why I should not use the int value...
> 
> 
> The actual values of constants may be subject to change in the future. 
> If you actually use the constants, then you don't need to worry about that.
> 

No, the values of those constants will NOT change.  Doing so will break 
a large number of sites.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
8/10/2009 10:52:55 AM
johannes keßler wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> amygdala wrote:
>> johannes keßler schreef:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Curtis Dyer wrote:
>>>> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
>>>> wrote:
>>>>> Vm wrote:
>>>>>> Hello ppl,
>>>>>>
>>>>>> I have old php code that is written in PHP 2 version... now i
>>>>>> want to move/ migrate the whole code into latest version of
>>>>>> PHP. Is there any tool or tips and tracks to migrate code.
>>>>> Hello,
>>>>>
>>>>> well, have a look at the register gloabls settings and other
>>>>> gloabl vars.
>>>>> then I would use the following in the old code:
>>>>>
>>>>>
>>>>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
>>>> No need to hard code the int value.  Also, E_ALL & E_STRICT is
>>>> probably not what you meant:
>>> Wrong. I meant it the way I said it.
>>> Also I do not see anything why I should not use the int value...
>>
>> The actual values of constants may be subject to change in the future.
>> If you actually use the constants, then you don't need to worry about that.
>>
> Ok fine, but until then It will work. And if the change will be ready, there
> will be a error for it ;-)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.11 (GNU/Linux)
> 
> iEYEARECAAYFAkp/2yEACgkQE++2Zdc7EteCQwCfQgzGImfyRkqpa8I599C8FZP2
> zwsAnjza3vlQSBREqVMMI/kaiofxFoIB
> =mB8w
> -----END PGP SIGNATURE-----

Don't worry about him, johannes.  He has no idea what he's talking about 
(as usual).  Changing these constants will break a lot of sites.

However, I do think it's better to use the constants where you can, just 
for clarity.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
8/10/2009 10:54:30 AM
Curtis Dyer wrote:
> On 09 Aug 2009, <mail@bananas-playground.net> wrote: 
> 
>> Curtis Dyer wrote:
>>> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
>>> wrote: 
>>>
>>>> Vm wrote:
> 
> <snip>
> 
>>>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
>>> No need to hard code the int value.  Also, E_ALL & E_STRICT is 
>>> probably not what you meant:
>> Wrong. I meant it the way I said it.
> 
> Perhaps I misread your comment as showing the equivalent bitwise 
> expression, in which case you intended to use "&" as a 
> conjunction.  However, due to the ambiguity there, it was hard to 
> tell what you meant.
> 
>> Also I do not see anything why I should not use the int value...
> 
> Your assumption that "8191" is the same as E_ALL | E_STRICT is 
> only valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP 5.1.x, 
> PHP 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change again in 
> PHP 6.
>

Incorrect.  E_ALL is the same in most of those versions, and will be so 
in PHP 6.  E_STRICT was added - but there is no harm in enabling an 
extra bit which is not used in other versions.

> Another portable way to enable all levels of error reporting is to 
> pass `-1' to error_reporting().  This should also work with Apache 
> PHP config directives (where the E_* constants aren't available).
> 
>   ini_set('error_reporting', -1);
>

Which sets even more unused bits.

> So, at best, your answer is unnecessarily unportable or, at worst, 
> just plain wrong.
> 
> <snip>
> 

Incorrect.  In fact, there are places you CAN'T use the E_ constants and 
must use the integer values.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
8/10/2009 10:57:12 AM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Curtis Dyer wrote:
> On 09 Aug 2009, <mail@bananas-playground.net> wrote: 
> 
>> Curtis Dyer wrote:
>>> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
>>> wrote: 
>>>
>>>> Vm wrote:
> 
> <snip>
> 
>>>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
>>> No need to hard code the int value.  Also, E_ALL & E_STRICT is 
>>> probably not what you meant:
>> Wrong. I meant it the way I said it.
> 
> Perhaps I misread your comment as showing the equivalent bitwise 
> expression, in which case you intended to use "&" as a 
> conjunction.  However, due to the ambiguity there, it was hard to 
> tell what you meant.
> 
>> Also I do not see anything why I should not use the int value...
> 
> Your assumption that "8191" is the same as E_ALL | E_STRICT is 
> only valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP 5.1.x, 
> PHP 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change again in 
> PHP 6.
> 
> Another portable way to enable all levels of error reporting is to 
> pass `-1' to error_reporting().  This should also work with Apache 
> PHP config directives (where the E_* constants aren't available).
> 
>   ini_set('error_reporting', -1);
> 
> So, at best, your answer is unnecessarily unportable or, at worst, 
> just plain wrong.
> 
> <snip>
> 

phew....,

he asked for a way to solve the migration issue.

He didn't ask for a "for everytime valid" solution to do this.

I provided only one of many solutions for this problem. And if he is up to do
this migration, he will be able to use my advice and determine if he can use it
or not.

It was only a suggestion, it is up to everybody to use it or not...

reagards,
johannes keßler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkp//ZQACgkQE++2Zdc7EtfhMQCfWl8HNEQxBXwwB6HfbTPbZnTL
6ggAnj9T8YHTXgx52sYXjczzg/gkOCJA
=6giC
-----END PGP SIGNATURE-----
0
mail1382 (206)
8/10/2009 10:59:32 AM
Jerry Stuckle schreef:
> Curtis Dyer wrote:
>>
>> Your assumption that "8191" is the same as E_ALL | E_STRICT is only 
>> valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP 5.1.x, PHP 
>> 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change again in PHP 6.
>>
> 
> Incorrect.  E_ALL is the same in most of those versions, and will be so 
> in PHP 6.  E_STRICT was added - but there is no harm in enabling an 
> extra bit which is not used in other versions.

Wow, you are really talking out of your ass these days aren't you Jerry? 
You stubborn idiot. Talk about giving of wrong advice (as I saw you 
accuse somebody of doing in c.d.mysql)

Let's go to:
http://www.php.net/manual/en/errorfunc.constants.php

Shall we?

Let's see now... hmmm, for E_ALL it says in the Note column:

"32767 in PHP 6, 30719 in PHP 5.3.x, 6143 in PHP 5.2.x, 2047 previously"

My god, you really do like to spit out shit, don't you?

-- 
Amygdala
http://amygdala.110mb.com/
0
example (178)
8/10/2009 11:08:15 AM
Jerry Stuckle escribió:
> amygdala wrote:
>> johannes keßler schreef:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Curtis Dyer wrote:
>>>> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
>>>> wrote:
>>>>> Vm wrote:
>>>>>> Hello ppl,
>>>>>>
>>>>>> I have old php code that is written in PHP 2 version... now i
>>>>>> want to move/ migrate the whole code into latest version of
>>>>>> PHP. Is there any tool or tips and tracks to migrate code.
>>>>> Hello,
>>>>>
>>>>> well, have a look at the register gloabls settings and other
>>>>> gloabl vars.
>>>>> then I would use the following in the old code:
>>>>>
>>>>>
>>>>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
>>>> No need to hard code the int value.  Also, E_ALL & E_STRICT is 
>>>> probably not what you meant:
>>> Wrong. I meant it the way I said it.
>>> Also I do not see anything why I should not use the int value...
>>
>>
>> The actual values of constants may be subject to change in the future. 
>> If you actually use the constants, then you don't need to worry about 
>> that.
>>
> 
> No, the values of those constants will NOT change.  Doing so will break 
> a large number of sites.

E_ALL has been changed in the past and it can be changed again:

"since error levels will be added over time, the maximum value (for 
E_ALL) will likely change. So in place of E_ALL consider using a larger 
value to cover all bit fields from now and well into the future, a 
numeric value like 2147483647."

http://es.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting

Whether they'll do it or not, who knows.


-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
0
8/10/2009 11:46:51 AM
Álvaro G. Vicario wrote:
> Jerry Stuckle escribió:
>> amygdala wrote:
>>> johannes keßler schreef:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Curtis Dyer wrote:
>>>>> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
>>>>> wrote:
>>>>>> Vm wrote:
>>>>>>> Hello ppl,
>>>>>>>
>>>>>>> I have old php code that is written in PHP 2 version... now i
>>>>>>> want to move/ migrate the whole code into latest version of
>>>>>>> PHP. Is there any tool or tips and tracks to migrate code.
>>>>>> Hello,
>>>>>>
>>>>>> well, have a look at the register gloabls settings and other
>>>>>> gloabl vars.
>>>>>> then I would use the following in the old code:
>>>>>>
>>>>>>
>>>>>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
>>>>> No need to hard code the int value.  Also, E_ALL & E_STRICT is 
>>>>> probably not what you meant:
>>>> Wrong. I meant it the way I said it.
>>>> Also I do not see anything why I should not use the int value...
>>>
>>>
>>> The actual values of constants may be subject to change in the 
>>> future. If you actually use the constants, then you don't need to 
>>> worry about that.
>>>
>>
>> No, the values of those constants will NOT change.  Doing so will 
>> break a large number of sites.
> 
> E_ALL has been changed in the past and it can be changed again:
> 
> "since error levels will be added over time, the maximum value (for 
> E_ALL) will likely change. So in place of E_ALL consider using a larger 
> value to cover all bit fields from now and well into the future, a 
> numeric value like 2147483647."
> 
> http://es.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
> 
> Whether they'll do it or not, who knows.
> 
> 

Yes, it has been ADDED TO.  But that did not change the existing 
behavior of the numeric constants.  All it did was add additional 
options not available in previous versions.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
8/10/2009 11:48:41 AM
amygdala wrote:
> Jerry Stuckle schreef:
>> Curtis Dyer wrote:
>>>
>>> Your assumption that "8191" is the same as E_ALL | E_STRICT is only 
>>> valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP 5.1.x, PHP 
>>> 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change again in PHP 6.
>>>
>>
>> Incorrect.  E_ALL is the same in most of those versions, and will be 
>> so in PHP 6.  E_STRICT was added - but there is no harm in enabling an 
>> extra bit which is not used in other versions.
> 
> Wow, you are really talking out of your ass these days aren't you Jerry? 
> You stubborn idiot. Talk about giving of wrong advice (as I saw you 
> accuse somebody of doing in c.d.mysql)
> 
> Let's go to:
> http://www.php.net/manual/en/errorfunc.constants.php
> 
> Shall we?
> 
> Let's see now... hmmm, for E_ALL it says in the Note column:
> 
> "32767 in PHP 6, 30719 in PHP 5.3.x, 6143 in PHP 5.2.x, 2047 previously"
> 
> My god, you really do like to spit out shit, don't you?
> 

Yep, and if you didn't have your head so far up your ass, you'd figure 
out that each of those constants still means the same thing in PHP 5.x.

They added bits to E_ALL.  But they have never changed the values of the 
existing bits.  They still do exactly what they did in earlier versions 
of PHP, and will continue to do so in future versions.

But it would take someone with a modicum of intelligence to figure that 
out - which you don't have.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
8/10/2009 11:50:56 AM
Jerry Stuckle escribió:
> Álvaro G. Vicario wrote:
>> Jerry Stuckle escribió:
>>> amygdala wrote:
>>>> johannes keßler schreef:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Curtis Dyer wrote:
>>>>>> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
>>>>>> wrote:
>>>>>>> Vm wrote:
>>>>>>>> Hello ppl,
>>>>>>>>
>>>>>>>> I have old php code that is written in PHP 2 version... now i
>>>>>>>> want to move/ migrate the whole code into latest version of
>>>>>>>> PHP. Is there any tool or tips and tracks to migrate code.
>>>>>>> Hello,
>>>>>>>
>>>>>>> well, have a look at the register gloabls settings and other
>>>>>>> gloabl vars.
>>>>>>> then I would use the following in the old code:
>>>>>>>
>>>>>>>
>>>>>>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
>>>>>> No need to hard code the int value.  Also, E_ALL & E_STRICT is 
>>>>>> probably not what you meant:
>>>>> Wrong. I meant it the way I said it.
>>>>> Also I do not see anything why I should not use the int value...
>>>>
>>>>
>>>> The actual values of constants may be subject to change in the 
>>>> future. If you actually use the constants, then you don't need to 
>>>> worry about that.
>>>>
>>>
>>> No, the values of those constants will NOT change.  Doing so will 
>>> break a large number of sites.
>>
>> E_ALL has been changed in the past and it can be changed again:
>>
>> "since error levels will be added over time, the maximum value (for 
>> E_ALL) will likely change. So in place of E_ALL consider using a 
>> larger value to cover all bit fields from now and well into the 
>> future, a numeric value like 2147483647."
>>
>> http://es.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting 
>>
>>
>> Whether they'll do it or not, who knows.
>>
>>
> 
> Yes, it has been ADDED TO.  But that did not change the existing 
> behavior of the numeric constants.  All it did was add additional 
> options not available in previous versions.

Sorry, when you said "actual values of constants" I understood you were 
referring to the _numeric_ values. Of course, the behaviour remains 
mostly the same.



-- 
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
0
8/10/2009 11:58:53 AM
Jerry Stuckle schreef:
> amygdala wrote:
>> Jerry Stuckle schreef:
>>> Curtis Dyer wrote:
>>>>
>>>> Your assumption that "8191" is the same as E_ALL | E_STRICT is only 
>>>> valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP 5.1.x, PHP 
>>>> 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change again in PHP 6.
>>>>
>>>
>>> Incorrect.  E_ALL is the same in most of those versions, and will be 
>>> so in PHP 6.  E_STRICT was added - but there is no harm in enabling 
>>> an extra bit which is not used in other versions.
>>
>> Wow, you are really talking out of your ass these days aren't you 
>> Jerry? You stubborn idiot. Talk about giving of wrong advice (as I saw 
>> you accuse somebody of doing in c.d.mysql)
>>
>> Let's go to:
>> http://www.php.net/manual/en/errorfunc.constants.php
>>
>> Shall we?
>>
>> Let's see now... hmmm, for E_ALL it says in the Note column:
>>
>> "32767 in PHP 6, 30719 in PHP 5.3.x, 6143 in PHP 5.2.x, 2047 previously"
>>
>> My god, you really do like to spit out shit, don't you?
>>
> 
> Yep, and if you didn't have your head so far up your ass, you'd figure 
> out that each of those constants still means the same thing in PHP 5.x.
> 


Yes, but where not talking about keeping it working in only one version 
of PHP now are we? We want to keep it scalable. Isn't that one of your 
mantra's you always like to rub in peoples faces?

E_ALL has altered value three times for 5.x versions! What happens if 
your on a shared host (on which many developers have websites) that 
upgraded to a new minor or major PHP version?

How would you get notified of:
E_RECOVERABLE_ERROR in 5.2
E_DEPRECATED and E_USER_DEPRECATED in 6.x

Talk about once head up his ass. Moron.

-- 
Amygdala
http://amygdala.110mb.com/
0
example (178)
8/10/2009 12:04:57 PM
Jerry Stuckle schreef:
> Yep, and if you didn't have your head so far up your ass, you'd figure 
> out that each of those constants still means the same thing in PHP 5.x.
> 
> They added bits to E_ALL.  But they have never changed the values of the 
> existing bits.  They still do exactly what they did in earlier versions 
> of PHP, and will continue to do so in future versions.
> 
> But it would take someone with a modicum of intelligence to figure that 
> out - which you don't have.
> 

By the way, still waiting for your example code to proof the 
encapsulation example I showed wrong.

Twat.

-- 
Amygdala
http://amygdala.110mb.com/
0
example (178)
8/10/2009 12:09:51 PM
Álvaro G. Vicario wrote:
> Jerry Stuckle escribió:
>> Álvaro G. Vicario wrote:
>>> Jerry Stuckle escribió:
>>>> amygdala wrote:
>>>>> johannes keßler schreef:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> Curtis Dyer wrote:
>>>>>>> On 07 Aug 2009, johannes ke�ler <mail@bananas-playground.net>
>>>>>>> wrote:
>>>>>>>> Vm wrote:
>>>>>>>>> Hello ppl,
>>>>>>>>>
>>>>>>>>> I have old php code that is written in PHP 2 version... now i
>>>>>>>>> want to move/ migrate the whole code into latest version of
>>>>>>>>> PHP. Is there any tool or tips and tracks to migrate code.
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> well, have a look at the register gloabls settings and other
>>>>>>>> gloabl vars.
>>>>>>>> then I would use the following in the old code:
>>>>>>>>
>>>>>>>>
>>>>>>>> ini_set('error_reporting',8191); // E_ALL & E_STRICT
>>>>>>> No need to hard code the int value.  Also, E_ALL & E_STRICT is 
>>>>>>> probably not what you meant:
>>>>>> Wrong. I meant it the way I said it.
>>>>>> Also I do not see anything why I should not use the int value...
>>>>>
>>>>>
>>>>> The actual values of constants may be subject to change in the 
>>>>> future. If you actually use the constants, then you don't need to 
>>>>> worry about that.
>>>>>
>>>>
>>>> No, the values of those constants will NOT change.  Doing so will 
>>>> break a large number of sites.
>>>
>>> E_ALL has been changed in the past and it can be changed again:
>>>
>>> "since error levels will be added over time, the maximum value (for 
>>> E_ALL) will likely change. So in place of E_ALL consider using a 
>>> larger value to cover all bit fields from now and well into the 
>>> future, a numeric value like 2147483647."
>>>
>>> http://es.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting 
>>>
>>>
>>> Whether they'll do it or not, who knows.
>>>
>>>
>>
>> Yes, it has been ADDED TO.  But that did not change the existing 
>> behavior of the numeric constants.  All it did was add additional 
>> options not available in previous versions.
> 
> Sorry, when you said "actual values of constants" I understood you were 
> referring to the _numeric_ values. Of course, the behaviour remains 
> mostly the same.
> 
> 
> 

What I was referring to was compatibility.  The constants are fully 
compatible with previous and future releases of PHP.  They have to be, 
because there are places you can't use the E_ constants.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
8/10/2009 12:11:31 PM
amygdala wrote:
> Jerry Stuckle schreef:
>> amygdala wrote:
>>> Jerry Stuckle schreef:
>>>> Curtis Dyer wrote:
>>>>>
>>>>> Your assumption that "8191" is the same as E_ALL | E_STRICT is only 
>>>>> valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP 5.1.x, PHP 
>>>>> 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change again in PHP 6.
>>>>>
>>>>
>>>> Incorrect.  E_ALL is the same in most of those versions, and will be 
>>>> so in PHP 6.  E_STRICT was added - but there is no harm in enabling 
>>>> an extra bit which is not used in other versions.
>>>
>>> Wow, you are really talking out of your ass these days aren't you 
>>> Jerry? You stubborn idiot. Talk about giving of wrong advice (as I 
>>> saw you accuse somebody of doing in c.d.mysql)
>>>
>>> Let's go to:
>>> http://www.php.net/manual/en/errorfunc.constants.php
>>>
>>> Shall we?
>>>
>>> Let's see now... hmmm, for E_ALL it says in the Note column:
>>>
>>> "32767 in PHP 6, 30719 in PHP 5.3.x, 6143 in PHP 5.2.x, 2047 previously"
>>>
>>> My god, you really do like to spit out shit, don't you?
>>>
>>
>> Yep, and if you didn't have your head so far up your ass, you'd figure 
>> out that each of those constants still means the same thing in PHP 5.x.
>>
> 
> 
> Yes, but where not talking about keeping it working in only one version 
> of PHP now are we? We want to keep it scalable. Isn't that one of your 
> mantra's you always like to rub in peoples faces?
> 
> E_ALL has altered value three times for 5.x versions! What happens if 
> your on a shared host (on which many developers have websites) that 
> upgraded to a new minor or major PHP version?
> 
> How would you get notified of:
> E_RECOVERABLE_ERROR in 5.2
> E_DEPRECATED and E_USER_DEPRECATED in 6.x
> 
> Talk about once head up his ass. Moron.
> 

Full of bullshit, as always.

No, you won't get notified of those.  But that does NOT mean there is an 
incompatibility.  However, as usual, you are too stoopid to understand 
such a concept.  You'd rather argue from your ass as you always do.

So if this level of compatibility is so important to you - please tell 
me, how do I get notified of them in PHP 5.0?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
8/10/2009 12:14:08 PM
Jerry Stuckle schreef:
> amygdala wrote:
>> Jerry Stuckle schreef:
>>> amygdala wrote:
>>>> Jerry Stuckle schreef:
>>>>> Curtis Dyer wrote:
>>>>>>
>>>>>> Your assumption that "8191" is the same as E_ALL | E_STRICT is 
>>>>>> only valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP 5.1.x, 
>>>>>> PHP 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change again in 
>>>>>> PHP 6.
>>>>>>
>>>>>
>>>>> Incorrect.  E_ALL is the same in most of those versions, and will 
>>>>> be so in PHP 6.  E_STRICT was added - but there is no harm in 
>>>>> enabling an extra bit which is not used in other versions.
>>>>
>>>> Wow, you are really talking out of your ass these days aren't you 
>>>> Jerry? You stubborn idiot. Talk about giving of wrong advice (as I 
>>>> saw you accuse somebody of doing in c.d.mysql)
>>>>
>>>> Let's go to:
>>>> http://www.php.net/manual/en/errorfunc.constants.php
>>>>
>>>> Shall we?
>>>>
>>>> Let's see now... hmmm, for E_ALL it says in the Note column:
>>>>
>>>> "32767 in PHP 6, 30719 in PHP 5.3.x, 6143 in PHP 5.2.x, 2047 
>>>> previously"
>>>>
>>>> My god, you really do like to spit out shit, don't you?
>>>>
>>>
>>> Yep, and if you didn't have your head so far up your ass, you'd 
>>> figure out that each of those constants still means the same thing in 
>>> PHP 5.x.
>>>
>>
>>
>> Yes, but where not talking about keeping it working in only one 
>> version of PHP now are we? We want to keep it scalable. Isn't that one 
>> of your mantra's you always like to rub in peoples faces?
>>
>> E_ALL has altered value three times for 5.x versions! What happens if 
>> your on a shared host (on which many developers have websites) that 
>> upgraded to a new minor or major PHP version?
>>
>> How would you get notified of:
>> E_RECOVERABLE_ERROR in 5.2
>> E_DEPRECATED and E_USER_DEPRECATED in 6.x
>>
>> Talk about once head up his ass. Moron.
>>
> 
> Full of bullshit, as always.
> 
> No, you won't get notified of those.  But that does NOT mean there is an 
> incompatibility.  However, as usual, you are too stoopid to understand 
> such a concept.  You'd rather argue from your ass as you always do.
> 
> So if this level of compatibility is so important to you - please tell 
> me, how do I get notified of them in PHP 5.0?
> 

I understand your point perfectly well Jerry. But as usual you have such 
low opinion of your 'fellow' usenet users.

Sure the underlying bits of E_ALL will stay the same. And they will stay 
compatible. But it's not only about compatibility. It's about scalability.

So if you use E_ALL in stead of 6143 (for version 5.2.x, that is) you'ld 
still be notified of all errors (including new ones) if your host has 
upgraded to 5.3.x for instance.

And yes, I know you can't use the constants everywhere (such as in 
apache directives). But if you *can* use them, why avoid using them?

Jerry, even you understand this. But you'ld be to stubborn to admit it.

-- 
Amygdala
http://amygdala.110mb.com/
0
example (178)
8/10/2009 12:27:11 PM
amygdala wrote:
> Jerry Stuckle schreef:
>> amygdala wrote:
>>> Jerry Stuckle schreef:
>>>> amygdala wrote:
>>>>> Jerry Stuckle schreef:
>>>>>> Curtis Dyer wrote:
>>>>>>>
>>>>>>> Your assumption that "8191" is the same as E_ALL | E_STRICT is 
>>>>>>> only valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP 
>>>>>>> 5.1.x, PHP 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change 
>>>>>>> again in PHP 6.
>>>>>>>
>>>>>>
>>>>>> Incorrect.  E_ALL is the same in most of those versions, and will 
>>>>>> be so in PHP 6.  E_STRICT was added - but there is no harm in 
>>>>>> enabling an extra bit which is not used in other versions.
>>>>>
>>>>> Wow, you are really talking out of your ass these days aren't you 
>>>>> Jerry? You stubborn idiot. Talk about giving of wrong advice (as I 
>>>>> saw you accuse somebody of doing in c.d.mysql)
>>>>>
>>>>> Let's go to:
>>>>> http://www.php.net/manual/en/errorfunc.constants.php
>>>>>
>>>>> Shall we?
>>>>>
>>>>> Let's see now... hmmm, for E_ALL it says in the Note column:
>>>>>
>>>>> "32767 in PHP 6, 30719 in PHP 5.3.x, 6143 in PHP 5.2.x, 2047 
>>>>> previously"
>>>>>
>>>>> My god, you really do like to spit out shit, don't you?
>>>>>
>>>>
>>>> Yep, and if you didn't have your head so far up your ass, you'd 
>>>> figure out that each of those constants still means the same thing 
>>>> in PHP 5.x.
>>>>
>>>
>>>
>>> Yes, but where not talking about keeping it working in only one 
>>> version of PHP now are we? We want to keep it scalable. Isn't that 
>>> one of your mantra's you always like to rub in peoples faces?
>>>
>>> E_ALL has altered value three times for 5.x versions! What happens if 
>>> your on a shared host (on which many developers have websites) that 
>>> upgraded to a new minor or major PHP version?
>>>
>>> How would you get notified of:
>>> E_RECOVERABLE_ERROR in 5.2
>>> E_DEPRECATED and E_USER_DEPRECATED in 6.x
>>>
>>> Talk about once head up his ass. Moron.
>>>
>>
>> Full of bullshit, as always.
>>
>> No, you won't get notified of those.  But that does NOT mean there is 
>> an incompatibility.  However, as usual, you are too stoopid to 
>> understand such a concept.  You'd rather argue from your ass as you 
>> always do.
>>
>> So if this level of compatibility is so important to you - please tell 
>> me, how do I get notified of them in PHP 5.0?
>>
> 
> I understand your point perfectly well Jerry. But as usual you have such 
> low opinion of your 'fellow' usenet users.
>

No, I have a very high opinion of many usenet users.  I do have a very 
low opinion of you and a few others.

> Sure the underlying bits of E_ALL will stay the same. And they will stay 
> compatible. But it's not only about compatibility. It's about scalability.
> 
> So if you use E_ALL in stead of 6143 (for version 5.2.x, that is) you'ld 
> still be notified of all errors (including new ones) if your host has 
> upgraded to 5.3.x for instance.
> 
> And yes, I know you can't use the constants everywhere (such as in 
> apache directives). But if you *can* use them, why avoid using them?
> 
> Jerry, even you understand this. But you'ld be to stubborn to admit it.
> 

Oh, I understand it, all right.  And I even said earlier that you should 
use them, if for no other reason than more clarity.

But you should NOT use them just because they are available.  I don't 
know how many times I've seen such changes cause new messages to 
suddenly pop up where they weren't before (and not just in PHP).  Maybe 
they're important, maybe not.  But they can cause all kinds of other 
troubles by hiding real problems amongst all the false error messages.

Like anything else - use a feature because you need it, not because it's 
there.

But you fail to acknowledge that.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
8/10/2009 12:49:09 PM
amygdala wrote:
> Jerry Stuckle schreef:
>> Yep, and if you didn't have your head so far up your ass, you'd figure 
>> out that each of those constants still means the same thing in PHP 5.x.
>>
>> They added bits to E_ALL.  But they have never changed the values of 
>> the existing bits.  They still do exactly what they did in earlier 
>> versions of PHP, and will continue to do so in future versions.
>>
>> But it would take someone with a modicum of intelligence to figure 
>> that out - which you don't have.
>>
> 
> By the way, still waiting for your example code to proof the 
> encapsulation example I showed wrong.
> 
> Twat.
> 

As I told you, idiot.  I don't try to teach pigs to sing.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
0
jstucklex (14659)
8/10/2009 12:49:41 PM
Jerry Stuckle schreef:
> amygdala wrote:
>> Jerry Stuckle schreef:
>>> Yep, and if you didn't have your head so far up your ass, you'd 
>>> figure out that each of those constants still means the same thing in 
>>> PHP 5.x.
>>>
>>> They added bits to E_ALL.  But they have never changed the values of 
>>> the existing bits.  They still do exactly what they did in earlier 
>>> versions of PHP, and will continue to do so in future versions.
>>>
>>> But it would take someone with a modicum of intelligence to figure 
>>> that out - which you don't have.
>>>
>>
>> By the way, still waiting for your example code to proof the 
>> encapsulation example I showed wrong.
>>
>> Twat.
>>
> 
> As I told you, idiot.  I don't try to teach pigs to sing.
> 

Nice cop out Jerry.

-- 
Amygdala
http://amygdala.110mb.com/
0
example (178)
8/10/2009 12:56:41 PM
Jerry Stuckle schreef:
> amygdala wrote:
>> Jerry Stuckle schreef:
>>> amygdala wrote:
>>>> Jerry Stuckle schreef:
>>>>> amygdala wrote:
>>>>>> Jerry Stuckle schreef:
>>>>>>> Curtis Dyer wrote:
>>>>>>>>
>>>>>>>> Your assumption that "8191" is the same as E_ALL | E_STRICT is 
>>>>>>>> only valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP 
>>>>>>>> 5.1.x, PHP 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change 
>>>>>>>> again in PHP 6.
>>>>>>>>
>>>>>>>
>>>>>>> Incorrect.  E_ALL is the same in most of those versions, and will 
>>>>>>> be so in PHP 6.  E_STRICT was added - but there is no harm in 
>>>>>>> enabling an extra bit which is not used in other versions.
>>>>>>
>>>>>> Wow, you are really talking out of your ass these days aren't you 
>>>>>> Jerry? You stubborn idiot. Talk about giving of wrong advice (as I 
>>>>>> saw you accuse somebody of doing in c.d.mysql)
>>>>>>
>>>>>> Let's go to:
>>>>>> http://www.php.net/manual/en/errorfunc.constants.php
>>>>>>
>>>>>> Shall we?
>>>>>>
>>>>>> Let's see now... hmmm, for E_ALL it says in the Note column:
>>>>>>
>>>>>> "32767 in PHP 6, 30719 in PHP 5.3.x, 6143 in PHP 5.2.x, 2047 
>>>>>> previously"
>>>>>>
>>>>>> My god, you really do like to spit out shit, don't you?
>>>>>>
>>>>>
>>>>> Yep, and if you didn't have your head so far up your ass, you'd 
>>>>> figure out that each of those constants still means the same thing 
>>>>> in PHP 5.x.
>>>>>
>>>>
>>>>
>>>> Yes, but where not talking about keeping it working in only one 
>>>> version of PHP now are we? We want to keep it scalable. Isn't that 
>>>> one of your mantra's you always like to rub in peoples faces?
>>>>
>>>> E_ALL has altered value three times for 5.x versions! What happens 
>>>> if your on a shared host (on which many developers have websites) 
>>>> that upgraded to a new minor or major PHP version?
>>>>
>>>> How would you get notified of:
>>>> E_RECOVERABLE_ERROR in 5.2
>>>> E_DEPRECATED and E_USER_DEPRECATED in 6.x
>>>>
>>>> Talk about once head up his ass. Moron.
>>>>
>>>
>>> Full of bullshit, as always.
>>>
>>> No, you won't get notified of those.  But that does NOT mean there is 
>>> an incompatibility.  However, as usual, you are too stoopid to 
>>> understand such a concept.  You'd rather argue from your ass as you 
>>> always do.
>>>
>>> So if this level of compatibility is so important to you - please 
>>> tell me, how do I get notified of them in PHP 5.0?
>>>
>>
>> I understand your point perfectly well Jerry. But as usual you have 
>> such low opinion of your 'fellow' usenet users.
>>
> 
> No, I have a very high opinion of many usenet users.  I do have a very 
> low opinion of you and a few others.
> 
>> Sure the underlying bits of E_ALL will stay the same. And they will 
>> stay compatible. But it's not only about compatibility. It's about 
>> scalability.
>>
>> So if you use E_ALL in stead of 6143 (for version 5.2.x, that is) 
>> you'ld still be notified of all errors (including new ones) if your 
>> host has upgraded to 5.3.x for instance.
>>
>> And yes, I know you can't use the constants everywhere (such as in 
>> apache directives). But if you *can* use them, why avoid using them?
>>
>> Jerry, even you understand this. But you'ld be to stubborn to admit it.
>>
> 
> Oh, I understand it, all right.  And I even said earlier that you should 
> use them, if for no other reason than more clarity.

Fair enough. I read the message now.

> But you should NOT use them just because they are available.  I don't 
> know how many times I've seen such changes cause new messages to 
> suddenly pop up where they weren't before (and not just in PHP).

Error messages? On a production box you'ld log them. You wouldn't show 
them on screen to the user. Now, if you're talking about log files 
overflowing, or rather massive accessing of log files, you might have a 
point. But if it's a huge amount of errors, you're site is probably in 
trouble already.

> Maybe 
> they're important, maybe not.  But they can cause all kinds of other 
> troubles by hiding real problems amongst all the false error messages.

False error messages? How so? They would be *real* error messages that 
point you to the *real* problems due to an upgrade of PHP.

> 
> Like anything else - use a feature because you need it, not because it's 
> there.
> 
> But you fail to acknowledge that.
> 

Nah, you make a decent point here alright. I'm not as stubborn as you Jerry.

-- 
Amygdala
http://amygdala.110mb.com/
0
example (178)
8/10/2009 1:10:52 PM
On 10 Aug 2009, <mail@bananas-playground.net> wrote: 

> Curtis Dyer wrote:
>> On 09 Aug 2009, <mail@bananas-playground.net> wrote: 
>> 
>>> Curtis Dyer wrote:
>>>> On 07 Aug 2009, johannes ke�ler
>>>> <mail@bananas-playground.net> wrote: 
>>>>
>>>>> Vm wrote:

<snip>

>> Your assumption that "8191" is the same as E_ALL | E_STRICT is 
>> only valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP
>> 5.1.x, PHP 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change
>> again in PHP 6.
>> 
>> Another portable way to enable all levels of error reporting is
>> to pass `-1' to error_reporting().  This should also work with
>> Apache PHP config directives (where the E_* constants aren't
>> available). 
>> 
>>   ini_set('error_reporting', -1);
>> 
>> So, at best, your answer is unnecessarily unportable or, at
>> worst, just plain wrong.
>> 
>> <snip>
>> 
> 
> phew....,
> 
> he asked for a way to solve the migration issue.
> 
> He didn't ask for a "for everytime valid" solution to do this.
> 
> I provided only one of many solutions for this problem. And if
> he is up to do this migration, he will be able to use my advice
> and determine if he can use it or not.
> 
> It was only a suggestion, it is up to everybody to use it or
> not... 

Sorry, I owe you an apology.  I'm not sure why I thought your 
usage of "8191" would "break"; as Jerry points out elsethread, 
that would not be the case.  Even when more bits are added to 
E_ALL, your solution would still work.

Sorry again!

-- 
~Curtis Dyer
<? $x='<? $x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>
0
dyer85 (342)
8/10/2009 9:28:30 PM
On 10 Aug 2009, Jerry Stuckle <jstucklex@attglobal.net> wrote:

> Curtis Dyer wrote:
>> On 09 Aug 2009, <mail@bananas-playground.net> wrote: 
>>> Curtis Dyer wrote:
>>>> On 07 Aug 2009, johannes ke�ler
>>>> <mail@bananas-playground.net> wrote: 
>>>>> Vm wrote:

<snip>

>> Your assumption that "8191" is the same as E_ALL | E_STRICT is 
>> only valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP
>> 5.1.x, PHP 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change
>> again in PHP 6.
> 
> Incorrect.  E_ALL is the same in most of those versions, and
> will be so in PHP 6.  E_STRICT was added - but there is no harm
> in enabling an extra bit which is not used in other versions.

Quite right, acknowledged.  The only thing the OP should be aware 
of is that "8191" would not include new bits set in future 
versions, but still works just fine.

<snip>

>> So, at best, your answer is unnecessarily unportable or, at
>> worst, just plain wrong.
>> 
>> <snip>
>> 
> 
> Incorrect.

Acknowledged.

> In fact, there are places you CAN'T use the E_
> constants and must use the integer values.

Indeed, and I acknowledged this in my previous post.

-- 
~Curtis Dyer
<? $x='<? $x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>
0
dyer85 (342)
8/10/2009 9:39:25 PM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Curtis Dyer wrote:
> On 10 Aug 2009, <mail@bananas-playground.net> wrote: 
> 
>> Curtis Dyer wrote:
>>> On 09 Aug 2009, <mail@bananas-playground.net> wrote: 
>>>
>>>> Curtis Dyer wrote:
>>>>> On 07 Aug 2009, johannes ke�ler
>>>>> <mail@bananas-playground.net> wrote: 
>>>>>
>>>>>> Vm wrote:
> 
> <snip>
> 
>>> Your assumption that "8191" is the same as E_ALL | E_STRICT is 
>>> only valid in PHP 5.2.x.  Thus, it breaks in PHP 5.3.x, PHP
>>> 5.1.x, PHP 5.0.x, PHP 4.x, and lower.  Also, E_ALL will change
>>> again in PHP 6.
>>>
>>> Another portable way to enable all levels of error reporting is
>>> to pass `-1' to error_reporting().  This should also work with
>>> Apache PHP config directives (where the E_* constants aren't
>>> available). 
>>>
>>>   ini_set('error_reporting', -1);
>>>
>>> So, at best, your answer is unnecessarily unportable or, at
>>> worst, just plain wrong.
>>>
>>> <snip>
>>>
>> phew....,
>>
>> he asked for a way to solve the migration issue.
>>
>> He didn't ask for a "for everytime valid" solution to do this.
>>
>> I provided only one of many solutions for this problem. And if
>> he is up to do this migration, he will be able to use my advice
>> and determine if he can use it or not.
>>
>> It was only a suggestion, it is up to everybody to use it or
>> not... 
> 
> Sorry, I owe you an apology.  I'm not sure why I thought your 
> usage of "8191" would "break"; as Jerry points out elsethread, 
> that would not be the case.  Even when more bits are added to 
> E_ALL, your solution would still work.
> 
> Sorry again!
> 

accepted ;-)

regards,
johannes keßler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkqBDWwACgkQE++2Zdc7Etd0BgCfYP9hh9ekYy/vznmntXiUKyD2
qgcAnA0lA57U7pRaHBUHVNsRE0uNKEUR
=BLY+
-----END PGP SIGNATURE-----
0
mail1382 (206)
8/11/2009 6:19:25 AM
Thanks for that wonderful explain about E_ALL | E_STRICT..... but it
was not that i was looking for..
But it is good to learn unknown things thanks to one and all

where my problem is solved.. i just rewrite code in new version
PHP.... and yes it was old PHP code was written back in 1995....


~thanks
Vijay,

0
8/21/2009 10:34:33 AM
What an insufferable arse that Jerry is.
0
8/21/2009 4:25:51 PM
markskilbeck@googlemail.com wrote:
> What an insufferable arse that Jerry is.

What took you so long? ;-)
0
tnp (2409)
8/21/2009 5:15:49 PM
On Mon, 10 Aug 2009 08:49:09 -0400, Jerry Stuckle wrote:

> But you should NOT use them just because they are available.  I don't

Heh, this comment reminded me of something I read way back when I was 
learning perl: 
Just because there's more than one way to do it, doesn't mean that all 
ways are right.
0
8/28/2009 4:52:57 PM
Reply:

Similar Artilces:

PHP 4.X vs PHP 5.x
When does it really matter? I have read that PHP5 has a stronger object model, is that really helpful? walterbyrd wrote: > When does it really matter? I have read that PHP5 has a stronger object > model, is that really helpful? > It is if you're doing OO programming - which I much prefer. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ================== ...

Help Needed: Upgrade Fedora 4 / Apache 2 to PHP 5.2.x from 5.0.4
Help Needed: Upgrade Fedora 4 / Apache 2 to PHP 5.2.x from 5.0.4 I've been testing Joomla as a content manager for the County offices, and it looks pretty good. Unfortunately, I decided to upgrade it from the 1.0.13 version to 1.5 as we get ready to go live with the web site... and the update installation gives an error in XML processing, which seems (from what I've been able to dredge up in forum discussions) to stem from a known bug in PHP 5.0.4... I've seen this same error from a couple of other programs that want to upload XML data to PHP based server software, too, so I'...

imagerotate problem with PHP 4.3.9
Recap: Using imagerotate within PHP 4.3.9 - PHP 5.2.0 for both XP and Linux, all using GD2 If you rotate an image 180 degrees, all is fine If you rotate an image > 0 degrees and < 180 degrees, or > 180 degrees and < 360 degrees, while the image will rotate, its dimensions are somehow not refactored and as a result you get a rather annoying black bar in the newly-rotated image, along with part of your image being cropped off. I learned about a possible workaround with ImageMagick's convert command, but has anyone found a better solution (other than using XP's built-in im...

PHP 5.2.0 and Python 2.5
Hi Guys, I need some wisdom from you. Is it possible to have PHP pages posting to python scripts on the server side and returning values back to the calling PHP files? Like, if my enterval.php form's action=" think.py", would the two scripts be able to talk to each other? Thanks and Best Regards, "Shortash" Shortash wrote: > Hi Guys, > > I need some wisdom from you. Is it possible to have PHP pages posting > to python scripts on the server side and returning values back to the > calling PHP files? Like, if my enterval.php form's action=" t...

PHP 5 or PHP 4 compatible codes
Kinda OT. I haven't yet moved to PHP5. But, interested to know how many of you _really_ started using it or moved? Are you doing any compatible tweaks specifically for PHP 5 (forward compatible) or PHP 4 (backward compatible)? -- | Just another PHP saint | Email: rrjanbiah-at-Y!com R. Rajesh Jeba Anbiah wrote: > Kinda OT. I haven't yet moved to PHP5. But, interested to know how > many of you _really_ started using it or moved? Are you doing any > compatible tweaks specifically for PHP 5 (forward compatible) or PHP 4 > (backward compatible)? Basically, if you code for...

WinXP SP2,Apache 2.0.52, MySQL 5.0.0, PHP 5.01
I'm having a little trouble getting MySQL to load with Apache. Apache and PHP are working OK, but MySQL isn't loading. I know php.ini is loading because the following lines are in php.ini: extension_dir = "C:\Program Files\PHP" extension=php_mysql.dll and the error I get when Apache starts up is: PHP Startup: Unable to load dynamic load library 'C:\Program Files\PHP\php_mysql.dll' - The specified procedure could not be found. php_mysql.dll is definitely there. This same setup ( MySQL 5.0.0, PHP 5.01) works unchanged with the Abyss Web Server, so I know MySQL a...

[ANN] Kwartz-php 0.2.0
Hi all, I'm pleased to announce the release of Kwartz-php. http://www.kuwata-lab.com/kwartz-php Kwartz-php is a template system which is available with multi language (PHP, Ruby and JSP). And, it is the first template system which realized the concept of 'Separation of Presentation Logic and Presentaion data' (SoPL/PD). Features: * Separates presentation logic from presentation data. * Runs very fast * Multiple programing languages * Doesn't break HTML design at all * Can handle any text file * Auto-Sanitizing and Partial-Sanitizing Support Example: * Pres...

Is Php built in function ' imagecreate()' compatible in Php version 5.2.2 ?
Hi All, I have the php version 5.2.2 . When I am using " $im = imagecreate(......); " I am getting the following message "Fatal error: Call to undefined function imagecreate() in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\server.php on line 32" I want to know whether "imagecreate()" is compatible in PHP version 5.2.2.? saikiran.iitkgp@gmail.com wrote: > Hi All, > > I have the php version 5.2.2 . When I am using > > > " $im = imagecreate(......); " I am getting the following message > > > &q...

Apache/2.0.54 (Win32) PHP/5.0.5 multiple output
A newbie question: With the config mentioned in the topic, all on localhost, Win xpsp2, i created a caledar-table. The output should be a daily calendar for half a year with about 15 cols. So everything works fine on the console, output is as it should be. But when calling the script via apache, the table is either truncated or it comes twice or three times or i get an 404-Error with the table appended. Any hints? Many thanks in advance Thomas Hermann On Tue, 13 Sep 2005 21:15:14 +0200, Thomas Hermann <thomashermann@gmx.net> wrote: >A newbie question: > >With the config...

PHP 5.x and Wordpress 1.5.2 and Apache 1.3.x
Folks, I'm using WP 1.5.2 on Apache 1.3.33 and tried it with both PHP 5.0.4 and php 5.1.0.rc.1 -- and getting seg faults (can't even complete setup) I complete the first step in Setup, and get the seg fault going to the second step. I would welcome any work arounds/solutions people might have. I checked our the wordpress site, http://www.wordpress.org/, but seeing mixed messages. Some folks say the seg fault is there, others say it works with Apache 2.0? Many thanks. -- John ________________________________________________________________...

testing PHP 5 with Apache 2 and php info file
When I go to look for php info file in the browser all i get is the actually words. <?php phpinfo(); ?> any obvious problems? thanks ...

testing PHP 5 with Apache 2 and php info file
When I go to look for php info file in the browser all i get is the actually words. <?php phpinfo(); ?> any obvious problems? thanks ...

PHP 5.1.2 and using PHP w Apache2 and MySQL
Hello all, First of all I first dld and installed (unzipped) PHP 5.1.1 before 5.1.2 was released, so do I just unzip 5.1.2 over the existing 5.1.1 and use the same php.ini file, or is there more to it than that? When I run phpinfo it still displays the ver as 5.1.1, is this ok? Also, I have installed Apache 2.0.55 and PHP 5.1.2 (see above 5.1.2 question) on my personal windows me computer, and I would like to install MySQL as well. To the best of my knowledge both of the above SEEM to be working and setup correctly. My goal in doing this is so that I can learn to use Apache, PHP ...

php-mcrypt module for php-4.2.2 ?
Hi I am looking for the above as my php version (Redhat) is that. Call me lazy, but I do not wish to compile php unless it becomes absolutely necessary, as it has been working fine so far. I have searched google for it, but to no avail so far. Does anyone know a source for it ? Upgrading to 4.2.3 is an option, but it will require upgrading large chunks of my installation that I do not have a problem with. Thanks, MS ...

Parsing a php include (which also contains php code)
Hello, I am using the <?php include() ?> statement on my website for organizational purposes. However, one of my includes contains some PHP code. Is there any way for the server to actually parse the include? I've tried this before, and it did not parse the include. Rather, it included the file as just plain ASCII. ======================= /*EXAMPLE 1*/ /*index.php*/ .... <?php include('global/includes/footer.inc') ?> .... /*footer.inc*/ .... <p>&copy 1993-<?php echo date("Y") ?> Kingswood School. All rights reserved.</p> .... /*EXA...

WIN2K, Apache 2.0.5 and PHP 5
hi Everyone, I hope (actually I'm sure) someone can help me to solve my problem. I installed Apache V 2.0.53 on Windows 2000 pro SP4 (including latest Windows patches). Installed PHP version is V 5.0.4 Installed folder locations: Apache: E:\Program Files\Apache Group\Apache2 PHP 5: E:\usr\PHP5 I added the above path to the PHP folder to the PATH environment variable. The http.conf of Apache containes the following entries: <<< start snippet: >>> LoadModule php5_module "E:/usr/php/php5apache2.dll" AddType application/x-httpd-php .php # configure the path...

Installing php 5.x on apache 2.x
Can someone please help me install php on apache? I downloaded the latest stable msi installer. Left it with default options unless i specifically needed to change them (e.g. server). Then I went to configue my httpd.conf file, and I realised I don't know where to put the lines of code. Can someone please say where I need to insert: 1) ScriptAlias /php/ "c:/php/" 2) AddType application/x-httpd-php .php3) Action application/x-httpd-php "/php/php-cgi.exe"Thanks. On Sat, 19 Nov 2005 23:16:37 -0000, "Samuel" <samuel@fssc.freeserve.co.uk> wrote: >Can someone please help me install php on apache? > >I downloaded the latest stable msi installer. Left it with default options >unless i specifically needed to change them (e.g. server). Then I went to >configue my httpd.conf file, and I realised I don't know where to put the >lines of code. > >Can someone please say where I need to insert: > >1) ScriptAlias /php/ "c:/php/" > >2) AddType application/x-httpd-php .php3) Action application/x-httpd-php >"/php/php-cgi.exe"Thanks. "php3" indicates you may have got this information from a very old source, and are you sure you want to be installing as CGI when installing as an Apache module is available? Running as a module is typically faster, and a more "normal" configuration - there's situations where CGI may be more appropriate but they're...

PHP 5.0.2 and tomcat 4.0
I am using PHP 5.0.2 and tomcat 4. whenever load the the PHP pages through IE, it gives the following error. java.lang.UnsatisfiedLinkError: send at net.php.servlet.send(Native Method) at net.php.servlet.service(servlet.java:190) at net.php.servlet.service(servlet.java:214) at javax.servlet.http.HttpServlet.service(HttpServlet.java:1264) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(Sta...

php 4.4.1 constructor Vs. Php 5.0 constructor
I have a class with a constructor function that looks like so on my php 5.0 box: public function __construct(....) does this syntax change when I go back to php 4.4.1? I've never used 4.4.1 before, been solely 5.0 until now. It seems the 4.4.1 box is giving me an error on that call. I've been looking on google for a while for a simple answer, but must not be searching for the right thing. Thanks in advance. Greg Scharlemann wrote: > I have a class with a constructor function that looks like so on my php > 5.0 box: > > public function __construct(....) >...

PHP Training Institute In Delhi, Live Projects on PHP. Short Term PHP Courses, PHP Scripts, PHP Training with Live Projects.
Vserve Global offers short term PHP: Hypertext Preprocessor Training Course, which is a widely used, general-purpose scripting language that was originally designed for web development, to produce dynamic web pages. It can be embedded into HTML and generally runs on a web server, which needs to be configured to process PHP code and create web page content from it. It can be deployed on most web servers and on almost every operating system and platform free of charge.PHP is installed on over 20 million websites and 1 million web servers. TOPICS:- >> Core PHP Language >> HTML, Cascad...

PHP within PHP...
I took over the support of a website that is set up something like this inside one of the pages: include_once("header.php"); <?php //to get the content of the page they do this: $content = mysql_query("select content etc...); echo $content; ?> include_once("footer.php"); I am having problems evaluating any php that is used in the mysql content. Is there a way to get the mysql withing the mysql to run? Thank you for your time, Mandragon On Sep 17, 12:56 pm, Mandrago...@gmail.com wrote: > I took over the support of a website that is set up something like > this inside one of the pages: > > include_once("header.php"); > > <?php > //to get the content of the page they do this: > $content = mysql_query("select content etc...); > > echo $content; > ?> > > include_once("footer.php"); > > I am having problems evaluating any php that is used in the mysql > content. Is there a way to get the mysql withing the mysql to run? > > Thank you for your time, > > Mandragon Sorry, The question should read: "Is there a way to get the php withing the echo $htmlcontent to run?" Of course you are, $content is a resource. The MySQL Query resource. try this: $content = mysql_query('bla bla bla'); while ($row = mysql_fetch_assoc($content)) { $result[] = $row; } $content = $result; Now you can use $content ;). In answer to your edit... eval($co...

php to php obj
Hi All, Is there any tool to convert the .php files into its object files in deploying the files to other's server like java classes are deployed? Thanks in advance --AR John7481 <arjohn7481@hotmail.com> wrote or quoted: > Is there any tool to convert the .php files into its object files in > deploying the files to other's server like java classes are deployed? To what end? Do you want a PHP obfuscator? They tend not to be needed - since the code remains on the server. Do you want a PHP squeezer? Again - since PHP remains on the server that is of reduced importance. PHP obfuscators and squeezers are out there - but what exactly are you looking for? -- __________ |im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply. With total disregard for any kind of safety measures Tim Tyler <tim@tt1lock.org> leapt forth and uttered: > John7481 <arjohn7481@hotmail.com> wrote or quoted: > >> Is there any tool to convert the .php files into its object >> files in deploying the files to other's server like java >> classes are deployed? > > To what end? > > Do you want a PHP obfuscator? They tend not to be needed - > since the code remains on the server. > > Do you want a PHP squeezer? Again - since PHP remains on the > server that is of reduced importance. > > PHP obfuscators and squeezers are out there - but what exactly > are you looking for? I think he'...

php outside php (?)
Sounds weird, i know. What i want/wonder is the following: PHP can do the next: <?php if($foo == 'bar') { ?> Ow yeah, foo is bar! <?php }; ?> But how can i do the following: <?php $foo= ?> this is what foo looks like. <?php }; ?> This way i could edit the content of $foo in DW's design-view. I hope it's clear enough for you all to understand... Greetings frizzle. frizzle wrote: > But how can i do the following: > > <?php > > $foo= > > ?> > this is what foo looks like. > <?php > > }; > > ?> > > This way i could edit the content of $foo in DW's design-view. > I hope it's clear enough for you all to understand... <?php ob_start(); ?> this is what foo looks like. <?php $foo=ob_get_clean(); ?> -- Justin Koivisto - justin@koivi.com http://koivi.com Wow, little late on the reply, but i still wanted to thank you for your help. This is exactly what i meant, and it works great! :D Thanks again. ...

PHP with Indian PHP Developers #2
Dear all, If you want to make a PHP web application, or need to Hire PHP Developer contact a leading PHP Web Development Compnay http://www.virtueinfo.com/ php-developers/php-web-development.htm ...

Web resources about - Migrate PHP 2.0 code to PHP 5.x - comp.lang.php

1-800-Flowers Becomes the First Client to Migrate to Facebook’s Revamped Atlas Ad Platform
... platform , which Facebook announced at Advertising Week 2014 in New York at the end of September, has its first client, as 1-800-Flowers migrated ...

Facebook Migrates 400,000 Users to Fans of Apple’s Page
While Facebook has been turning up the marketing on businesses and brand owners to create Facebook Pages, one feature of Pages that is less well ...

Why, when and how to migrate to Windows 8 - Windows 8 migration, Windows 8 deployment, Windows 8, Windows ...
Windows 8 machines are coming out sometime this fall, but that doesn't mean businesses should shift to panic mode to upgrade their corporate ...

'You don't migrate to this country unless you want to join our team': Tony Abbott renews push on national ...
Prime Minister Tony Abbott has elaborated on his "Team Australia" remarks, telling a radio interview that "you don't migrate to this country ...

Tony Abbott's woman problem migrates to his ministry
Tony Abbott is having women trouble. It's nothing he said, mind.

Doctors and Nurses From Poor Countries Migrate To Rich Ones
Australia has saved almost $640 million by poaching doctors from some of the poorest countries in Africa.

ISIS recruitment video Join the Ranks urges Indonesian Muslims to migrate to the Islamic State
A video released by the terrorist group shows Indonesian men urging Muslims to wage join the jihad.

Polar bears migrate to Canadian Arctic for longer lasting ice: study
Some polar bear clusters have slowly moved to islands north of Canada's mainland that are retaining the Arctic ice for longer, according to a ...

Apple now allows developer MobileMe users to migrate their accounts to iCloud
As promised, Apple has opened up a new portal at me.com/move for developers that the MobileMe service to migrate their entire account over to ...

Verizon Explains the Real Reason Geese Migrate
... In the new spot for Verizon we learn that geese hate buffering (and they have cell phones). To escape the dreaded "dead zone," the flock migrates ...

Resources last updated: 3/23/2016 4:36:57 PM