osCommerce and PHP 5?

[balasko]

I had working install of osCommerce 2.2ms2 before server migration to PHP 5 (I suspect), now I get this error instead the admin page (log-in goes through):

:blink:

Warning: include(includes/languages/slovak/) [function.include]: failed to open stream: No such file or directory in /home/html/balasko.sk/public_html/_sub/katalog/admin/includes/application_top.php on line 133

 

Warning: include() [function.include]: Failed opening 'includes/languages/slovak/' for inclusion (include_path='./:/usr/local/lib/php/pear/') in /home/html/balasko.sk/public_html/_sub/katalog/admin/includes/application_top.php on line 133

 

Fatal error: Cannot re-assign $this in /home/html/balasko.sk/public_html/_sub/katalog/admin/includes/classes/upload.php on line 31

:blink:

also all goods are lost...

 

Where to start look for answers and any help? :blush:

cheers

[Velveeta]

I had working install of osCommerce 2.2ms2 before server migration to PHP 5 (I suspect), now I get this error instead the admin page (log-in goes through):

:blink:

Warning: include(includes/languages/slovak/) [function.include]: failed to open stream: No such file or directory in /home/html/balasko.sk/public_html/_sub/katalog/admin/includes/application_top.php on line 133

 

Warning: include() [function.include]: Failed opening 'includes/languages/slovak/' for inclusion (include_path='./:/usr/local/lib/php/pear/') in /home/html/balasko.sk/public_html/_sub/katalog/admin/includes/application_top.php on line 133

 

Fatal error: Cannot re-assign $this in /home/html/balasko.sk/public_html/_sub/katalog/admin/includes/classes/upload.php on line 31

:blink:

also all goods are lost...

 

Where to start look for answers and any help? :blush:

cheers

Well, I can tell you the error on line 31 of upload.php is an old error that's been posted many times... The answer to that one is simple, find line 31 of admin/includes/classes/upload.php, and comment it out... It should look like this:

 

$this = null;

 

As for your slovak language file errors, the problem I think I see in there is that there's no filename specified... It's saying "Failed opening 'includes/languages/slovak/' for inclusion", but you can't use the include function on a directory, so that should be saying something like this if it were a legitimate error "Failed opening 'includes/languages/slovak.php' for inclusion" or "Failed opening 'includes/languages/slovak/categories.php' for inclusion" or something like that... Check your file to see what FILENAME_ value is being referenced, such as include(DIR_WS_LANGUAGES . $language . '/' . FILENAME_CATEGORIES); and then go check your admin/includes/filenames.php file to make sure it's declared properly... That's about the only thing I can think of... As for all goods being lost, I am totally clueless as to why that would be the case... The MySQL database is totally separate from PHP on the system, and any changes to PHP should have had no impact on the database, even if it did end up breaking the store... Double-check the credentials supplied in your configure.php files, and make sure the database username/password are still correct?

 

Richard.

[Velveeta]

Also, I just remembered something... If the upgrade to PHP5 turned register_globals off, which is how it is by default in a PHP5 install I believe, then it's possible that your admin console just isn't reading the cPath variable from the url string and displaying the right category of products... In this case, you might always just see the top-level category entries, no matter what you clicked on in the catalog section, so it might look like all of your products are gone, but it's just that your code doesn't know the $cPath variable exists anymore, because it needs to be referenced as $_GET['cPath'] without register_globals turned on... You can find out if your register_globals value is on or off by going to your admin console's Tools -> Server Info, and checking out your php_info display... Just search the page for register_globals...

 

Richard.

[balasko]

Also, I just remembered something... If the upgrade to PHP5 turned register_globals off, which is how it is by default in a PHP5 install I believe, then it's possible that your admin console just isn't reading the cPath variable from the url string and displaying the right category of products... :thumbsup: In this case, you might always just see the top-level category entries, no matter what you clicked on in the catalog section, so it might look like all of your products are gone, but it's just that your code doesn't know the $cPath variable exists anymore, because it needs to be referenced as $_GET['cPath'] without register_globals turned on... :thumbsup: You can find out if your register_globals value is on or off by going to your admin console's Tools -> Server Info, and checking out your php_info display... Just search the page for register_globals...

 

Richard.

 

... exactly what it does/looks like, many Thanx Richard...

[balasko]

Well, I can tell you the error on line 31 of upload.php is an old error that's been posted many times... The answer to that one is simple, find line 31 of admin/includes/classes/upload.php, and comment it out... It should look like this:

 

$this = null;

 

fixed error on line 31 --> as you said. I can access the admin console again. Thank you.

But I don't understand what can/should I do with those register_globals off... :blush:

If it's off (cannot verify, unable to find/execute that "php_info"),

does it mean all code has to be checked and inserted "$_GET['cPath']" instead 'cPath' ?

or should I as admin to turn globals on? (is it any security risk when "on"?)

[Velveeta]

fixed error on line 31 --> as you said. I can access the admin console again. Thank you.

But I don't understand what can/should I do with those register_globals off... :blush:

If it's off (cannot verify, unable to find/execute that "php_info"),

does it mean all code has to be checked and inserted "$_GET['cPath']" instead 'cPath' ?

or should I as admin to turn globals on? (is it any security risk when "on"?)

If you re-read the post above, it'll tell you how to get to that phpinfo page, it's what's called for display when you go to Tools -> Server Info in the admin console... As for fixing it if it is off, there are a few contributions out there that have various fixes for these circumstances... You can fix it with your own php.ini file in your root directory I believe, or if this is your own dedicated server, you could fix it in the main php.ini file... It does carry a security risk, which is why in PHP5 it came disabled by default...

 

Richard.

[balasko]

If you re-read the post above, it'll tell you how to get to that phpinfo page, it's what's called for display when you go to Tools -> Server Info in the admin console... As for fixing it if it is off, there are a few contributions out there that have various fixes for these circumstances... You can fix it with your own php.ini file in your root directory I believe, or if this is your own dedicated server, you could fix it in the main php.ini file... It does carry a security risk, which is why in PHP5 it came disabled by default...

 

Richard.

 

well, I have tried, but Tools in admin console shows NO server info or anything similar to it..

Anyway.. people at host server forum told me that register_globals are "on".

 

From topic on that forum it seems that code has to be updated/fixed in this manner:

HTTP_GET_VARS --> _GET

HTTP_POST_VARS --> _POST

etc...

$HTTP_*_VARS --> $_*

 

many shops have been down and many are up again, yet I have no answer if the above helps..

Still the console isn't working properly, I'll try the above.

Thank You Richard

[Velveeta]

well, I have tried, but Tools in admin console shows NO server info or anything similar to it..

Anyway.. people at host server forum told me that register_globals are "on".

 

From topic on that forum it seems that code has to be updated/fixed in this manner:

HTTP_GET_VARS --> _GET

HTTP_POST_VARS --> _POST

etc...

$HTTP_*_VARS --> $_*

 

many shops have been down and many are up again, yet I have no answer if the above helps..

Still the console isn't working properly, I'll try the above.

Thank You Richard

You can try the perl command-line utility to search and replace all files in a directory at the same time and make these changes for you... I believe there's a way to expand upon this to make it do all directories recursively as well, but I don't know what it is, as I'm not a perl guy :D I just remembered using a line similar to the following years ago when I was still doing MUD development, and this was the best I could dig up right now, which does 1 directory at a time... Still much faster than 1 file at a time :D

 

perl -pi -e 's/lookFor/replaceWith/g' *.fileExtension

 

So for example:

 

perl -pi -e 's/HTTP_GET_VARS/_GET/g' *.php

perl -pi -e 's/HTTP_POST_VARS/_POST/g' *.php

 

etc... This is assuming you have shell access via ssh... However, you may be able to run it from a php script if you don't, by using the exec() function...

 

Richard.