Function ereg_replace() is deprecated

[steve_s]

Can anyone help me fix this one in headertags.php?

 

$pageName = ucwords(ereg_replace("[^A-Za-z0-9]", " ", $pageName));

 

Thanks in advance!

 

Hi

change it to

$pageName = ucwords(preg_replace("|[^A-Za-z0-9]|", " ", $pageName));

 

Steve

[♥FWR Media]

Hi

change it to

$pageName = ucwords(preg_replace("|[^A-Za-z0-9]|", " ", $pageName));

 

Steve

 

Or even ( same just using the i modifier for case insensitivity )

 

$pageName = ucwords(preg_replace("/[^a-z0-9]/i", " ", $pageName));

[MrPhil]

There are a lot of things that are going to break in PHP 6.0.0 (support is removed), and as of PHP 5.3 we are being warned about them (deprecated functions and other things): http://us.php.net/manual/en/migration53.deprecated.php . Note that register global variables and long array names (e.g., $HTTP_POST_VARS) will be flat out unavailable (but are no longer needed in recent osC 2.2 RC releases). mysql_list_tables() (used in install) is also deprecated, but not in the list (so watch out for additions to this list). Anyone developing osC, developing add-ons for osC, or customizing osC code should be aware of this list. Merely turning off the warnings is not a good long-term solution! Given the level of support for osC 2.2, I'm not sure there are any efforts to make it PHP 6 compatible (you'll have to fix some things, such as ereg, on your own -- how about an add-on to bring all known PHP 6 exposures up to date?). I would expect osC 3.0 to be PHP 6-ready.

[FIMBLE]

http://github.com/osCommerce/oscommerce2 this has all of the files updated

[♥FWR Media]

There are a lot of things that are going to break in PHP 6.0.0 (support is removed), and as of PHP 5.3 we are being warned about them (deprecated functions and other things): http://us.php.net/manual/en/migration53.deprecated.php . Note that register global variables and long array names (e.g., $HTTP_POST_VARS) will be flat out unavailable (but are no longer needed in recent osC 2.2 RC releases). mysql_list_tables() (used in install) is also deprecated, but not in the list (so watch out for additions to this list). Anyone developing osC, developing add-ons for osC, or customizing osC code should be aware of this list. Merely turning off the warnings is not a good long-term solution! Given the level of support for osC 2.2, I'm not sure there are any efforts to make it PHP 6 compatible (you'll have to fix some things, such as ereg, on your own -- how about an add-on to bring all known PHP 6 exposures up to date?). I would expect osC 3.0 to be PHP 6-ready.

 

Have to agree .. I actually mentioned E_DEPRECATED in a post previously but it really must be seen as a short term "get me/the client going while I fix it" thing.

 

It won't happen that way of course most will suppress the errors and hope it goes away .. in fact osCommerce imo has invented this by suppressing notices as standard.

 

I often come across sites that don't even display unless warnings are suppressed! ridiculous.

 

In my opinion error_reporting should ALWAYS be set at the strict level for developing and at the E_ALL level for production too, you just don't output errors to the user you use set_error_handler() to handle them quietly.

[MrPhil]

http://github.com/osCommerce/oscommerce2 this has all of the files updated

Has anyone confirmed that all the other PHP 6 exposures (besides the ereg functions) have been addressed here? Is this effectively 2.2 RC3? If HPDL et al. are going to go through the bother of posting it on github, why not formally release an RC3 with all the accumulated 2.2 fixes (e.g., the navigation history bug, the MySQL 5 JOIN fix, the IE8 IE7 emulation, whatever else keeps popping up,...)? I've kept up-to-date with everything through RC2a, but it's a nuisance to have to poke through github to find bits and pieces of fixes.

[jfkafka]

Thanks to all for the ereg to preg modifications,

for some reason, am receiving this error even though

the code was updated with the new lines from github

(recommended by ecatz)

the error is:

 

Warning: preg_match() [function.preg-match]: Unknown modifier '/'

in C:\server\xampp\htdocs\public_html\includes\functions\validations.php on line 118

 

the replacement in the code is:

 

// TLDs should be 3 letters or more

// 12-15-09 deprecated if (eregi('^[a-z]{3,}$', $tld) == 1) {

// 12-15-09 deprecated $tld_pattern .= '^' . $tld . '$|';

if (preg_match('/^[a-z]{3,}$/i', $tld) == 1) {

$tld_pattern .= '/^' . $tld . '$|/i';

// 12-15-09 my feeble attempt doesn't work - $tld_pattern .= '/' . $tld . '/i';

 

made all the substitutions from github for validations.php

using version: (rc2a) $Id: validations.php 1739 2007-12-20 00:52:16Z hpdl $

have searched on google without success and wondering if this problem is

a personal one!

 

Thanks for any enlightenment

jk

[anonimouse]

The same is happening to me...

[MrPhil]

You weren't supposed to change the $tld_pattern line. That section of code should be

                 $tld = trim($words[0]);
                 // TLDs should be 3 letters or more
                 //if (eregi('^[a-z]{3,}$', $tld) == 1) {
                 if (preg_match('/^[a-z]{3,}$/i', $tld) == 1) {
                   $tld_pattern .= '^' . $tld . '$|';
                 }
               }
               // Remove last '|'
               $tld_pattern = substr($tld_pattern, 0, -1);
               //if (eregi("$tld_pattern", $top_level_domain) == 0) {
               if (preg_match("/$tld_pattern/i", $top_level_domain) == 0) {

As a result of your change of $tld_pattern, the next preg_match sees "//^tld_text$|/i/i". That's why you're getting complaints about "/" it doesn't know what to do with.

[anonimouse]

Thanks! It works now!

[jfkafka]

Thanks for your speedy and knowledgeable response, MrPhil,

have gotten past the validation error hurdle,

really appreciate it.

jk

[MrPhil]

@anonimouse and @jfkafka, you're both quite welcome.

[burt]

Work is ongoing on a "RC Final" and "3" in tandem, hence the commits.

I'd expect to see a finalised rc (based on rc2a + fixes) soon.

[AlanR]

Has anyone confirmed that all the other PHP 6 exposures (besides the ereg functions) have been addressed here? Is this effectively 2.2 RC3? If HPDL et al. are going to go through the bother of posting it on github, why not formally release an RC3 with all the accumulated 2.2 fixes (e.g., the navigation history bug, the MySQL 5 JOIN fix, the IE8 IE7 emulation, whatever else keeps popping up,...)? I've kept up-to-date with everything through RC2a, but it's a nuisance to have to poke through github to find bits and pieces of fixes.

Agreed

 

It's difficult to go though all the github changes and bring everything up to date since some files are changed two or three times. It's actually easier to work backwards datewise and remember which changes one has caught so as not to restore errors.

 

It would be nice to see a release.

[steve_s]

Hi all,

 

Can anyone help out with this

i changed

<?php if (eregi('^(.*)' . tep_session_name() . '=[a-f,0-9]+[&]*(.*)', $whos_online['last_page_url'], $array)) { echo $array[1] . $array[2]; } else { echo $whos_online['last_page_url']; } ?>

 

to

<?php if (preg_match('/^(.*)/i' . tep_session_name() . '=[a-f,0-9]+[&]*(.*)', $whos_online['last_page_url'], $array)) { echo $array[1] . $array[2]; } else { echo $whos_online['last_page_url']; } ?>

 

but i get this warning

 

PHP Warning: preg_match(): Unknown modifier 'o' in /srv/www/htdocs/store/admin/index.php im using a modified index.php

 

Steve

[♥FWR Media]

Hi all,

 

Can anyone help out with this

i changed

<?php if (eregi('^(.*)' . tep_session_name() . '=[a-f,0-9]+[&]*(.*)', $whos_online['last_page_url'], $array)) { echo $array[1] . $array[2]; } else { echo $whos_online['last_page_url']; } ?>

 

to

<?php if (preg_match('/^(.*)/i' . tep_session_name() . '=[a-f,0-9]+[&]*(.*)', $whos_online['last_page_url'], $array)) { echo $array[1] . $array[2]; } else { echo $whos_online['last_page_url']; } ?>

 

but i get this warning

 

PHP Warning: preg_match(): Unknown modifier 'o' in /srv/www/htdocs/store/admin/index.php im using a modified index.php

 

Steve

 

The pattern delimiters are in the wrong place .. aside from that it looks odd anyway, I'd need to know exactly what it was trying to do.

[♥FWR Media]

E.g.

if $whos_online['last_page_url'] contained http://www.mysite.com/product_info.php?products_id=27&osCsid=y73yt735yt3. The following modified pattern ..

 

  if ( preg_match( '/^(.*)([\??&?]' . tep_session_name() . '=[a-z0-9]+)(.*)/i', $whos_online['last_page_url'] , $array ) ) {
   echo '<pre>' . print_r( $array, true ) . '</pre>' . PHP_EOL;
 }

 

Would produce: -

 

Array
(
   [0] => http://www.mysite.com/product_info.php?products_id=27&osCsid=y73yt735yt3
   [1] => http://www.mysite.com/product_info.php?products_id=27
   [2] => &osCsid=y73yt735yt3
   [3] => 
)

 

So if the script was trying to strip the osCsid then $array[1] would suffice.

[Jan Zonjee]

The pattern delimiters are in the wrong place .. aside from that it looks odd anyway

Yep, Mark Evans fixed that in his own repository (moved the /i to another spot).

 

                <td class="dataTableContent"><?php if (preg_match('/^(.*)' . tep_session_name() . '=[a-f,0-9]+[&]*(.*)/i', $whos_online['last_page_url'], $array)) { echo $array[1] . $array[2]; } else { echo $whos_online['last_page_url']; } ?> </td>

[MrPhil]

preg_match('/^(.*)' . tep_session_name() . '=[a-f,0-9]+[&]*(.*)/i' ....

[Guest]

I tried all these fixes at github and now the admin/catalog/categories/products and admin/customer/orders section are blank ... totally missing. All the other admin listings are still there.

 

And get this error after deleting the sessions and whosonline table:

Parse error: syntax error, unexpected '{' in /home/xxxx/public_html/adminxxxx/includes/classes/language.php on line 87

(preg_match('/^(' . $value . ')(;q=[0-9]\\.[0-9])?$/i', $this->browser_languages[$i]) && isset($this->catalog_languages[$key])) {
           $this->language = $this->catalog_languages[$key];

 

Anyone know how to get these back?

 

Am using php 5.3.1 but will need to downgrade if there is no fix.

[Jan Zonjee]

Parse error: syntax error, unexpected '{' in /home/xxxx/public_html/adminxxxx/includes/classes/language.php on line 87

(preg_match('/^(' . $value . ')(;q=[0-9]\\.[0-9])?$/i', $this->browser_languages[$i]) && isset($this->catalog_languages[$key])) {
           $this->language = $this->catalog_languages[$key];

That particular line should have an if in front of it:

if (preg_match('/^(' . $value . ')(;q=[0-9]\\.[0-9])?$/i', $this->browser_languages[$i]) && isset($this->catalog_languages[$key])) {

[♥FWR Media]

I tried all these fixes at github and now the admin/catalog/categories/products and admin/customer/orders section are blank ... totally missing. All the other admin listings are still there.

 

And get this error after deleting the sessions and whosonline table:

Parse error: syntax error, unexpected '{' in /home/xxxx/public_html/adminxxxx/includes/classes/language.php on line 87

(preg_match('/^(' . $value . ')(;q=[0-9]\\.[0-9])?$/i', $this->browser_languages[$i]) && isset($this->catalog_languages[$key])) {
           $this->language = $this->catalog_languages[$key];

 

Anyone know how to get these back?

 

Am using php 5.3.1 but will need to downgrade if there is no fix.

 

Hi Melinda

 

That line looks like it should be ..

 

if (preg_match('/^(' . $value . ')(;q=[0-9]\\.[0-9])?$/i', $this->browser_languages[$i]) && isset($this->catalog_languages[$key])) {
 $this->language = $this->catalog_languages[$key];
}

 

That should sort your immediate error.

 

If you are struggling with the PHP 5.3.X thing my suggestion is to do as follows: -

 

Open up includes/application_top.php

 

Find ..

 

 error_reporting(E_ALL & ~E_NOTICE);

 

Replace with ..

 

  if ( defined( 'E_DEPRECATED' ) ) {
   error_reporting( E_ALL ^ E_NOTICE ^ E_DEPRECATED );
 } else {
   error_reporting(E_ALL & ~E_NOTICE);
 }

 

This will suppress the PHP5.3.X deprecated errors and give you some time to handle them perhaps in a dev environment.

[Guest]

That particular line should have an if in front of it:

if (preg_match('/^(' . $value . ')(;q=[0-9]\\.[0-9])?$/i', $this->browser_languages[$i]) && isset($this->catalog_languages[$key])) {

 

Thanks!

 

Strange how the categories/products and customers/orders section in the admin are blank. The info is still in the database.

 

There are more problems than the error reporting. People cannot order, admin table info missing so nobody can put a new product in, etc. I have decided to recompile apache to 5.2.12 and see what happens.

[Jan Zonjee]

Strange how the categories/products and customers/orders section in the admin are blank. The info is still in the database.

Probably there is an error somewhere. There is no error log?

[♥FWR Media]

Thanks!

 

Strange how the categories/products and customers/orders section in the admin are blank. The info is still in the database.

 

There are more problems than the error reporting. People cannot order, admin table info missing so nobody can put a new product in, etc. I have decided to recompile apache to 5.2.12 and see what happens.

 

5.3 does no more than create deprecated notices if you came from a decent PHP5.2.X

 

Having said that the build could have done "the usual" in as much as register_globals off, register_long_arrays off.

 

Have you checked those?