[Done v1.5.5] PHP 5.4 warnings: Illegal string offset

[Woodymon]

Assuming there were no other code change dependencies in play,
I tested the new code in the two github links posted above on a a ZC 1.51 shop:

1. RE: https://github.com/zencart/zencart/c...2cb78fc86946c9

Tested the code changes in twelve files on above github page

After editing the twelve files, added virtual download products to shopping cart, then clicked "Go to Checkout", then observed the following error:

https://domainname/shop/index.php?ma...ckout_shipping

Error in Firefox: "The page isn't redirecting properly. Firefox has detected that the server is redirecting the request for this address in a way that will never complete. This problem can sometimes be caused by disabling or refusing to accept cookies."

I ensured Firefox was not blocking cookies, and indeed, checking out with download products in the cart worked before updating the twelve files. I observe the same result in IE.

Had no issue checking out with physical products.

2. In regards to the file update for tpl_checkout_shipping_default.php

The github change code for the above file shows "$checked = FALSE;" as a pre-existing line of code.

// set the radio button to be checked if it is the method chosen
$checked = FALSE;

however, this line does not already appear in the zc 1.51 stock file.

And yet github does not show the line of code "$checked = FALSE;" as new
(not displayed in green with a "+" symbol) indicating it should be added.

I went ahead added that code line.


3. Re: https://github.com/zencart/zencart/c...6deb80026d2886

Employed the code changes in /includes/functions/sessions.php

Following that, I observed the sessionid (zenid) was no longer appended to the shop URL while navigating through the shop (and user tracking mod logs showed the same).

Observed no related error or warnings in either the server error log or zc logs.

Reverting to the stock sessions.php, zenid was again employed.

[vanhorn_s]

My understanding, is that the two github posts, are the changes made to 1.6.0, not the changes that we need to make to 1.5.0, or 1.5.1
I made the changes discussed in the posts here, and that is what worked. I am still running 1.5.0

[vanhorn_s]

I made all of the file changes discussed on the first page, and I am now getting this error again:
[04-Dec-2013 15:49:10 America/Denver] PHP Warning: Illegal string offset 'cost' in /home2/redsauto/public_html/includes/classes/order.php on line 355
There are only 3 of these in my cache, when I have had 19 orders since I switched to php 5.4
How do I determine what is setting this error now, being that it is such a low occurrence?

[lat9]

I made all of the file changes discussed on the first page, and I am now getting this error again:
[04-Dec-2013 15:49:10 America/Denver] PHP Warning: Illegal string offset 'cost' in /home2/redsauto/public_html/includes/classes/order.php on line 355
There are only 3 of these in my cache, when I have had 19 orders since I switched to php 5.4
How do I determine what is setting this error now, being that it is such a low occurrence?

Of the 19 orders, were 3 of them using a different shipping method?

[countrycharm]

lat9 some of my client are still getting lots of error logs to after making all the changes. I'm not sure about the shipping method. Any ideas

[lat9]

countrycharm: Which changes are "all the changes"?

[countrycharm]

countrycharm: Which changes are "all the changes"?

I already stated it here.

http://www.zen-cart.com/showthread.p...10#post1224510

[vanhorn_s]

Of the 19 orders, were 3 of them using a different shipping method?

They have all been USPS

[lat9]

The changes made for Zen Cart v1.5.2 were much more "intense" that those that I proposed in this thread. Please see https://github.com/zencart/zencart/c...2cb78fc86946c9 for the full set of changes made to v1.5.2 surrounding this issue.

[rayw1679]

What is the impact of this error? Does it prevent the order from being completed, or just have the possibility of incorrect data? (We use flat-rate shipping, so we shouldn't be invoking any special calculations; however, we've had 10 of these errors within the past 2 months.) The fix appears extensive, and I don't want to break my store applying the fix (I'm good at that) if it's not a severe problem.