Upgrade to PHP 5.1 makes trashes to the PHP Functions [EXPERT&isset]

Hi All !

Upgrading from PHP 4 something to PHP 5.1 leads to a master piece of
problem.

Our website was working perfectly with coding under PHP 4 or before :
"Our manager did a stupid attempt to upgrade the PHP code to PHP
5.1" ... as a result, many of our pages are not working anymore.
.... if I have a old F150 and replace it with a new F150 : that's still
the same gas so far !!!

Functions that seem not to work anymore are ISSET functions, and may
be more functions ...

Did you have in your previous experiences the problem to upgrade PHP ?

if(isset($_POST['process']))
if(!empty($loginname))

and may be more functions are not working anymore.

Thank you for any help;

Cougloff

In news:91cd96a0-8923-4a1f-8757-eb2ca80dd7ec@t41g2000yqt.googlegroups.com,
Pseudonyme <normancougloff@gmail.com> typed:

> if(isset($_POST['process']))
> if(!empty($loginname))
>
> and may be more functions are not working anymore.

What errors do you receive when display_errors is enabled in the php.ini
file? And why not upgrade to a current version?

Thank you greg for your answer.

I have no error displaid. The functions simply do not work.

Example : Post a form does not work.
Example2 : A display of a huge query that reads throughout many
tables, display nothing.

These errors are the worst, because we have no message, and I have to
try handling the complicated code in hidden process.

Example of a Post : http://tinyurl.com/y9bv3wc

Just the email address as to be filled like bob@bob.com the rest can
be ANYTHING

Thanks +

Pseudonyme wrote:

> Upgrading from PHP 4 something to PHP 5.1 leads to a master piece of
> problem.
>
> Our website was working perfectly with coding under PHP 4 or before :
> "Our manager did a stupid attempt to upgrade the PHP code to PHP
> 5.1" ... as a result, many of our pages are not working anymore.
> ... if I have a old F150 and replace it with a new F150 : that's still
> the same gas so far !!!
>
> Functions that seem not to work anymore are ISSET functions, and may
> be more functions ...
>
> Did you have in your previous experiences the problem to upgrade PHP ?
>
> if(isset($_POST['process']))
> if(!empty($loginname))

When we moved our control panel from php4 to php5 (this happen due server
crash and we didn't want to install so outdated server again), the major
problem was object passed by reference. The OOP part oh PHP changed the most,
IMHO to the better.

All isset() and empty() usage continued to work as expected

I do suggest you take a look at
http://www.php.net/manual/en/migrati...compatible.php

Keep in mind that php4 default "register_globals = On" is now
"register_globals = Off", which means that posted/get values will not
automatically be stored in variables, but only accessed from the $_POST/$_GET
array.

Without exact error messages, it's not possible to give any further assistance.



--

//Aho

Pseudonyme wrote:
> Thank you greg for your answer.
>
> I have no error displaid. The functions simply do not work.
>
> Example : Post a form does not work.

As globals are off, you need to do

$email = $_POST['email'];



> Example2 : A display of a huge query that reads throughout many
> tables, display nothing.

I haven't seen anything that would make mysql to fail, I suggest you test with
echoing the SQL query and run it manually to see if it do really find anything.

Use mysql_errno() and mysql_error() to see what kind of error you get, I'm
sure that the problem is that you expect values set which where posted and as
those aren't, your query has many where statements looking for a empty string
or even worse comparing a column with nothing (this generates a sql error).



--

//Aho

..oO(Pseudonyme)

>Thank you greg for your answer.
>
>I have no error displaid. The functions simply do not work.

They _do_ work. Check your error reporting in the php.ini, as already
suggested:

error_reporting = E_ALL|E_STRICT
display_errors = On

Do that on a development machine, of course, not on the production
server. You do have a dev machine, don't you?

>Example : Post a form does not work.

It does work. Most likely your code is relying on a feature from 10
years ago or so called register_globals. There really was enough time to
fix such old code! Have a look at the manual about this old directive
and how to fix it. In current PHP it's just disabled by default (since
years, BTW), but in the coming PHP 6 it will be completely removed, so
you _must_ fix your code!

Simply spoken you access form values by using a superglobal array like
$_GET or $_POST, dependent on which method was used in the form
submission. Same for cookies ($_COOKIE) and session data ($_SESSION). So
if you have some form field named 'foo', you don't access it by using
the $foo variable anymore, but $_POST['foo'] for example.

>Example2 : A display of a huge query that reads throughout many
>tables, display nothing.
>
>These errors are the worst, because we have no message, and I have to
>try handling the complicated code in hidden process.

You just have a misconfigured error reporting. PHP doesn't silently stop
working (except maybe for a real crash, but even then you should find
something in the server log).

Micha

Thank you J.O.
I will :
- review the variable in PHP.INI (register_globals)
- "The OOP part oh PHP changed the most, IMHO to the better". I will
take my queen victoria harrap's dictionary to try getting that one )
Probably Google all that.
- review that one : http://www.php.net/manual/en/migrati...compatible.php
- MySQL should be fine. It is.
I don't believe so much in Debug mode like in C++ or UML never helped
that much ... but PHP Debug mode ? Something I know nothing about.

imagecreatetruecolor
- That Library should be recompiled with PHP say the tutorials, while
my pack for the hosting cpy is a friendly tool with Plask + PHP +
MySQL all in one ... I don't have the source code to recompile the
package and to add the GD module to build image on the fly. Searching
15 minutes ... I could not get a simple way to add this library.

I now have input from your experience, thank you... will work on all
this.

Norman Cougloff
)

Thank Micha :

I Will :
error_reporting = E_ALL|E_STRICT
display_errors = On

PHP Boring. What ? :
register_globals was friendly. It is much more pure and clean to
initiate yourself the variables, I agree ... but PHP is such a little
engine, it is not powerful at all. UNIX is fine and pure, but not
PHP. So, keeping register_globals would have been cool.

the COOKIE is very important to me to eat
PHP 6 is coming ... OK.

No variable at all ?
You are mentioning the PHP will not offer anymore server variables.
That's a Big change !

session_start() .. That one ? Dead ? 100% Dead ?
$_SESSION['language']... That one ?

No $_something anymore ?

Thank you for your answer that will allow to prepare developers.

Norman by Norman Cougloff

..oO(Pseudonyme)

>Thank Micha :
>
>I Will :
>error_reporting = E_ALL|E_STRICT
>display_errors = On
>
>PHP Boring. What ? :
>register_globals was friendly.

It was dirty and dangerous. It was a risk for your application security
and data integrity. In short: It was a design error in PHP. Another such
stupid thing are the magic quotes (also removed in PHP 6).

>No variable at all ?
>You are mentioning the PHP will not offer anymore server variables.
>That's a Big change !

Who said that? Of course it will still all be there, just not in the
"normal" namespace where variables of the same name coming in from
different sources would overwrite each other.

>session_start() .. That one ? Dead ? 100% Dead ?

Of course not.

>$_SESSION['language']... That one ?

Still there and the correct way to access session data. But before it
was also possible to do that with $language ... and a whole bunch of
possible problems and conflicts that came along with it.

>No $_something anymore ?

Either I have written something completely wrong or you've just
misinterpreted some it.

Micha

On Mar 9, 2:13*pm, Michael Fesser <neti...@gmx.de> wrote:
> .oO(Pseudonyme)
>
> >Thank Micha :
>
> >I Will :
> >error_reporting = E_ALL|E_STRICT
> >display_errors = On
>
> >PHP Boring. What ? :
> >register_globals was friendly.
>
> It was dirty and dangerous. It was a risk for your application security
> and data integrity. In short: It was a design error in PHP. Another such
> stupid thing are the magic quotes (also removed in PHP 6).
>
> >No variable at all ?
> >You are mentioning the PHP will not offer anymore server variables.
> >That's a Big change !
>
> Who said that? Of course it will still all be there, just not in the
> "normal" namespace where variables of the same name coming in from
> different sources would overwrite each other.
>
> >session_start() .. That one ? Dead ? 100% Dead ?
>
> Of course not.
>
> >$_SESSION['language']... That one ?
>
> Still there and the correct way to access session data. But before it
> was also possible to do that with $language ... and a whole bunch of
> possible problems and conflicts that came along with it.
>
> >No $_something anymore ?
>
> Either I have written something completely wrong or you've just
> misinterpreted some it.
>
> Micha

Also when dealing with old php stuff that needs to die keep an eye on
your use of $HTTP_GET_VARS / $HTTP_POST_VARS and the
register_long_arrays setting.

keep an eye on your use of $HTTP_GET_VARS / $HTTP_POST_VARS and the
register_long_arrays settings

..... my eye is right down there ...

But register_long_arrays ... I must know more about UNIX. But the
registers within MSFT are useful (regedit)... UNIX ?

Bob

Pseudonyme wrote:
> keep an eye on your use of $HTTP_GET_VARS / $HTTP_POST_VARS and the
> register_long_arrays settings
>
> .... my eye is right down there ...
>
> But register_long_arrays ... I must know more about UNIX. But the
> registers within MSFT are useful (regedit)... UNIX ?
>
> Bob

No, they aren't. They are archaic remnants in both Unix and Microsoft.
Rather, you should be using the $_GET, $_POST, etc. superglobal arrays.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Pseudonyme wrote:
> Thank you J.O.
> I will :
> - review the variable in PHP.INI (register_globals)

Don't enable it, you will get a more hackable site if it's on.


> - "The OOP part oh PHP changed the most, IMHO to the better". I will
> take my queen victoria harrap's dictionary to try getting that one )
> Probably Google all that.

http://fr.wikipedia.org/wiki/Program...t%C3%A9e_objet


> - review that one : http://www.php.net/manual/en/migrati...compatible.php
> - MySQL should be fine. It is.
> I don't believe so much in Debug mode like in C++ or UML never helped
> that much ... but PHP Debug mode ? Something I know nothing about.

See what Michael Fesser wrote about error_reporting and display_errors.



> imagecreatetruecolor
> - That Library should be recompiled with PHP say the tutorials, while
> my pack for the hosting cpy is a friendly tool with Plask + PHP +
> MySQL all in one ... I don't have the source code to recompile the
> package and to add the GD module to build image on the fly. Searching
> 15 minutes ... I could not get a simple way to add this library.

If you have made a php upgrade, then the gd part should have been updated too.
I do suggest you use imagick [pecl.php.net/imagick] which is far better and
faster than gd, this one do not usually come when you install php, but you
either have a extra package in the repo, or in worst case you need to install
it with pecl.



--

//Aho

Am 09.03.2010 19:16, schrieb Pseudonyme:
> Did you have in your previous experiences the problem to upgrade PHP ?
>
> if(isset($_POST['process']))
> if(!empty($loginname))
>
Try:
print_r($_POST); /* What is in the array? */
exit(); /* Stop the PHP execution */

And see the result.

PHP still Boring : If I was changing my F150 each year in the last 50
years, I would not have passed 50 times my driving license.

An editor + consulting firm requires work load when upgrading software
versions to sell consulting hours ... but PHP ?

With that little story said : "Using imagick [pecl.php.net/imagick] to
build image on the fly. I will."

Thank you Sirs.