Jump to content
thirty bees forum

gl_ybit

Members
  • Posts

    9
  • Joined

  • Last visited

gl_ybit's Achievements

Newbie

Newbie (1/14)

  • Reacting Well Rare
  • First Post
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

5

Reputation

  1. I've searched unsuccessfully so far. Is there anywhere I can find the API Definition for the webservice? The plan is to integrate the shop with a third party ERP solution, and the third party would require the specifications.
  2. Thanks. I've checked it out a bit. The Cart->duplicate() method is used to copy the old cart, funnily enough there is code in there to copy the customizations and the customizations themselves are even added to the database, but not the customization_data... this is weird. Edit: I opened a Github issue: https://github.com/thirtybees/thirtybees/issues/1131
  3. The main thing to keep in mind when using headings is the hierarchy. As long as no h3 is semantically above a h2, you are free to use multiples. Google likes a singular h1 to fill its search results and thus punishes pages with multiple visible h1 tags, that is all.
  4. I have a problem with a Product Customization. It works fine for the Order itself, but when the Order (or rather the Cart) is copied for a Reorder from the Customers orders history, the Customization is lost. I cannot see the customized text field in the Order overview and thus cannot know how the customer wanted the original product customized, I only see the base product. Does anyone know a trick, tweak or override that can help me out?
  5. @oliiiix Have you tried to set your rounding rule to "per article" instead of "per line"? If it is set to per line, it will round each position after adding the amounts per article, that is useful for shops selling, for example, ropes in feet or something. If you only set articles by piece instead of per foot or per lbs, then you should set the rounding rule to "per article".
  6. This is caused by the CartCore class' getProducts. There is a switch-case over Configuration::get('PS_ROUND_TYPE') which in the default case calls the Tools::ps_round function. The second parameter is _TBPRICEDATABASEPRECISION_ which is in the config set to 6 on default installation. It should use _PSPRICEDISPLAYPRECISION_ or _PSPRICECOMPUTE_PRECISION_ which are both set from (int) Configuration::get('PS_PRICE_DISPLAY_PRECISION'). Until there is a fix, you could use an override for the CartCore class which puts _PSPRICECOMPUTEPRECISION_ instead of _TBPRICEDATABASEPRECISION_ in that spot. Not pretty, but at least it'll work.
  7. @dosbiner Thank you. I have searched the forum for such a bug, but not the git.
  8. I have a fresh 1.0.5 installation. There are two carriers configured in the demo data. Carrier1 is set as default. When I go through an order and pick Carrier2 for delivery, the following overview page still assumes Carrier1 including the fee of Carrier1. I have tried to change the order of carriers and switched defaults to Carrier2 (in which case Carrier2 is assumed even if I pick Carrier1). I looked into the networking and there is an ajax request previous to the html request. The Ajax requests the controller order?rand and the method updateExtraCarrier. The response from that ajax-request is {"content":""}. The following html-request has a parameter in the form data which reads processCarrier, but that parameter is empty. I am not sure whether this is a bug (that would be a substantial one) or whether I failed to configure something important. Has anyone an idea what is going on there?
×
×
  • Create New...