New 
bopper
-
Posts
79 -
Joined
-
Last visited
-
Days Won
1
Posts posted by bopper
-
-
Hello,
I'm getting inaccurate rates for ground shipments to Canada. To ship a 2 LBS package to Canada at fedex.com cost me FedEx International Ground: $33.86, osCommerce quoted a customer for this shipment Federal Express (Ground Service (4 days)): $18.03. I don't have any discount rates for my FedEx account and 'Show List Rates' is set to False in Admin --> Modules --> Fedex settings. What might be wrong with the osc rates?
Thanks.
Hi Irina
Have you figured out anything on this? We are also getting rate quotes for Canada that are much less than the actual shipping cost.
bopp
-
We have a new store that will offer both USPS Priority Mail and FedEx shipping.
We've got the USPS Priority Mail working beautifully.
I don't see an option to select FedEx in the shipping admin section.
Does this require some fancy 'contributions' and configuration? :blink: :blink:
What's the simplest way to add FedEx shipping as an option for our customers?
Thanks!
go to the community contributions link and find the fedex mod (search easiest)....download and install....
-
vger's fix worked....authorize.net now gets the order amount the coupon discount correctly...we don't use paypal ipn so no problem there (use paypal.php,v 1.1.1.1 2004/09/22 which seems to work okay after the fix...also COD works)...CCGV trad is a good mod....
I'm trying this fix from vger...will report back to see if it works....http://www.oscommerce.com/forums/index.php?sho...p;#entry1014609
-
I'm trying this fix from vger...will report back to see if it works....
http://www.oscommerce.com/forums/index.php?sho...p;#entry1014609
We are having this problem too....anybody got a fix? using the authorize.net AIM mod....thanks
bopp
-
Hi Jason
Did you ever figure out why this is happening? We are having the same problem....using the authorize.net AIM mod
thanks
bopp
I just moved the OT modules around so that on the checkout_confirmation page the total shows including the coupon discount. However, It�s still transmitting at the pre coupon total. I�ve tried to look through the manual and install again but I didn�t find and missed steps. :sweating: -
We are having this problem too....anybody got a fix? using the authorize.net AIM mod....
thanks
bopp
Did you ever find a fix for this? If you did fix your problem it is a good idea to post your findings here so others can hopefully take note.If you are still looking for a fix you need post back with details of which Authorizenet contribution you are using (AIM or standard) and what modifications you have made to the store in general.
-
same problem...the function (tep_cfg_multiinput_list) goes in fuctions/general.php as outlined in step 5 of the installation instructions....
missed it first time around...
couldn't get 4.3 to work...USPS error...had to revert to 4.2.1
-
When I was trying to do the quick update, I had the same issue. Searched for an answer, couldnt find it. Do a full install. (follow the first 6 steps in the instructions then try again. worked for me.
same problem...the function (tep_cfg_multiinput_list) goes in fuctions/general.php as outlined in step 5 of the installation instructions....
missed it first time around...
-
will this latest revision work in a v2.2 store?
thanks
-
Hi Bill
Tried that too but didn't work...using <?php echo $basepath ?> for the css and js urls is the only thing that seems to work...where
$basepath = (($request_type == 'SSL') ? HTTPS_SERVER : HTTP_SERVER) . DIR_WS_CATALOG;
but I'm still getting the secure/non-secure items alert in IE...can't find what else is causing that...
ryan,Do not use the STS tag $templatedir inside your css file but rather use it to link to your css file. For example:
<link rel="stylesheet" type="text/css" href="$templatedir/stylesheet.css">
Then, you add the following in your css file:
background-image: url('YOURIMAGE.jpg') -
I've tried your advice Bill to no avail... I tried putting $templatedir/ in front of the background image url in the css file but that makes the background images not show at all (don't think it can handle the $templatedir var in a css file)...if my css image url is:
background-image: url(images/tile2.jpg);
then that path should be relative whether the sever is secure or not, and no non-secure items warning should ever display...but it isn't, and that is an STS thing...I have templated many osc sites manually and never run across these path problems using that method....and they are coded to "osc standards"...I admit it is a bit more work when changes to layout are made and that is why I tried STS...but in my experience and the long run it has been much simpler, faster and stable for me to do the layout templating manually...for sure it is possible that something in the configuration of my shops is not quite kosher (I've set up 30+ osc stores)...but layering a complicated app with more complications does not make my job simpler...lol...
I'm glad you took the time to write your mod and that it works well for many of those who use it...not everyone is a programmer and STS attemps to address this...it just hasn't worked out well for me...
thanks for your time
ryan
Ryan,I'm not trying to argue with you but you are not listening to my advice.
Use the STS tag $templatedir to link to your images (even your background images). This method does not have any issues with SSL. The tag points to your template directory and is dynamic so that you can have multiple template folders and not have to modify your links each time you change folders in the admin.
I strongly disagree with your statement regarding if a shop works before STS and has issues afterwards that the problem lies with STS. This is not true. You could begin with a shop that is not configured properly (but appears to work) and have faulty code (again, that appears to work) and STS will not function properly because of those underlying issues. STS requires a solid osC shop that is coded to osC standards. I understand your point but just wanted to emphasize the above as well.
I truley feel your image issue is a simple one and can be resolved by simply using relative links along with the proper use of the $templatedir tag. I have created several shared SSL shops with this method and had no SSL issues at all.
Hope this helps you out, if not, please post again and we will work it out together.
-
You missed the point...the stylesheet is being found okay...but the extra layer that STS puts on the site is preventing background images from getting the proper path, so IE throws up the secure/non-secure alert box...which of course is not conducive to a good shopping flow experience...
if a site works fine without STS and then doesn't work with STS turned on then I'd say STS has a problem...it may be an STS config thing but I have tried everything I can think of and still have not been able to resolve this problem...note that this problem is on a site with a shared SSL server...that may be part of the problem...but STS does not handle it well...
ryan
Nope, STS is not the problem but rather how STS is being used.$templatedir/images/blah.gif is completely SSL safe. This example will link to blah.gif in includes/sts_templates/your_template_folder/images .
You should be using $templatedir/stylesheet.css for the path to any template specific stylesheet.css file being referenced.
-
Jim,
Not caused by STS, but rather this is most likely due to how your image links have been created in your templates. You should use relative links not absolute links such as http://blah.com/images/blah.gif, make them like /images/blah.gif
Have to disagree with you Bill...it is STS's poor handling of paths that is the problem in cases like this...I've run across this type of thing before with STS but was able to get around it by using <?php echo $basepath ?> before any image or file calls in the pages. But i have not been able to find a way to prevent IE from giving a secure/non-secure warning for background images whose urls are defined in a css file...I think the only way to get around it is to get rid of any background image calls in the css file...instead will have to define them in the head section and use php to add the basepath to the url dynamically...there is a problem with paths caused by the extra "layer" of the template when the site has a shared ssl server...
-
hey ryan, did you ever figure this out?
ryan
Perhaps the moderator should move this to Payment Modules > PayPalEither way, after researching others posts and trying at least one other fix which was to modify the catalog/product_attributes
from this thread
http://www.oscommerce.com/forums/index.php?sho...20IPN&st=20
Original code:
<td align="center" class="smallText"> <?php echo $options_values["products_options_id"]; ?> </td> <!-- BOF Product Option Type --> <td class="smallText"> <?php echo translate_type_to_name($options_values["products_options_type"]); ?> </td> <!-- CLR 030212 - Add column for option type //--> <td class="smallText"> <?php echo $options_values["products_options_length"]; ?> </td> <!-- CLR 030212 - Add column for option length //--> <td class="smallText"> <?php echo $options_values["products_options_comment"]; ?> </td> <!-- CLR 030212 - Add column for option comment //--> <!-- EOF Product Option Type -->With added line under <!-- BOF Product Option Type -->
<td align="center" class="smallText"> <?php echo $options_values["products_options_id"]; ?> </td> <!-- BOF Product Option Type --> <td class="smallText"><?php echo $options_values['products_options_name']; ?></td> <td class="smallText"> <?php echo translate_type_to_name($options_values["products_options_type"]); ?> </td> <!-- CLR 030212 - Add column for option type //--> <td class="smallText"> <?php echo $options_values["products_options_length"]; ?> </td> <!-- CLR 030212 - Add column for option length //--> <td class="smallText"> <?php echo $options_values["products_options_comment"]; ?> </td> <!-- CLR 030212 - Add column for option comment //--> <!-- EOF Product Option Type -->However, it did not appear to work. I trying to find an answer already, or figure it out on my own, but my first experience with building a site was 2 months ago, and I am hoping someone far more brilliant can point me in the right direction
Here is an example from the confirmation email from ordering via check and the name 'Tempt' does appear
Products
------------------------------------------------------
1 x Lady Bug #1 () = $24.65
Bib Color Pink
Collar/Neck Lace Trimmed
Collar/Neck Color Pink
Name: (Up to 9 letters) Tempt
------------------------------------------------------
Here is an example from Paypal IPN
Products
------------------------------------------------------
1 x Example -Not for Sale = $0.13
Bib Color Pink
Collar/Neck Color Red
Collar/Neck Lace Trimmed
Lettering Black with white polka dots
Name: (Up to 9 letters) TEXT
------------------------------------------------------
Thanks for you help,
Ryan
-
forum is not letting me edit...all I've found so far is that it appears to be a http redirect problem:
HTTP/1.1 401 Authorization Required is what getimagesize() returns...
now it lets me edit...lol
anyway...there was a difference...the wholesalecatalog directory had an htaccess password set on it...I turned that off and now my images in the non-template content are now getting the correct heights and widths...that should not make a difference but the layers of code probably cause this...
but I still get a 500 internal server error when clicking on any of the ssl links on the page...they have the correct urls so I'm still stumped...
bopp
finally figured this out..somehow the .htaccess file got this added to it in the wholesalecatalog directory:
<IfModule mod_setenvif.c>
<IfDefine SSL>
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</IfDefine>
</IfModule>
don't know where it came from (sts?) but I commented it out and now the SSL links work okay...
so just posting this for anyone who has SSL problems using sts...something to check out...
bopp out
-
forum is not letting me edit...all I've found so far is that it appears to be a http redirect problem:
HTTP/1.1 401 Authorization Required is what getimagesize() returns...
now it lets me edit...lol
anyway...there was a difference...the wholesalecatalog directory had an htaccess password set on it...I turned that off and now my images in the non-template content are now getting the correct heights and widths...that should not make a difference but the layers of code probably cause this...
but I still get a 500 internal server error when clicking on any of the ssl links on the page...they have the correct urls so I'm still stumped...
bopp
-
(bkellum @ Mar 3 2008, 01:10 AM) *
Ryan, my comments sounded a little rough but they were not meant to be. blush.gif
I was just pointing out that image links are usually the culprit when it comes to SSL problems, not any code changes that are implemented by installing STS.
I do think that while designing your template, it is probably easier to use absolute links so that you can preview your template. However, these should always be changed over to relative links before uploading to your store. thumbsup.gif
When someone mentions that they did not have any issues until STS then it implies that STS has some errant code and is to blame. STS, as a osCommerce add-on, has no control of how a user goes about using/abusing the contribution. STS assumes that it is being installed upon solid osCommerce core code and not upon any other add-ons that were not created with other contributions in mind. STS works great with the "properly coded" add-ons available.
With that said, I suggest that anyone who has SSL issues, to first look at the code of thier shop. It is most likely due to image or external links which could so happen to be in the STS template that they created.
STS out of the box does not have any SSL issues.
Hope that helps anyone in the future who may be dealing with SSL issues. :-
Hi Bill
I'm having a hard time believing that "STS out of the box does not have any SSL issues." It has path issues in general that arre beyond the scope of many. I did find a workaround for the previous problem I had with SSL and images but now have run into a new problem that so far I have not been able to crack. I have made an exact duplicate of the original osc sts store for a wholesale store, with the only difference of course being the cookie and catalog directory paths in configure.php. I am having
major path problems again with this store. Images are not getting sized correctly because for some reason getimagesize($src) fails, so no width or height is returned for images that use the osc SMALL_IMAGE_WIDTH, SMALL_IMAGE_HEIGHT parameters. I can print the $src out okay before the getimagesize conditional but then the "if ($image_size = @getimagesize($src))" condition fails because of some screwup with the $src and so that block is bypassed.
Also, all SSL links in this copy return a 500 internal server error when clicked on. I'm stumped. I am using an ip in the config during development but this was not a problem in the original osc sts store. Also the SSL server is shared so the links are like https://secure2-hosting.net/domain/wholesalecatalog/...but again, that is not a problem in the original catalog. Got any ideas as to why this duplication of a working sts store is failing?
This is really frustrating but I realize there is only so much you can do. Being a programmer I wouldn't have gone this route but I took this store over from someone else.
thanks, bopp
-
the osc board is not letting me edit again...I wanted to add that the the wholesale store is an exact duplicate of the main store, with the only difference of course being the cookie and catalog directory paths in configure.php.
This is really frustrating but I realize there is only so much you can do. Being a programmer I wouldn't have gone this route but I took this store over from someone else.
thanks, bopp
-
Ryan, my comments sounded a little rough but they were not meant to be. :blush:
I was just pointing out that image links are usually the culprit when it comes to SSL problems, not any code changes that are implemented by installing STS.
I do think that while designing your template, it is probably easier to use absolute links so that you can preview your template. However, these should always be changed over to relative links before uploading to your store. :thumbsup:
When someone mentions that they did not have any issues until STS then it implies that STS has some errant code and is to blame. STS, as a osCommerce add-on, has no control of how a user goes about using/abusing the contribution. STS assumes that it is being installed upon solid osCommerce core code and not upon any other add-ons that were not created with other contributions in mind. STS works great with the "properly coded" add-ons available.
With that said, I suggest that anyone who has SSL issues, to first look at the code of thier shop. It is most likely due to image or external links which could so happen to be in the STS template that they created.
STS out of the box does not have any SSL issues.
Hope that helps anyone in the future who may be dealing with SSL issues. :-
Hi Bill
I'm having a hard time believing that "STS out of the box does not have any SSL issues." I did find a workaround for the previous problem I had with SSL and images but now have run into a new problem that so far I have not been able to crack. I have made an exact duplicate of the original osc sts store for a wholesale store. I am having
major path problems again with this store. Images are not getting sized correctly because for some reason getimagesize($src) fails, so no width or height is returned. I can print the $src out okay before the getimagesize conditional but then the "if ($image_size = @getimagesize($src))" condition fails and so that block is bypassed.
Also, all SSL links in this copy return a 500 internal server error when clicked on. I'm stumped. I am using an ip in the config during development but this was not a problem in the original osc sts store. Also the SSL server is shared so the links are like https://secure2-hosting.net/domain/wholesalecatalog/...but again, that is not a problem in the original catalog. Got any ideas as to why this duplication of a working sts store is failing?
thanks
bopp
-
If you have SSL image problems, and happen to have STS installed, the easy solution is to blame STS.
to be clear, I had no SSL problems until I added STS, and I have no problems with images or links that are in the content from the original pages...just had a problem with images and links on the sts template page
-
followup on this...still getting bad quotes ...the osc mod and the UPS online rate calculator frequently give quite different quotes...(it's not the insurance thing, turned that off)...getting some quotes to ups from the logger for them to look at...
bopp
-
That's a lot of work to fix a problem that isn't caused by STS.
If you have SSL image problems, and happen to have STS installed, the easy solution is to blame STS. The real solution would be to have your configure.php files configured correctly and your links setup correctly as well. You may even need to search each line of code in your catalog for any absolute links and correct them.
Even if you have other issues in your shop, STS still tries to help you out by allowing you to place your images and stylesheet in your templates folder and use the STS tage "$templatedir" to reference them.
For example: If your template folder is "my_templates", then you would upload your images to catalog/includes/sts_templates/my_templates/images. You would link to those images as so:
$templatedir/images/my_image.gif
.
By using the tag, you are keeping your links "relative" and not "absolute" which is the root of SSL image issues.
You can upload your stylesheet into your template folder and link to it as so:
<link rel="stylesheet" type="text/css" href="$templatedir/stylesheet.css">
Hi Bill
I tried that fix for images and css but it didn't work...tried everything i could think of but the solution i finally got to work, altho clunky, did fix the problem...only so many hours in the day...
thanks
bopp
-
It could be a server issue, but it is not due to any contributions or anything else. This has been an on going topic when osC RC1 was first release and the edit I mentioned above was the solution that was provided by the community as well as it seems that it that this is still an ongoing thing with osC RC 2.
I am just providing this information to help those who are beating their head at why their secure pages are coming up unsecure.
I too have had SSL problems with STS....templates worked fine on nonssl pages but image and links on ssl pages did not show or function correctly. I tried many fixes including trying to put the images in the templates directory and switching that on in html_outout.php....spent quite some time trying to figure it out. I had the same problem of using a shared SSL server: the path was missing the site domain name in the the SSL urls so images wouldn't display and links such as those to the css pages weren't working.
The "fix" I finally came up with was to put
<?php
global $request_type;
$basepath = (($request_type == 'SSL') ? HTTPS_SERVER : HTTP_SERVER) . DIR_WS_CATALOG;
?>
at the top of my template page.
Then I added <?php echo $basepath ?> before any of my image src fields and style page or other links.
That works well.
So my image paths used to look like:
https://secureserver.net/catalog2/images/nav/headerCap.jpg
Now they look like:
https://secureserver.net/domainname/catalog...v/headerCap.jpg
Seems like there is probably a better way but I have a life and only so much time to waste...
-
You asked for $199 insurance - that's the difference.
as usual, the devil's in the details...thanks for your assistance Steve...
at least this time I have something to explain the disparity to the customer...lol
FedEx Direct 2.06 Support thread
in Shipping Modules
Posted
what I figured out is that if you get a quote from the FedEx site without logging in it doesn't apply any account discounts or whatever so the quote on the fedex site if not logged in is higher. If I log in to my account on the fedex website and then get the quote, it is exactly the same as the OSC quote. So problem solved for me and the customer.