Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

auzStar

Members
  • Posts

    580
  • Joined

  • Last visited

  • Days Won

    26

auzStar last won the day on June 23 2019

auzStar had the most liked content!

4 Followers

Profile Information

  • Real Name
    Dominic C.
  • Gender
    Male
  • Location
    Australia

Recent Profile Visitors

17,147 profile views
  1. @valquiria23 The file contains javascript code. It's the javascript code that appears in the source which is normal. cheers
  2. @milkman45 All I can suggest is that you compare your Auspost shipping module files with the original files, and also investigate and do further testing to see if it some other cause. Sorry, but I can't help any further than that. ip 52.222.138.160 has nothing to do with this module. Regardless, I have no control over the response times from the Auspost servers in retrieving shipping rates. I'm not sure why though you would be getting excessive delays as you claim. They may sometimes have excesses loads on their servers. I have not tested this lately, sorry but at the moment I don't have time. I would suggest you ask if anyone else is experiencing this issue of maybe contact Australia Post. cheers
  3. @milkman45 I don't know where you're getting that ip 52.222.138.160 from. When I ping the Australia Post api server "digitalapi.auspost.com.au" (from inside the file apdomexp.php, shown in you log above) I get this ip 54.230.242.74. "digitalapi.auspost.com.au" is the only connection used by the module to the Australia Post api server to retrieve the postage rates: $api_server = 'https://digitalapi.auspost.com.au'. If you look at the attached screen images (which are ip lookups) you'll see that 52.222.138.160 points to some server in India. 54.230.242.74 (the correct one) points to the server in Melbourne. There is also a trace route (the black screen shot) also confirming this. Check that you haven't been hacked.
  4. @radhavallabh Hi, sorry for late reply, currently travelling. Thanks for the fix. The cookie script file has been taken out of the latest osC BS/CE version. Another simple fix would be to put the cookie js file back. Will update in next release of this add-on. cheers
  5. @inra311 You might need to apply the fix by Moxamint at the top of the previous page. cheers
  6. I've had a look at your site and I see what you mean. The problem is with the colours of your theme. The add-on just uses the colours from your theme by default, to match your theme. I haven't incorporated a means to easily switch colours. But if you want to have a play try this file: "ext\typeahead\css\ht-twitter-typeahead.css" (you need to have knowledge of css files). Sorry but I won't be helping you with that. Make sure you have a backup copy of original. cheers
  7. @inra311 It seems that the cookie.js file (which this add-on needs) has been removed from the latest 2.3.4.1 CE version, not sure why. The installation routine never checked for this file as it assumed it was always there. It only checked for the files that were being uploaded for this add-on. I have attached a zipped copy of the file. Download and extract it to "ext/jquery" folder on your server. See if that fixes your problem. Hopefully nothing else has been changed in the latest 2.3.4.1 CE version to break add-ons. cheers cookie.zip
  8. @inra311 Have you got a link to your site so that I can see what the problem is. You can check the link to my test site in my post further above to see a working version. cheers
  9. @Streamcode Installed latest osC 2.3.4.1 BS EDGE version here: https://www.auzcommerce.com.au/osc234bs_edge/. Still wasn't able to replicate your issue. I'm not aware of anyone else having this problem. You need to check or get help with your "SSL/session/cookie" configuration since your "osCsid" in the URL should disappear from the URL after first click on your site. Do this first and see if it rectifies the issue. Here is another site that you can see where this add-on works fine without emptying the cart: https://www.grandpas.co.nz cheers
  10. @Streamcode Hi, wasn't able to replicate the problem here on demo site https://www.auzcommerce.com.au/, but demo site is not latest BS version, slightly older. Will have to update to latest and test again when I get a chance. But it's looks light it could be a session/cookie issue. Will let you know results when completed test. Why is your osCsid always appearing in your URL? Check your admin settings. cheers
  11. Hi Rainer @raiwa Glad you got it sorted out. Appreciate your efforts as many others would also. Sorry that I misunderstood that you referred to older modules. Just to confirm that this applies to other older Australia Post shipping modules, not this contribution since the code above does not exist. But this contribution is still to be tested on PHP7, and not recommended for osC BS version. cheers
  12. Hi @raiwa This shipping contribution was created to run on non-BS versions. I'm pretty sure I worked on this before the BS version started to become mainstream and never got around to creating a BS version. There are a lot of code changes that are required to install this module so it needs a complete rethink to code it up to BS "no core changes" policy. The core changes are mainly to do with the way the shipping quotes are displayed in "checkout shipping" i.e. there are multiple shipping quotes for a given shipping option. And also a lot of the copy/paste replace code is using tables and cells as opposed to divs. I don't know what could be causing the error you mention with international shipping other than to say that this contribution is in-compatible with the BS version as already mentioned. As far as I know it all works OK on the non-BS versions. At the moment I don't have a lot of time to look at this, but if I get a chance I will. The modules are very complex and I would need to study the code again because it's been a while :). But going by the error " Please enter a valid Service code" suggests that the service codes aren't being sent to the Auspost server correctly. Something do to with the way the data (that is to be sent) is being handled and compiled initially. cheers
  13. @SuperPower09 Quick test on 2.3.4 std version also seems OK on dev site here: http://www.auzcommerce.com.au/osc234/catalog/index.php Same as before: use "mg4" for test. cheers
  14. @SuperPower09 Hi, I wasn't able to replicate the issue. See test here: https://www.auzcommerce.com.au/index.php. Search for model "mg4" (for a test I changed the model number for the product "Matrox G400 32MB" from "MG400-32MB" to "MG4". Is this what you are referring to? It seems to work on test site. Have you made any changes that my affect the search? cheers
×
×
  • Create New...