Printable View
It's a bug, and that will be a fine workaround.Quote:
Originally Posted by Foster660
The official fix (not yet released) would be to change
toCode:$sdl = substr(strtoupper( MODULE_SHIPPING_OZPOST_SDL ),0,3);
What has happened is that somewhere along the line the constant has lost a portion of its name, therefore remains undefined causing it to eval to 'MOD' regardless of actual setting.Code:$sdl = substr(strtoupper( MODULE_SHIPPING_OZPOST_TYPE_SDL ),0,3) ;
Cheers
Rod
Thanks Rod, that worked nicely :)
John
curl
cURL support enabled cURL Information 7.36.0 Age 3 Features AsynchDNS Yes CharConv No Debug No GSS-Negotiate Yes IDN Yes IPv6 Yes krb4 No Largefile Yes libz Yes NTLM Yes NTLMWB Yes SPNEGO No SSL Yes SSPI No TLS-SRP No Protocols dict, file, ftp, ftps, gopher, http, https, imap, imaps, ldap, ldaps, pop3, pop3s, rtsp, scp, sftp, smtp, smtps, telnet, tftp Host x86_64-redhat-linux-gnu SSL Version OpenSSL/0.9.8b ZLib Version 1.2.3 libSSH Version libssh2/1.4.3
Is what is installed
I don't know what changed but we did not renew for a long time and the expiry date kept on resetting to 55 days while I was working on the draft. Could this happen if your server rejects request from our site?Quote:
Originally Posted by RodG
Our *servers* - Three of them, on different networks, all running independently, will never block or reject a connection from any store. It/They *need* to be accessible in order to check the subscription status.Quote:
Originally Posted by vandiermen
The '55 days' is a bit of a mystery too. Positive numbers are the number of days left remaining on a subscription, negative number are the days since the subscription has expired. New stores (those that have never connected to the server before are given a 60 day subscription.
I suspect that the '55 days' is perhaps a stored/cached value - but then is the question, you say it is resetting *to* this value, what is the value(s) that it is resetting it *from*?
Your screenshot show that cURL is apparently installed, so therefore it must be 'some other network error'.
Here's the thing - This problem, whatever the cause, if far more likely to be related to your *single* server rather than the 3 independent servers that we have spread across the globe, so looking to ozpost as being the *source* of the problem is pretty much going to be futile.
As for the error message Network Connectivity test FAILED
Is cURL installed?
This comes about as the result of a rather simple test. A request is sent to our server(s)
http://svr1.ozpost.net/quotefor.php?...client_version
http://svr2.ozpost.net/quotefor.php?...client_version
http://svr0.ozpost.net/quotefor.php?...client_version
The result is expected to be
"V1.2.3". The *numbers* will change over time (currently V4.2.6), but the "V" is considered a constant, so as long as the 'V' exists, the test will pass. If we don't get the expected 'V' response then a network error is assumed, with 'cURL' being the prime (but not the only) suspect.
I really can't help you any more than this - For some reason, your store simply isn't getting the expected response from our servers, and it isn't our servers doing the blocking or returning an invalid result for this very simple query.
Basically. I'm at a loss.
Cheers
Rod
If I PM you the FTP/cPanel details, or send them by your contact page, would that help?
I'd rather you didn't.Quote:
Originally Posted by vandiermen
Instead, please d/load the attached .zip file, extract the contents (ozpost_test.php), upload the php into the top level folder of your store, then execute it by pointing your browser to http:/yourstore.com/ozpost_test.php?detail
This should provide *some* clue as to what is going on (rather than a simple 'test failed').
Cheers
Rod
Rod
I'm extending my ozpost.inc to handle another category of products. As usual I'm stuffing multiple charts into a tube but the tubes vary in size and capacity, plus I have the added joy of shipping flat packs. I'm now getting shipping quotes roughly double expected for even single tubes and I think that somehow the code is doubling the number of tubes and this the weight. Here is a typical debug output:
The Parcel Build (No Pack) is correct but the Items in Parcel is 2 when it should be 1.Quote:
[parcel_build] => Parcel Created by svr1+ On Sat Feb 03, 2018 13:44 (Server Time)
Fits into Medium Tube (weight permitting)<-----------------------------------------Don't know how this is determined
Number Parcels : 2<------------------------------------------------------------------NOT Correct Should be 1
Dimensions: 75 x 8 x 8 cm<---------------------------------------------------------Correct
Weight :1.288kg = 2 * 0.644kg<----------------------------------------------------NOT Correct Should be 1 * 0.644kg
Parcel Value : $30<-------------------------------------------------------------------NOT Correct. Should be $15
====== Parcel Build (NoPack) ======
Item 1, Qty 1<-------------------------------------------Correct
Item Value $15<-----------------------------------------Correct
Item Weight 0.644kg<-----------------------------------Correct
Item Dimensions 75 x 8 x 8 (cm)<---------------------Correct
----------------------------------
Items in Parcel :2 <--------------------------------NOT Correct. Should be 1
Parcel Weight 0.644kg <---------------------------Correct
Parcel Dimensions:75 x 8 x 8 (cm)<--------------Correct
Parcel Contents Value $30<------------------------NOT Correct Should be $15
--------------------------------------------------------------------
If I add another item, also with a quantity of 1, I get this:
Quote:
[parcel_build] => Parcel Created by svr1+ On Sat Feb 03, 2018 15:49 (Server Time) Fits into Large Tube (weight permitting)
Number of Items in list : 2
Number of Items in Parcel : 4
Dimensions: 75 x 16 x 16 cm
Weight :2.576kg
Parcel Value : $60
====== Parcel Build ======
Item 1, Qty 2
Item Value $15
Item Weight 0.644kg
Item Dimensions 75 x 8 x 8 (cm)
Bulk Pack Dimensions 75 x 16 x 8 (cm) ( Packed as 1x2x1 )
----------------------------------
Items in Parcel :2
Parcel Weight 1.288kg
Parcel Dimensions:75 x 16 x 8 (cm)
Parcel Contents Value $30
--------------------------------------------------------------------
Item 2, Qty 2
Item Value $15
Item Weight 0.644kg
Item Dimensions 75 x 8 x 8 (cm)
Bulk Pack Dimensions 75 x 16 x 8 (cm) ( Packed as 1x2x1 )
----------------------------------
Items in Parcel :4
Parcel Weight 2.576kg
Parcel Dimensions:75 x 16 x 16 (cm)
Parcel Contents Value $60
--------------------------------------------------------------------
So this fail seems to be a constant factor regardless of the actual quantity of an item or the number of items in the cart. At this stage I'm suspecting a problem with ozpost.php but can't quite finger it. Certainly, the ozpost server is having trouble working out the dimensions of the bundle, ignoring the results from ozpost.inc and doubling the small dimensions of the tube willy nilly before interrogating the shipping servers. In this context the meaning of $NoPack is ambiguous to me. Whether I set it to 0, 1 or comment it out entirely the shipping calculations shown in the parcel build are all over the place but nowhere accurate.Code:// Set basic parameters that don't change within the line item processing loop $control_tare = "" ; // It is generally good to add tare to a parcel. I've disabled it here on the *assumption* that there will be no other items in the cart
// If there are other items the ozpost servers will assume you will be packing these tubed items into the same box as other items so
// disabling tare here isn't what it really wanted
$tws = 204; // weight (gm) of a single small tube 73 x 8 x 8 cms
$twm = 256; // weight (gm) of a single medium tube 75 x 10 x 10 cms < this is the original tube
$twl = 672; // weight (gm) of a single large tube 75 x 20 x 20 cms - used instead of 5 large tubes
$twx = 1070; // weight (gm) of a single maxi tube 97 x 20 x 20 cms - only used for shipping a combination of banners and charts
$twf = 500; // weight (gm) of a single flatpack 70 x 100 x 2 cms - this is the original packaging from the printer - 2 sheets of kraft paper
$twsmax = 2; // max qty charts in a single small tube 73 x 8 x 8 cms
$twmmax = 5; // max qty charts in a single medium tube 75 x 10 x 10 cms < this is the original tube
$twlmax = 25; // max qty charts in a single large tube 75 x 20 x 20 cms - used instead of 5 large tubes
$twxmax = 25; // max qty charts in a single maxi tube 97 x 20 x 20 cms - only used for shipping a combination of banners and charts
$twfmax = 25; // max qty charts in a single flatpack - only used for shipping to colleges
// loop through $shipme items
for ($index = 0 ; $index < count($shipme) ; $index++ ) {
/// set parameters that are used in each loop
$tq = 0; // the qty of tubes that will be needed
$pcat = $shipme[$index]['category'] ; // the category of products in this line item
$pnum = $shipme[$index]['id'] ; // the product id of this line item
$pq = $shipme[$index]['quantity'] ; // the quantity of products in this line item
$pw = $shipme[$index]['weight'] ; //the weight of the product (usually chartsets but may be banners or books)
$pp = $shipme[$index]['price'] ; //the weight of the product (usually chartsets but may be banners or books)
/// if (($shipme[$index]['category'] == "1" ) && (stristr($shipme[$index]['name'], "Chart")) ) { // Only if category '1' and name contains 'chart'
switch ($pcat):
case 1: // Only if category '1' ie Wallcharts
if ($pq < 3):
{ $tw = $tws; $tq = floor($pq / $twsmax); $length = 75 ; $height = 8 ; $width = 8 ; } // special calc to handle stuffing up to 2 charts per small tube
elseif ($pq < 16):
{ $tw = $twm; $tq = ceil($pq / $twmmax); $length = 75 ; $height = 10 ; $width = 10 ; } // special calc to handle stuffing up to 5 charts per medium (large) tube
elseif ($pq < 26):
{ $tw = $twl; $tq = ceil($pq / $twlmax); $length = 75 ; $height = 20 ; $width = 20 ; } // special calc to handle stuffing up to 25 charts per large (mega) tube
else:
{ $tw = $twl; $tq = ceil($pq / $twlmax); $length = 75 ; $height = 20 ; $width = 20 ;} // let's give up here and go for the basic solution since actual packing will involve a variety of tubes.
endif;
break;
case 7:// Only if category '7' ie Wholesale which consists of larger tubes and flatpacks
if ($pnum = 21): // medium tube
{ $tw = $twm; $tq = ceil($pq / $twmmax); $length = 75 ; $height = 10 ; $width = 10 ; } // special calc to handle stuffing up to 5 charts per medium tube
elseif ($pnum = 20): // large tube
{ $tw = $twl; $tq = ceil($pq / $twlmax); $length = 75 ; $height = 20 ; $width = 20 ; } // special calc to handle stuffing up to 25 charts per large tube
elseif ($pnum = 19): //flat pack
{ $tw = $twf; $tq = ceil($pq / $twfmax); $length = 100 ; $height = 2 ; $width = 70 ; } // special calc to handle 25 chartsets in a flatpack
endif;
break;
endswitch; // not this category
if ($tq = 2): {$kraft = 250;} // half a sheet for two small tubes
elseif ($tq > 2 && $tq < 6): {$kraft = 500;} // a full sheet for two or more medium tubes
endif;
$products_weight = (($pw * $pq) + ($tw * $tq)) / $tq + $kraft ; //(weight of one chart * qty ordered) + (weight of the tube * qty of tubes needed) + weight of kraft paper to overwrap tubes
$parcelWeight += $products_weight ;
$packageItems += $tq ;
$productValue = $pp * $pq ;
echo "\nTube Qty = ".$tq."\n"."Tube Weight = ".$tw."\n";
echo "\nTQ = ".ceil($pq/$twmmax);
/// Finished processing this line item. let's output what we've found
// $width = 0 used for debugging missing data //
$items[] = array(
'Length' => $length * 10,
'Width' => $width * 10,
'Height' => $height * 10,
'Weight' => $products_weight,
'Qty' => $tq,
'Insurance' => $productValue );
$shipme[$index] = null ; // Mark item as done
$NoPack = 1 ; // Treat the tubes as separate parcels - Note: Only works if only one 'item' is in the cart. Comment out for normal packing
} // next item
Any suggestions?
This is probably a clue. The ozpost server will only do the 'right thing' with a 'NoPack' option is there is only one item in the items[] array. If the server is reporting 2 items it can only be because there are two "items" being sent to the server.Quote:
Originally Posted by lucidlee
Before calling the ozpost.inc the code creates an array of 'shipme' items, it is this array that gets passed/manipulated by the .inc file, which should then return back to ozpost.php with *one* item, and an empty/nullified shipme array.
If it returns with two items[] array it means that the .inc file has for some reason created two of them (the items[] array doesn't exist prior to entering the .inc code. Alternatively, if the .inc code return just one item[] , but there is still an unnullified shipme[] array then whatever is left in the shipme[] gets copied/added to the items[] array. The server then tries to perform its calcs based on the two items, one of which may or may not contain more than one item, which then get treated as products rather than parcels. Basically, all *very* confusing, which is why I've not tried to replicate this feature into the modules for other eCommerce systems.
This could be where things are falling over and the two item[]'s are being created. I'm guessing that there should be a check added here to negate the NoPack = 1 if items[] > 1. but doing this would cause the server to try to 'pack' the item[qty] rather than treat it as a parcel[qty].Quote:
Originally Posted by lucidlee
Basically, the server code isn't 'smart' enough to handle multiple *parcels* and multiple *quantities* at the same time, so (as far as I can determine from the very messy hacked together code), the 'qty x parcels' you have created are being treated as 'qty x item' by virtue of their being two items[] rather than just one item[]
I've not made any changes to this aspect of the ozpost.php code since the day it was created, which then brings us back to the .inc code, or possibly your changes to the .inc code has exposed a bug that has always been there, but only now just revealed?Quote:
Originally Posted by lucidlee
It wouldn't be willy nilly. Computers are far more predictable than that.Quote:
Originally Posted by lucidlee
What is happening, as far as I can see, is that you have two items[]. The 1st one having a qty of 2 x tubes, and the second having 'x' x products, and because the servers can only handle *one* item[] with 'x' tubes, and you are supplying two items, the server is treating your tubes as products, and adding them to the other product(s) so you are no longer being calculated for two tubes, but two tube sized products, that are being stacked against whatever the other item is.
In the context of more than one item[], the NoPack has no meaning or function. In the context of only one item[] it changes the calculation from being based on (size * qty) to (size * 1) * qty (does that make sense?)Quote:
Originally Posted by lucidlee
My only suggestion is to ensure that there is only one item[] to be quoted for as this will allow the 'NoPack' do its job and treat the 'qty' as #of parcels rather than #of items.
Hmm, another possibility is if you do have 'mixed' items/parcels to quote for is to manipulate the item[] as parcel data so that it has the correct weights and dimensions for the number of parcels needed, and set the qty to '1' - This will stop the weights/dimensions from being multiplied by the qty (well, not stop, but 1x1 = 1) - but this means you won't be quoted based on #number of tubes and that should give correct results (assuming all tubes and other items are packed into a single box for shipping). I would suggest adding a conditional when doing this, so if only a qty of tubes are needed (single item[]) then that function will continue to work as it always has been.
So to summarize as best I can.
One item (several charts) with 'NoPack' set the quote will be based on the cost of one tube, multiplied by the number of tubes.
One item (several charts) with 'NoPack' NOT set the quote will be based on the size of the tube, multiplied by the quantity of items (if three charts are in a tube, then the qty of items will need to be '1'. The servers don't 'care' how many items are in the tube,
With more than one item the NoPack is ignored, and the quote is based on the calculated size of all items and quantities of each item (this is the default behaviour).
At the end of the day, if you use the ozpost.inc it becomes your responsibility to provide the servers the correct data needed to provide the the desired results, regardless of whether you with to use one item[] with NoPack (indicating #of parcels), or more than one item, leaving the ozpost servers to stack them into a single package. The key point to remember is that 'NoPack' only works when there is a single item[] array.
Hope this helps. Its all bloody confusing to me though. :)
Cheers
Rod
Hi RodG, Is this still a feature that works with the new my post business?Quote:
Originally Posted by RodG
Sorry, but no, the Click n Send CSV support was dropped about 2 years ago (perhaps longer).Quote:
Originally Posted by gee38l
No one mourned its demise.
Cheers
Rod