First: this is not a syntax error, just a notification that the function split() is deprecated, i.e. it will not be maintained and may -- possibly -- not be included in some future release. That being the case, you can certainly go ahead and replace it with [man]preg_split/man, but if you are getting any actual errors, I would prioritize dealing with them over dealing with notice-level warnings such as this.

Anyway, you could use preg_split() as:

$resticted_categories = preg_split('/ ?, ?/',
      MODULE_PAYMENT_GOOGLECHECKOUT_RESTRICTED_CATEGORIES);

(Assuming I've correctly interpreted that you want to split on zero or one space followed by a comma followed by zero or one space)

    Thanks for the reply, I'm a complete novice so excuse my terminology as I try and get to grips with PHP.

    Thank you for the preg_split() line, it's extremely helpful. I had read somwhere else that replacing split() with explode() may also work, so I had already edited the GoogleCheckout file and replaced with explode(). This has stopped the error logs, but whether or not it will cause problems at a later stage I don't know. So, I'll change it with the preg_split() function you so kindly provided.

    I do understand that these logs are merely warnings that the deprecated functions will no longer be supported with the next release of PHP comes live. That's why I'm slowly but surely working through each log and updating these functions to 5.3 standard.

    When the next release of PHP (6?) comes out, I don't want to be caught out still using deprecated functions.

      limelites;10958363 wrote:

      ...
      When the next release of PHP (6?) comes out, I don't want to be caught out still using deprecated functions.

      It's certainly a good idea to replace them if you can, though there is no guarantee that it will not still be available in PHP 6 -- there's just no guarantee that it will be, either. 🙂

        Here's one that's been cropping up now and again. I can't figure it out at all. Maybe you could take a look?

        PHP Warning: Division by zero in/includes/modules/order_total/ot_group_pricing.php on line 79

        Line 79 goes like this:

        $ratio = $od_amount['total']/$order_total;

        The full function goes like this:

          function calculate_deductions($order_total) {
    global $db, $order;
    $od_amount = array();
    $orderTotal = $this->get_order_total();
    $orderTotalTax = $orderTotal['tax'];
    $group_query = $db->Execute("select customers_group_pricing from " . TABLE_CUSTOMERS . " where customers_id = '" . (int)$_SESSION['customer_id'] . "'");
    if ($group_query->fields['customers_group_pricing'] != '0') {
      $group_discount = $db->Execute("select group_name, group_percentage from " . TABLE_GROUP_PRICING . "
                                      where group_id = '" . (int)$group_query->fields['customers_group_pricing'] . "'");
      $gift_vouchers = $_SESSION['cart']->gv_only();
      $discount = ($order_total - $gift_vouchers) * $group_discount->fields['group_percentage'] / 100;
      $od_amount['total'] = round($discount, 2);
      $ratio = $od_amount['total']/$order_total;
      /**
       * when calculating the ratio add some insignificant values to stop divide by zero errors
       */

        It's the same file that was running on PHP 5.2 with no errors. But as soon as we went over to 5.3 it's warning about divide by zero. Don't suppose you know what's causing it?

          Apparently $order_total is 0 or empty. How do you call this function?

            I'm the worlds worst for posting just moments before I find the answer. I found the solution a second ago on the ZC forums by Dr. Byte. I just had to add

            if ($order_total == 0) return $od_amount;

            So it looks like this now:

            function calculate_deductions($order_total) {
    global $db, $order;
    $od_amount = array();
	if ($order_total == 0) return $od_amount;
    $orderTotal = $this->get_order_total();
    $orderTotalTax = $orderTotal['tax'];
    $group_query = $db->Execute("select customers_group_pricing from " . TABLE_CUSTOMERS . " where customers_id = '" . (int)$_SESSION['customer_id'] . "'");
    if ($group_query->fields['customers_group_pricing'] != '0') {
      $group_discount = $db->Execute("select group_name, group_percentage from " . TABLE_GROUP_PRICING . "
                                      where group_id = '" . (int)$group_query->fields['customers_group_pricing'] . "'");
      $gift_vouchers = $_SESSION['cart']->gv_only();
      $discount = ($order_total - $gift_vouchers) * $group_discount->fields['group_percentage'] / 100;
      $od_amount['total'] = round($discount, 2);
      $ratio = $od_amount['total']/$order_total;
      /**
       * when calculating the ratio add some insignificant values to stop divide by zero errors
       */

            ............ now onto the next error log 🙂

              OK, here's the latest error log I'm struggling with. Again, no such error on PHP 5.2, but as soon as we weont over to PHP 5.3 we get this:

              PHP Warning: explode() expects parameter 2 to be string, array given in limelite/public_html/includes/functions/functions_general.php on line 561

              Line 561 reads:

              $pieces = explode(':', $uprid);

              Can anyone see why it's creating this error? Parameter 2 sure looks like a string?

                Here's a note of the full function:

                  function zen_get_prid($uprid) {
    $pieces = explode(':', $uprid);

return $pieces[0];
  }
                  limelites wrote:

                  Parameter 2 sure looks like a string?

                  How can you tell? It just looks like a variable to me. 🙂

                  Place a [man]var_dump/man right before that line, e.g.:

                  var_dump($uprid);

                  and let us know what the output is.

                  Also, just FYI, as of right now, there isn't anything called PHP 6" in development; the trunk version currently reports 5.3.99 (at least, it did when I compiled it a week or so ago).

                    I found a little thread about this very same error and it turns out that in Zen Cart v1.3.9d (and previous) when updating the quantity of a product from the shopping cart page the above error is triggered twice in the myDebug log.

                    I have found out that this was being caused by a line in /includes/classes/shopping_cart.php in function actionUpdateProduct() at about line 1543:

                    $cart_qty = $this->in_cart_mixed($_POST['products_id']);

                    Should have read ...

                    $cart_qty = $this->in_cart_mixed($_POST['products_id'][$i]);

                    I've edited the shopping_cart.php file accordingly. Initial testing shows that this error log is no longer generating. I don't think I'll need to use that var_dump just yet, but thank you very much for letting me know such a thing exists 🙂 I am sure I'll need it in the near future as I try and erradicate all these error logs!

                    I'm getting through them. When I first switched to 5.3 my cache folder grew 11GB overnight (error logs). Millions of them! I've now gotten it down to a few KB every few hours. Thanks to forums and helpful advice such as yours.

                    Now, onto the next one :o

                      I'm stumped again with this one:

                      Function eregi() is deprecated in /admin/includes/classes/language.php on line 100

                      Line 100 reads:

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

                      Trying to rewrite this line with preg_match() function and getting nowhere. Could anyone please help with the new 5.3 syntax for this function, I'm useless at it? :queasy:

                        1. Change 'eregi' to 'preg_match'

                        2. Add pattern delimiters (common choice is a forward slash; if that's used in the pattern, either pick a different delimiter or escape the character when it appears within the pattern)

                        3. Since you're using the 'i' ereg function (for case-insensitivity), add an 'i' after the closing delimiter (so the pattern looks like '/foo/i').

                        EDIT: Also, take a look at this manual page: [man]reference.pcre.pattern.posix[/man]

                          Thanks for that, but I'm none the wiser unfortunately. I'm a total nwebie with PHP. I was hoping you might find some time to add the delimeters for me on this one so that I can see exactly how you change it and use it for future references.

                          The one in the OP, replied to by NogDog was very, very helpful asI've since been able to cross reference it successfully with other very similar ereg() functions. This new one has me totally baffled though. If you are able to fins time to add # delimeters or other suitable delimeters then I'd be eternally grateful. It would serve as a ver useful thread for other as well.

                            I could certainly spoonfeed you the code all day long, but that wouldn't help anyone. And besides, you're asking me to "find some time" to add a slash in front of and behind the pattern. You seriously aren't capable of doing that on your own? :/

                            Read the manual page I linked to. Better yet, the word "delimiters" on that page links to a manual page dedicated to that concept: [man]regexp.reference.delimiters[/man].

                              I looked at the link you sent, in fact I've been trying to decypher those pages for the last few days now 🙂 Every time I attempt to add my own delimiters, I end up with a white screen. I'm seriously hopeless at it, but when I have a worked example it makes it so much easier.

                              Surely it's not this simple (added 2 forward slashes):

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

                                You added the slashes outside of the string; the delimiters are part of the PCRE pattern, and the entire pattern is just a normal string like any other.

                                  See, I told you I was hopeless without a worked example. Am I getting warmer with this one:

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

                                    No, I think I've cracked it:

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

                                    Would that be correct then?

                                      Looks fine to me...

                                      EDIT: Oops - didn't notice your second reply before posting. The first pattern worked fine for me, so I would assume the second one (using case-insensitive searching) would also work.

                                        Yeah, I'd missed a backslash in the first one, but the 2nd one's working now. Thanks for your help with that, I'm slowly but sirely getting through them all 🙂

                                        Now, onto the next one.........