php3/mysql3 --> php5/mysql5 question

[Roaddoctor]

I'm in the middle of a server upgrade and so far so good. Could someone help me identify the problem in this code?

What needs to be changed to work on php5/mysql5/RHEL5/RC2a... Nothing I have tried has worked. This is code from the PDF DataSheet Maker 1.73. The problem is that the path and product name are not making it to the pdf. The rest of the addon is working fine.

 

    // Header Text
   $this->Ln(0);
   $path = $this->GetPath($products_id, $languages_id);
   $products_name = $this->ProductsName($products_id, $languages_id);
   $product_path_font=explode(",",PDF_PRODUCT_PATH_FONT);
   $this->SetFont($product_path_font[0],$product_path_font[1],$product_path_font[2]);
   $header_color_table=explode(",",PDF_HEADER_COLOR_TABLE);
   $this->SetFillColor($header_color_table[0], $header_color_table[1], $header_color_table[2]);
   $this->Cell(0,6,$path .' > '. $products_name,0,0,'L',1);
   $this->Ln(10);

 

And the queries

  function GetPath($products_id, $languages_id) {
   $cPath = '';
   $cat_count_sql = tep_db_query("select count(*) as count from " . TABLE_PRODUCTS_TO_CATEGORIES . " where products_id = '" . $products_id . "'");
   $cat_count_data = tep_db_fetch_array($cat_count_sql);
   if ($cat_count_data['count'] == 1) {
     $categories = array();
     $cat_id_sql = tep_db_query("select pc.categories_id, cd.categories_name from " . TABLE_PRODUCTS_TO_CATEGORIES . " pc,  " . TABLE_CATEGORIES_DESCRIPTION . " cd where
                                 pc.products_id = '" . $products_id . "' and
                                 cd.categories_id = pc.categories_id and
							  cd.language_id = '" . $languages_id . "'");
     $cat_id_data = tep_db_fetch_array($cat_id_sql);
     tep_get_parent_categories($categories, $cat_id_data['categories_id']);
     $size = sizeof($categories)-1;
     for ($i = $size; $i >= 0; $i--) {
       if ($cPath != '') $cPath .= ' > ';
       $parent_id_sql = tep_db_query("select categories_name from " . TABLE_CATEGORIES_DESCRIPTION . " where
          	                           categories_id = '" . $categories[$i] . "' and
                              		   language_id = '" . $languages_id . "'");
       $parent_id_data = tep_db_fetch_array($parent_id_sql);
       $cPath .= $parent_id_data['categories_name'];
     }
     if ($cPath != '') $cPath .= ' > ';
     $cPath .= $cat_id_data['categories_name'];
   }
   return $cPath;
 }

 function ProductsName($products_id, $languages_id) {
   $products_name_query = tep_db_query("select products_name from " . TABLE_PRODUCTS_DESCRIPTION . " where
                                        products_id = '" . $products_id . "' and
                                        language_id = '" . $languages_id . "'");
   $products_name = tep_db_fetch_array($products_name_query);
   return $products_name['products_name'];
 }

 

Thanks!

[MrPhil]

A few things off the top of my head... MySQL 5 is not perfectly upward compatible with earlier versions. Your "left join" SQL operations will fail if you don't update your osC code (see http://www.oscommerce.com/forums/topic/335136-osc-and-mysql-5-1054-errors ). PHP 5 probably has register global variables turned off by default, so you will either need to manually turn them back on (usually a php.ini entry), or upgrade to the current osC (2.2 RC2a) which doesn't use register globals. If your system was running on PHP 3 and MySQL 3, I would assume that you've got a very old version of osC (pre 2.2 RC1, anyway). PHP 5 may also give you error messages about "deprecated ereg functions". Here's the fix: http://www.oscommerce.com/forums/topic/341737-function-ereg-replace-is-deprecated/page__p__1434612__hl__eregi%20deprecated__fromsearch__1entry1447311 . Get those three things out of the way, and if you still have problems, we can take a closer look at your custom(?) code.

[Roaddoctor]

A few things off the top of my head... MySQL 5 is not perfectly upward compatible with earlier versions. Your "left join" SQL operations will fail if you don't update your osC code (see http://www.oscommerce.com/forums/topic/335136-osc-and-mysql-5-1054-errors ). PHP 5 probably has register global variables turned off by default, so you will either need to manually turn them back on (usually a php.ini entry), or upgrade to the current osC (2.2 RC2a) which doesn't use register globals. If your system was running on PHP 3 and MySQL 3, I would assume that you've got a very old version of osC (pre 2.2 RC1, anyway). PHP 5 may also give you error messages about "deprecated ereg functions". Here's the fix: http://www.oscommerce.com/forums/topic/341737-function-ereg-replace-is-deprecated/page__p__1434612__hl__eregi%20deprecated__fromsearch__1entry1447311 . Get those three things out of the way, and if you still have problems, we can take a closer look at your custom(?) code.

 

Thank you for the reply!

 

To clarify - The shop IS 2.2rc2a being built on a clean install on a new server running RHEL5/php5/mysql5/reg global off. The pdf datasheet addon in question works fine on my old 3x server, but not on the new 5x.. I will look/apply to the two procedures you mention to the addon and see if either apply. Thanks for pointer!

[Roaddoctor]

MrPhil,

 

I have performed all of the FROM LEFT JOIN corrections for the entire site - done. I was not having 1054 errors prior (that I know of) with "php_flag display_errors on" in .htaccess.

I do not think the other procedures you suggested apply - as this is a fresh rc2a install on RHEL5 server. correct?

The cat path and product name are still not making it to the pdf - no change.

 

I had one thought last night - Does Header Tags SEO change the way the cat path and product name are called? I will post that question in that forum, but if you have any thoughts on how to fix the original code posted above above your input is greatly appreciated.

 

If you wish to review the entire file visit PDF DataSheet Maker 1.73 http://addons.oscommerce.com/info/1077 , and the file is catalog/pdf/pdf_datasheet_functions.php. I've also noticed one other item is not making it to the pdf, Product Attributes.

 

Dave

[MrPhil]

If you're using MySQL v5, you will eventually start seeing 1054 errors unless you fix the LEFT JOINs.

 

Since this was an up-to-date 2.2 RC2a installation, it doesn't use register global variables and you don't have to turn them on or off (your PHP installation probably defaults to off).

 

You might want to check with your host about using "php_flag" or "php_value" settings in your .htaccess file. Most installations require that such PHP settings be in a php.ini file, but if they work for you, fine. On my server, I would get a 500 error if I did that. The LEFT JOIN problem is a MySQL error, and would probably not be affected by the PHP display errors setting.

 

Have you confirmed that your custom/add-on PHP code (for the PDF) is not using register global variables? That is, does it just start using $cPath or anything else from the URL Query String, rather than $cPath = $_REQUEST['cPath'];? That would be using register global variables, and would fail. You might try, as an experiment, turning register global variables on and seeing if the PDF code now works. If it does, I would suggest modifying the code to go through $_REQUEST as shown above. I don't see anything in the code you gave that jumps out at me, so I'd try the register globals bit first.

[♥kymation]

I'm using the latast version of PDF DataSheet Maker on MySQL 5.0.67-log/PHP 5.2.11 (Zend: 2.2.0). Everything works fine. Header Tags SEO should not make any difference either. Are you using a URL Rewriter (SEO URLs) of any sort? That will interfere with passing the parameters.

 

Regards

Jim

[♥kymation]

Oops -- ignore that last post. I forgot how many changes I made to that addon. Yes, it's a Register Globals problem. Add the following to the top of pdf_datasheet.php:

  $products_id = '';
 if (isset($_GET['products_id']) && $_GET['products_id'] != '') {
   $products_id = (int) $_GET['products_id'];
 }

Regards

Jim

[Roaddoctor]

Kymation your Awesome! that did the trick. I will be sure to post that in the PDF Datasheet support thread for others to benefit.

 

MrPhil - Thank you also for your instruction. You were on target with it being a register global issue.

One question regarding all the EREG deprecated stuff - Is it wise use of my time to sift thru the entire site and change the ereg funtions to preg funtions as illustrated on the Github site? If I understand correctly the purpose of this is only to be php6 ready?? Is that correct? or am I mistaken

On Github, when changes are "commited" by hpdl, does that mean we should make these change?

 

Thank you both again for your help!

[MrPhil]

Yeah, that old register global code will get you every time.

 

My understanding is that this will be mandatory when your site switches (some day) to PHP 6. Until then, with PHP 5.something, it will be a nuisance to get the warning, but your site will still work. Unless you plan to never switch to PHP 6, or you're sure that your store will be gone before then, you might as well go through and clean up the code. You'll be done with it (unless you reload osC 2.2 over it again) -- I don't know if there are any plans to update the distributed RC3 or gold (when they come out). As for Harald's "commit" on Github, I would assume that these fixes are pretty solid and can be trusted. I've gone through the 2.2 RC2a base code myself and looked for the deprecated functions, and it looks like he hit all of them. Of course, contributions and other add-ons must be checked out and fixed separately.

[Roaddoctor]

MrPhil,

 

Ive done all the Github ereg to preg changes as posted here with only one subsequnet error that I've found (so far)

 

in admin/server_info.php

 

112-    ereg('<body>(.*)</body>', $phpinfo, $regs);
112+    preg_match('/<body>(.*)<\/body>/', $phpinfo, $regs);

 

breaks the page. If I may ask, how does your file appear?

 

Anyone else that does this be sure to apply the changes in all 5 links provided or you will have errors.

[MrPhil]

Mine looks like yours. That change should be correct. Are you sure that's the line causing an error? What kind of error are you getting? Maybe during editing you broke something on a nearby line? Can we see the error message, and the offending line with 10 lines of code before and after it?

[Roaddoctor]

Mine looks like yours. That change should be correct. Are you sure that's the line causing an error? What kind of error are you getting? Maybe during editing you broke something on a nearby line? Can we see the error message, and the offending line with 10 lines of code before and after it?

 

the page loads, but stops at the title "osCommerce Online Merchant v2.2 RC2a" box with tthe oscommerce logo, and is then blank page

 

<?php
 if (function_exists('ob_start')) {
?>
<style type="text/css">
body, td, th {font-family: sans-serif; font-size: 10px;}
.p {text-align: left;}
.e {background-color: #ccccff; font-weight: bold;}
.h {background-color: #9999cc; font-weight: bold;}
.v {background-color: #cccccc;}
i {color: #666666;}
hr {display: none;}
</style>
<?php
   ob_start();
   phpinfo();
   $phpinfo = ob_get_contents();
   ob_end_clean();

   $phpinfo = str_replace('border: 1px', '', $phpinfo);
//    ereg('<body>(.*)</body>', $phpinfo, $regs);
   preg_match('/<body>(.*)<\/body>/', $phpinfo, $regs);    // this seems broke - github update
   echo '<table border="1" cellpadding="3" width="600" style="border: 0px; border-color: #000000;">' .
        '  <tr><td><a href="http://www.oscommerce.com"><img border="0" src="images/oscommerce.png" title="' . PROJECT_VERSION . '" /></a><h1 class="p"> ' . PROJECT_VERSION . '</h1></td>' . 
        '  </tr>' .
        '</table>';
   echo $regs[1];
 } else {
   phpinfo();
 }
?>
       </td>
     </tr>
   </table></td>
<!-- body_text_eof //-->
 </tr>
</table>
<!-- body_eof //-->

[MrPhil]

Hmm. If you comment out the new preg_match and uncomment the ereg call, does it work (albeit with the deprecated function warning)? If not, it's not that line, and you'll have to start commenting out other lines to see which one causes the failure.

[Roaddoctor]

yes, the file works fine with ereg - all the server details get listed.

But the file breaks with the preg_match.

Of course this is nothing critical or urgent, just an info file. I've just left it with ereg for now. but if it breaks for me its likely to do the same for other I would think.

 

perhaps something different in our servers?

Server OS: Linux 2.6.18-164.2.1.el5

Database: MySQL 5.0.77

HTTP Server: Apache/2.2.3 (Red Hat)

PHP Version: 5.1.6 (Zend: 2.1.0)

 

I manage my own server so if their are things to look at I can do that.

[♥kymation]

That code doesn't work on my server either. Pearl regex syntax is indeed voodoo. After sacrificing a chicken (yes, I had it for lunch) I have come up with the following fix:

    preg_match('/<body>(.*)<\/body>/is', $phpinfo, $regs);

This works on the two machines I've tried it on, but I offer no guarantees. Try it and let me know if it works for you.

 

Regards

Jim

[Roaddoctor]

That code doesn't work on my server either. Pearl regex syntax is indeed voodoo. After sacrificing a chicken (yes, I had it for lunch) I have come up with the following fix:

    preg_match('/<body>(.*)<\/body>/is', $phpinfo, $regs);

This works on the two machines I've tried it on, but I offer no guarantees. Try it and let me know if it works for you.

 

Regards

Jim

 

As usual, your voodoo chicken sacrifice has worked its charm. - Thank you! and someone send the memo to hpdl :)

[Roaddoctor]

btw, I'm sort of understanding the different syntax, but what does the "i" or "is"(in this case) do?

 

I've been skimming thru http://www.perl.com/doc/manual/html/pod/perlre.html#NAME to try to pick this up a bit better

[♥kymation]

I'm not all that good at the Perl syntax, but as I recall:

 

i is the case insensitive flag. Not really needed here, but I just always add it where I'm not concerned about case. And if some future version of phpinfo() starts returning <BODY>, this code will still work.

 

s is the magic here. The manual says that it is for single lines, while \m is multiline. I've found that it seems to be the opposite. In any case, if one doesn't work, try the other. It all has to do with how the match code handles line endings. There also seems to be some sort of default setting that varies by php.ini or some other setting. This would explain why the version without this flag will sometimes work and sometimes fail.

 

I have a couple of cheat sheets for regexes, but I can't recall where I got them. There are plenty of on-line resources that list the syntax and all of the elements. Understanding the voodoo is another matter entirely. No, I don't claim to even begin to understand it.

 

Regards

Jim