gl_ybit
-
Posts
9 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Posts posted by gl_ybit
-
-
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.
-
On 1/3/2020 at 10:26 PM, musicmaster said:
You might consider submitting an error report in Github.
Anyway, to help you a little further:
The file where this is handled is /controllers/front/ParentOrderController.php
The code handling it start with:
if (Tools::isSubmit('submitReorder') && $idOrder = (int) Tools::getValue('id_order'))
In the (older) version where I checked this it was at line 87.
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
- 1
-
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.
-
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?
-
@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".
- 1
-
This is caused by the CartCore class'
getProducts
. There is a switch-case overConfiguration::get('PS_ROUND_TYPE')
which in the default case calls theTools::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.
-
@dosbiner Thank you. I have searched the forum for such a bug, but not the git.
-
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?
API Definitions for the webservice
in English
Posted
Thank you very much!