ozpost shipping module

[Bruce1952]

I really don't have enough information from you to determine what the cause of the problem is.

I can tell you that the system itself is working perfectly, so it *must* be some kind of data problem.

Can you please confirm that your ununstall/install was the admin keypress sequence, and not a matter of removing and re-installing the ozpost files?

Can you please confirm that when you install the upgrade that the new 'skippy post' options appear (If the don't, then something has gone amiss with the database update).

Can you please confirm that you verified the WEIGHT setting in the ozpost settings? (This has been known to unset itself with some upgrades, resulting in weights being 1000x greater than they should be).

Can you please confirm that the problem only exists with overseas shipments.

Can you please try getting a quote from more than one destination (eg: USA and UK, etc) just to be sure that the problem doesn't relate to a specific country.

Can you please enable the ozpost DEBUG function and perform a test puchase then email a screencapture of the output to me at [email protected]. I suggest you do this at a quiet time and disable the DEBUG as soon as possible after the screen capture so that it doesn't cause customer complaints).

You probably won't need to check/do ALL of these things in order to solve the problem, but they are all things that I need to know in order for me to determine what and where things are going amiss.

Simply put, until you can provide more information, I can only guess what the cause is. It could be any of the above, or something else entirely.

Cheers
Rod

Rodd,

Found the error and for some reason when the update was done it changed the weight from kilo to gram. Once changed back all was working again. Will have to try and remember for next update. One other thing is because we have a heavy mode site each time you send an update it interferes with files and causes us to have to recode after the update.

[RodG]

Found the error and for some reason when the update was done it changed the weight from kilo to gram. Once changed back all was working again. Will have to try and remember for next update.

This is/was a 'one time only' problem that was caused by a 'minor' change to make all of the Gms/gms & Kgs/kgs text definitions consistant.

One other thing is because we have a heavy mode site each time you send an update it interferes with files and causes us to have to recode after the update.

The update code is supposed to 'patch' any existing code (rather than replace any files). If you could provide details as to how/where this is causing you a problem I'll be more than happy to see what I can do to rectify the issue.

Cheers
Rod

[RodG]

Hi Rod
I'm getting this error in the cache since the last upgrade: ".... Australia/Sydney] PHP Warning: Creating default object from empty value in /home/myadmin/public_html/store/includes/modules/shipping_estimator.php on line 117". There is also another error that is much the same but is on line 107. The shipping seems to be working OK just getting these errors.

Robyn

Hmmm, this could be a tough one. The "Australia/Sydney" looks to me like it is somehow related to a timezone setting, and the ozpost module doesn't make any direct use of this.

Having said that, about the only change to the latest update that I can see that *could* cause this, is in line#354 (or thereabouts) of /includes/modules/shipping/ozpost.php and the line that reads:

error_reporting(E_ALL) ;

This is increasing the log level for the servertest function (which means it should only produce the error when the 'test the ozpost servers' link is clicked. You could try commenting out this line to see if the problem goes away.

Also, if you do a Google search for "Creating default object from empty value" you'll find dozens of similar reports for lots of different software, along with various hints/tips as to how to rectify/hide the problem.

It *is* just a 'warning', and as such it won't affect the code functionality in any way, and although it could well be an ozpost issue, in that I haven't inititialised a variable somewhere, unless I can somehow reproduce the problem (I've not had any luck in doing so yet) it isn't something I can easily fix.

Looking at this another way, the 'error' will/should only be reported if the PHP log level has been set to ' E_STRICT', which *isn't* recommended for a production site.

I'll do what I can when I next get back to the code, but I'll repeat, it isn't a problem that you really need to worry about.

I *do* appreciate that you've brought it to my attention though.

Cheers
Rod

[robbie269]

Looking at this another way, the 'error' will/should only be reported if the PHP log level has been set to ' E_STRICT', which *isn't* recommended for a production site.

Thanks Rod

Sorry I did not reply earlier. The thread notification did not work.

I think the errors started when my hosting company upgraded their servers to PHP 5.4. It stuffed up my timezone and they said to put it in the php.ini file.

The part above about E_strict, which file is that located in?

Robyn

[RodG]

The part above about E_strict, which file is that located in?

There are several possible places where this can be 'fixed'

http://stackoverflow.com/questions/9...rds-in-php-5-4

Cheers
Rod

[robbie269]

There are several possible places where this can be 'fixed'

http://stackoverflow.com/questions/9...rds-in-php-5-4

Cheers
Rod

Great resource that stackoverflow site.
Did some more looking and found that to stop empty value errors you add = new stdClass(); . So I added $order = new stdClass(); above the troublesome line. It seems to have worked. Ran the shipping estimator again and there were no errors in the cache.

Do you think it is a safe option??

Robyn

[RodG]

Great resource that stackoverflow site.

Yeah, without even trying I find I seem to end up there when seeking the solution to many problems.

Did some more looking and found that to stop empty value errors you add = new stdClass(); . So I added $order = new stdClass(); above the troublesome line. It seems to have worked. Ran the shipping estimator again and there were no errors in the cache.

Well done. This is a far better solution than simply trying to suppress the warnings.

Do you think it is a safe option??

Personally I can't see it as being unsafe in any way, but I will add that this may not be the best place to initialize the $order variable (which is what you are doing). I'm making this statement because after having a quick look at the code/file I noted that the $order variable is being initialized on line#85 (albeit in a slightly different manner), and that if your fix is the 'correct' one, then the same fix should probably be applied to the other similar code within those elseif blocks.
IOW, you may have only achieved a partial fix for one possible condition.

The most important thing here though is that you have proven a point or two.

The 1st thing you've proven is that the fix works.
The second thing you have proven is that it isn't an ozpost problem, so I probably have no need to scour the ozpost code for a variable that I've failed to initialize.

So having found this, if Dr Byte, Ajeh, or one of the other dev team members could please take note. This same problem has been reported by another person in another thread in relation to the USP shipping module. In neither case is the problem in the shipping modules themselves, but as Robbie has found, it is being caused by an unitialised $order variable in the shipping_estimator.php file, which as you know is one of the core zencart files.

I'm expecting that there will be more and more of these error reports as the various hosts upgrade their PHP to V5.4.x so hopefully one of you guys can take a closer look into this to see if robbies solution is indeed 'safe', and whether or not there is an easier/better solution.

Cheers
Rod.

[RodG]

Do you think it is a safe option??

It still looks 'safe', but my earlier suspicions have just been confirmed, this is probably not the optimum location for the fix. You'll probably need to apply the same fix just before line#92

http://www.zen-cart.com/showthread.p...33#post1222033

Cheers
Rod

[robbie269]

It still looks 'safe', but my earlier suspicions have just been confirmed, this is probably not the optimum location for the fix. You'll probably need to apply the same fix just before line#92

http://www.zen-cart.com/showthread.p...33#post1222033

Cheers
Rod

Hi Rod

Funnily enough I did put it above line 92 as I was getting 2 errors, one at line 117 and one at line 92.
This is the code I added (red being the new code):

$order = new stdClass();
	$order->delivery = array('postcode' => $zip_code,

I may have to add the code above line 117 as well.

Robyn

[robbie269]

I may have to add the code above line 117 as well.

I got errors overnight for line 117 and 107 but not line 92. So I have partially fixed it.
I have now added the code above lines 92, 107 & 117. The lines with $order->delivery. Hopefully that gets rid of all the errors.

Robyn