ozpost shipping module

vandiermen:

Yes the Demo account is working.

Ergo, there is nothing amiss with the code.

vandiermen:

I believe it is caused by TNTs changes over the last couple of weeks.

I'm not going to rule this out, but it seems VERY VERY UNLIKELY! What evidence do you have to believe this is the cause?

vandiermen:

They have asked me to email them with the calculator code.

On the same token, I asked you to try resetting the primealt credentials. Did you do that yet?

I also suggested: if you've recently updated to ozpost V3.5.2 you could try performing the uninstall/install keypress sequence
Did you try that yet?

I'm not trying to give you are hard time or make things difficult for you here, but the error message clearly states
"Username and password combination is incorrect". This isn't a 'generic' error message, it is very specific, and as you have confirmed the code works when it is provided valid credentials. It seems that it is only primealt that is having a problem. I see no reason for anyone (including you) to waste time to follow up on extremely remote possibilities until this very likely probably has been well and truly eliminated.

I'd even go as far to suggesting you change the password (on both the TNT rtt site as well as the ozpost settings) to see if that makes a difference).

This, and the other suggestions I've made will take just a few minutes. The idea that the code is at fault for one particular customer only and that the fault is in the code rather than the credentials takes a huge step of imagination. I envision that both I and the TNT technical people could waste weeks of time looking for a non existent fault (these are always the hardest to find).

vandiermen:

They have asked me to email them with the calculator code. Do you have anything you would recommend sending them.

IF we can verify that it is a coding issue, rather than something amiss with the credentials, and IF I am unable to isolate the problem myself, then, and only then will I be prepared to share my code with the TNT technicians. This isn't something that I can simply cut 'n' paste. It is integrated into the server code, which means many hours of work to 'de-integrate' it into something that can be used for standalone testing and debugging. There's a ton of things I can do before I would even consider going to such an extreme measure. Most notably, I'd be requesting a copy of the account credentials so that I can perform my own testing and debugging (which will require that the password be changed after I've done testing anyway), so that takes us back to my current suggestions.. Change the password.

Again, I'm not trying to give you a hard time, and as always, I'm willing to go to almost any length to solve the problem, but I'm NOT going to go providing code to the TNT people and have them running around in circles unless I have very good reason to do so. I currently don't have that reason.

If you can't find/fix the problem by resetting the password, then just provide me with the credentials being used (PM or email please), and I'll take it from there.
I don't need the login details for the store (so please don't supply them). All I need are the TNT details (account#, username & password).

I can promise you that I'll have this sorted long before the TNT guys will. There is no reason for you to be the man in the middle as that will simply prolong the issue.

Cheers
Rod

ps. The last time I 'shared' my code with Zenners, it was hacked and used in a manner that is/was ultimately detrimental to everyone (especially me). I'm not going to make the same mistake twice. If anyone here wishes to create their own TNT module they'll need to do their own research for the API details and ways to implement it. I value the time and effort I put into this, even if others don't. (I'm not suggesting or implying that this is your intent, but I'm sure there are at least one or two people around here that would have no qualms in screwing me over again)

Rod,

I have uninstalled and reinstall but it is still not showing the options for express post or international. I have ticked nearly all options for express post, air mail sea mail etc but they don't show up and only giving flat rate. Would have I done something wrong with settings to cause the issue?

RodG:

On the same token, I asked you to try resetting the primealt credentials. Did you do that yet?

nope except I re-entered the credentials within ozpost.

RodG:

I also suggested: if you've recently updated to ozpost V3.5.2 you could try performing the uninstall/install keypress sequence
Did you try that yet?
yes, i did that before contacting you, complete reinstall (new upload) and check

RodG:

I'd even go as far to suggesting you change the password (on both the TNT rtt site as well as the ozpost settings) to see if that makes a difference).
I went to login as I did before and login did not work as it did before, I requested the current password / password reset and got a new password, and TNT on our website **is now working **

Thanks for your support!. Excellent.

vandiermen:

Rod:

you could try performing the uninstall/install keypress sequence
complete reinstall (new upload) and check
For future reference, a 'new upload' will rarely ever fix a problem related an upgrade. It is far more important that you use the uninstall/install keypress sequence from the admin panel. If you upload new files, but fail to perform this all important step you have more chance of causing problems rather than fixing them.

vandiermen:

and TNT on our website **is now working **

Sweet.

It's a pity that it took so long to resolve though, and sadly, I don't know if we'll ever find the cause now. It could be the result of the password change, or it could be the result of the email that I sent to TNT late last night (considering the nature of the problem I thought it wise to send them a few details regarding who was having a problem, and what my own findings were).

I've not had a reply from them yet, so I'm guessing that the password change was the most likely resolution.

Just one quick question for you though, did the original password have any 'special characters' in it, such as underscores, ampersands, @ symbols, etc, or was it only alpha/numeric characters? I can appreciate that this is now a bit of a moot point, but it is one of the few things that I can think of that could cause a problem as a result of the recent changes they've made. If there were any of these characters in the original password this is still an avenue that I'd like to explore/investigate further.

Cheers
Rod

Bruce1952:

Rod,

I have uninstalled and reinstall but it is still not showing the options for express post or international. I have ticked nearly all options for express post, air mail sea mail etc but they don't show up and only giving flat rate. Would have I done something wrong with settings to cause the issue?

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

RodG:

Just one quick question for you though, did the original password have any 'special characters' in it, such as underscores, ampersands, @ symbols, etc, or was it only alpha/numeric characters? I can appreciate that this is now a bit of a moot point, but it is one of the few things that I can think of that could cause a problem as a result of the recent changes they've made. If there were any of these characters in the original password this is still an avenue that I'd like to explore/investigate further.
no special characters

vandiermen:

no special characters

Bang goes that theory.

Thanks for the reply.

Cheers
Rod

Bruce1952:

I have uninstalled and reinstall but it is still not showing the options for express post or international. I have ticked nearly all options for express post, air mail sea mail etc but they don't show up and only giving flat rate. Would have I done something wrong with settings to cause the issue?

I note that things started working for you shortly after my last response (and has been working for the last 2 days).

Needless to say, I'm pleased that this is the case, but if you don't mind me asking, did you manage to discover the cause, or did you try several things at the same time before the problem was resolved? (Your response could help me better guide anyone else with a similar problem).

Cheers
Rod

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

RodG:

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.

Bruce1952:

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.

Bruce1952:

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

robbie269:

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

RodG:

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

robbie269:

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/9983286/disabling-strict-standards-in-php-5-4

Cheers
Rod

RodG:

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

http://stackoverflow.com/questions/9983286/disabling-strict-standards-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

robbie269:

Great resource that stackoverflow site.

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

robbie269:

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.

robbie269:

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.

robbie269:

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.php?210384-error-codes-for-shipping_estimator-php&p=1222033#post1222033

Cheers
Rod

RodG:

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.php?210384-error-codes-for-shipping_estimator-php&p=1222033#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

robbie269:

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.

I haven't tried, but I'm wondering if adding

$order = new stdClass();

To line#46 or thereabouts would take the place of all of the other additions (as well as any others not yet identified)

Cheers
Rod