datakick

@dynambee is correct. I can just add that this functionality still works correctly. As far as I can tell, there exists 3 restrictions for modules Disable on tablet / Disable on mobile / Disable on computer module preferences can be used to display modules on specific device types only Multistore restriction -- if you have multistore, you can enable module for specific shops only Customer group restriction - the one we are talking about All of these impact list of hooks that are being executed. You can also manually modify this hook list by removing specific hooks that you don't want to be displayed

edit history.tpl file and replace <a href="javascript:showOrder(1, {$order.id_order|intval}, '{$link->getPageLink('order-detail', true, NULL, "id_order={$order.id_order|intval}")|escape:'html':'UTF-8'}');"> with <a href="{$link->getPageLink('order-detail', true, NULL, "id_order={$order.id_order|intval}")|escape:'html':'UTF-8'}">

Reprosteps, please.

I did. In fact, I can't reproduce this problem on my 1.1.x at all. With or without your changes. That's why I speculate what's wrong. @RabbitZzZ said he installed TB 1.1.0 with demo data and tried to refund the first demo order. I did the same, and it worked fine. In order to investigate further, I need exact reprosteps.

You should verify that you have correctly defined constant _TB_PRICE_DATABASE_PRECISION_ in file defined.inc.php. It's possible that it's missing in your system --> php would probably consider missing value it as 0, resulting in the weird behavior you are describing. If the constant is defined and has value 6, it's not really possible for the the result to be rounded to full dollar/euro. This new rounding code ensures that result contains numbers like this: 39.999999 instead of 39.999999813893179847984789149816487163821357615

I fail to understand what your code fixes. I have downloaded your fix, and compared it to 1.1.x version. The only difference is in rounding -- the new version rounds values to _TB_PRICE_DATABASE_PRECISION_ (6 decimal points), whereas your version does not round at all. diff --git a/classes/tax/TaxCalculator.php b/classes/tax/TaxCalculator.php index 0b007c9330..be0a9b06c8 100644 --- a/classes/tax/TaxCalculator.php +++ b/classes/tax/TaxCalculator.php @@ -92,10 +92,7 @@ class TaxCalculatorCore */ public function addTaxes($priceTaxExcluded) { - return round( - $priceTaxExcluded * (1 + ($this->getTotalRate() / 100)), - _TB_PRICE_DATABASE_PRECISION_ - ); + return $priceTaxExcluded * (1 + ($this->getTotalRate() / 100)); } /** @@ -110,10 +107,7 @@ class TaxCalculatorCore */ public function removeTaxes($priceTaxIncluded) { - return round( - $priceTaxIncluded / (1 + $this->getTotalRate() / 100), - _TB_PRICE_DATABASE_PRECISION_ - ); + return $priceTaxIncluded / (1 + $this->getTotalRate() / 100); } /** @@ -176,16 +170,10 @@ class TaxCalculatorCore foreach ($this->taxes as $tax) { if ($this->computation_method == static::ONE_AFTER_ANOTHER_METHOD) { - $taxesAmounts[$tax->id] = round( - $priceTaxExcluded * (abs($tax->rate) / 100), - _TB_PRICE_DATABASE_PRECISION_ - ); + $taxesAmounts[$tax->id] = $priceTaxExcluded * (abs($tax->rate) / 100); $priceTaxExcluded = $priceTaxExcluded + $taxesAmounts[$tax->id]; } else { - $taxesAmounts[$tax->id] = round( - $priceTaxExcluded * (abs($tax->rate) / 100), - _TB_PRICE_DATABASE_PRECISION_ - ); + $taxesAmounts[$tax->id] = ($priceTaxExcluded * (abs($tax->rate) / 100)); } }

Such feature request should probably be implemented in thirtybees core. If this was implemented in chex only, then it could surprise customers, because the prices might be different than what's shown in cartblock. That's because cartblock could be using different country to calculate shipping / taxes / etc Right now, when you go to chex page, it will use the information saved in the context == the same info cartblock is using, so the prices are the same

I'm not sure if any module is needed for this. You just have to modify your template, and use product long description in both places. In the place where you want to display short description, you can use |truncate smarty modifier {$product->description|truncate:250:"..."}

I don't think Transaction IDs are used for anything by tb core, or paypal module. So from code perspective, it should be safe to change this to contain Transaction ID.

There is no such error -- this was only displayed because you clicked on the url and browser opened it using GET method. But module sends request using POST method, and correctly includes compareVersion parameters in the POST body

Not in this case. Core updater will end up in endless cycle trying to uninstall the same module over and over again, failing every time

Then do the manual upgrade

Disable debug mode, or upgrade thirtybees to 1.1.0. I've also filed an issue for this to be fixed within the module: https://github.com/thirtybees/advancedeucompliance/issues/10

Could you PM me access to your back office? I'll look into it

Core updater would tell you about them -- they would be listed after you compared versions If there are any improperly deleted modules, you are out of luck. There isn't any automated mechanism to fix that, unfortunately. You would have to manually delete them from PREFIX_module table (or modify core updater module to ignore them)

Thanks you all for your thoughts. I'd like to show you what I'm building here, and explain a little bit more my vision, regarding the theme page editor. What I did is I split the big template (like product.tpl) into many small blocks. Then I created a layout mechanism that allows to re-arrange these blocks as you like. There will be additional structures you can use, like section, tabs, columns etc where you can drop these blocks. Of course, dynamic blocks are supported as well (you can place any hook anywhere on the page) Here's a video. Note that this is work in progress, and very far from the final stage. So excuse the crude design 🙂 Is this something that your guys want / need, or is it completely useless? Any ideas?

I have recently helped someone with the very same issue. There were two problems that prevented migration: 1) core updater detected that incompatibile modules were installed. Unfortunately, these modules weren't really installed. They were simply deleted from /modules/ directory, but weren't uninstalled properly. Core updater tried to uninstall them automatically, but failed because they weren't found on disk. This is probably bug in core updater, and could be fixed 2) the update was run on php 7.3. Older version of thirtybees contains code that is not php 7.3 compatible, and this blocked upgrade. If anyone is running on php 7.3, it's important to use older php version to do the upgrade. Then, you can switch back to newer php 7.3. Again, this could be fixed -- that would require that core updater would bundle all it's dependencies, and would not depend on tb core files

You should upgrade to latest 1.1.0. That would actually solve this issue, as it contains new error handling code that does not emit notices or warnings to standard output Because you are experiencing so many issues, you should investigate what's wrong. Use core updater to detect modified files. Use Override check module to see what overrides you have installed. Use latest (unreleased) version of core updater 1.2.0 to find database differences, and possibly fix them, etc...

I've just tested it on my demo account and it works, as you can see here. My current settings: {hook h='displayRevwsReviewList' reviewStyle='item-with-product' allowPaging=true}

That's awesome, I'm happy the module works for you.

Db::getInstance() calls doesn't add any measurable overhead. Once the connection is established this method returns existing instance from static pool. Of course, it's possible to extract it to variable like this to save couple of micro/nano seconds per loop $conn = Db::getInstance(); do { ... } while ($conn->getValue($sql));

Imagine dice throwing. Every side (1..6) has the same probability -- uniform distribution. But if you throw 2 dice, then probability of multiplied number is different: total 1 -- probability 1/36 -- there is only one combination (1 * 1) that results in 1 total 2 -- probability 2/36 -- two combinations (1 * 2) and (2 * 1) total 4 -- probability 3/36 --- (1 * 4), (4 * 1), (2 * 2) total 7 -- probability 0 -- there is no combination that would result in 7 (or 11, 13, 17, 19, 23, 29, 31) As you can see, probability distribution changed significantly

I believe that product of two random number with uniform distribution results in a number that does not have uniform distribution, which means it leads to more collisions. In your case, mariadb rand() probably doesn't return number with uniform distribution, so product of two rand numbers might be useful. In my case, it's not (assuming php rand generates number with uniform distribution, as my quick test suggests)

For collision to happen, there would 1) have to be 2 php processes trying to insert new entry into the same table at the same time (or in the timespan of ~10ms) 2) and both php processes would have to generate the same random number Even the first condition is very unlikely to happen. But probability of both two condition to be met at the same time is effectively zero. You could run your store for thousands of years without this to ever happen.

Good job. I'm most interested in conversion of loyalty points on checkout. I'll test how it works with chex, but I assume it doesn't integrate