datakick

I don't think that's an error. If you had advanced stock management enabled, and you selected that new products should use ASM, and your didn't associate your products with warehouses OR you didn't associate your warehouses with carriers than it makes sense that there were no carriers available. Thirty bees tried to find carrier that can deliver product from warehouse, and failed. That's not error, that's misconfiguration.

In most countries businesses are required by law to issue invoice, and it must usually contain address. Therefore, collecting billing address is a must even for virtual products. You can hide shipping address, of course.

Of course, looking forward to it

Actually, this is expected behaviour. If I have Product A: base price = 100, tax = 22, final price = 122 Product B: base price = 100, tax = 0, final price = 100 Shipping with Shipping Cost = 100, "Price includes tax" = NO enabled "Proportionate tax" Then if I have 1 of each in the cart, then shipping tax is 22% of 1/2 * 100 0% of 1/2 * 100 which is 11% ==> shipping price is 111 If I put 2 products A and 1 product B in the cart, then proportion is different. Product A now account for 2/3 of shipping price, and Product B for 1/3 of product price. Result tax is 22% of 2/3 * 100 0% of 1/3 * 100 Which in total is ~14.66% => shipping price is 114.66 If I put 1 product A and 2 product B, then the result is tax is composed of 22% of 1/3 * 100 0% of 2/3 * 100 which is total tax ~ 7.33% => shipping price is 107.33 The calculations are correct, it just isn't very user friendly. That's why the option "Price includes tax" = "Yes" exists, with that the final shipping price will be always 100, and base price without tax will change for each tax bracket.

Yeah, I can reproduce it as well. The same problem exists in 1.2.0, though, so it's not an injection. But I will look into it, hopefully the fix will be easy

New feature was just included in the bleeding edge. It should resolve this proportionate shipping tax issue. In carrier settings you can now specify if the shipping cost entered in the range table are with or without tax: By default this is set to 'No', for backwards compatibility. If you set this to Yes, and enable 'Proportionate tax for shipping and wrapping' then the system should work as expected. For example, I have set shipping cost to 100EUR including tax, and added two products with different tax rates to the cart. Result is following: @30knees I would like you to ask to test the solution, if you have some testing server. You can use core updater to update to bleeding edge - 'main' version.

If you know there is a bug, then please file github issue, so it won't get lost. It's quite easy to forget forum posts. When I read forum on mobile I don't create github issue immediately, and then forget about it 🙂

You know, you can create issues in github as well. https://github.com/thirtybees/thirtybees/issues/1308

FPC modules depends on overrides to hack into the core system. In this particular area, thirty bees core is very different compared to vanilla ps16, because of native FPC cache. This difference means that third party FPC overrides might not work. I'm not saying they don't

FPC don't know what is displayed on the page. For example, if you install my product comments module, reviews will be part of product page. When new review is submitted, new row is stored in database table. But thirty bees FPC (or any other caching module) don't know what that mean. Thirty bees have no idea on which pages this record is displayed -- in this case, it's a product detail page, category listing, home page, review list page, possibly blog posts, etc... All these pages will show outdated information (new review will not be there). The worst situation will be on product page itself, because the customer will not see the review he just submitted. He might thing that something went wrong, and submit it again. And again.... And all these duplicate reviews will be eventually displayed, once the cached version is flushed... This is just one example. There are hundreds of modules (and core features as well) that can be negatively impacted by FPC. You can try to mitigate this impact by setting FPC dynamic hooks, but... some problems will still happen. If your pages are mostly static, then go ahead, use FPC. If you use a lot of modules, I recommend not to use any FPC. You would shoot yourself to the foot. But yeah, FPC is working correctly. It is working as designed, although design is seriously flawed 🙂

Hi everyone, Elasticsearch module received some love lately. A lot of bugs were fixed. Module should now work on php7 version without issues, and ES versions 5.x, 6.x, 7.x should be supported. Before we release the module officially, I would like to ask community member to test it. You can download pre-release version here elasticsearch-v1.1.0-pre.zip For testing purposes you can start up elastic search in docker using command like this: docker run --rm -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" elasticsearch:7.11.2 Many thanks to @zen for his contribution. Most of this release is based on his work.

Update your store to latest version of tb install maxmindgeoip2 module. create account in maxmind download maxmind city database and extract it to /tools/geoip/ directory

Full page cache works, to some extent. Problem with this kind of caches is that... well they will never work reliably with thirtybees/prestashop system, because there is no way to detect when something changed and flush the cache. Which means that your store will, ultimately, display stale information. For many merchants this is acceptable. But you must be OK with stuff like your customer entering new product review, and then this review not being displayed for couple of hours you change product price, and it correctly changes on product page, but not in category listing ... Note that you would experience these issues with tb native FPC, and with any other similar solution. As I said, there is no way to notify caching layer to flush the cache when content changes. In my experience thirty bees is pretty fast, and you can usually work very well without FPC. If your server is slow, there is probably some reason behind that -- badly written module, bad server, etc.

Out of curiosity I have created a test product, with base price = 100. I set not tax for the product. I then set quantity discounts in the same way you did. My result: It looks like it works correctly.

@haylau From the information you provided I don't really understand what is wrong, or what expected values should look like. Plese provide more detailed information: product base price discount settings expected results actual result It would be best if you could reproduce the problem on vanilla installation of thirty bees, to ensure that the problem is not caused by some of your modules and/or overrides. Thank you

That's a good question 🙂 I guess it was the easiest solution at a time. I agree we should get rid of these third party service dependencies. I filed an enhancement request on github for this one to not forget it

You are right, making it not visible really break javascript. That's insane. Please file bug on gitub (although that will fix the issue in niara/community theme) You could try to fix it yourself. Edit file product.js, find function findSpecificPrice, and remove this: .not(':hidden'); This is second similar issue I've seen lately. We really need to implement some javascript data layer for themes, and not depend on data stored in dom.

Are you sure that hiding section using css blocks the functionality? That would be very strange. Try again addding 'hidden' class, or setting style display to none, on section with discount table

What functionality do you guys need from such sync module? Is it one way, or two way sync? Orders, catalog, mapping, price management,... ? If we coould put together scope, some dev (maybe me) could pick up the task.

Maybe you have found bug in bing engine 🙂

I looked in the source page and there is no link containing p=2?p=2 anywhere, so this doesn't seem to be related to build-in paging mechanism. Most likely there is some link somewhere in the web (not necessarily on your site) containing this bad url parameters. You need to look at your site and check everywhere if you could spot this link, and fix it. If the bad link is on third party website, well there is not much you can do. You could propose fix to FrontController that could gracefully solve this situation.

Yes, you shouldn't encounter any issues or problems Nope, core update does not touch third party modules at all

Oh, I found a bug in the server tooling. @ariom please try update now

What version of core updater do you use? I just tried it, and it works fine for me. In server logs I can see that your core updater module sends request to list content of revision 1.1.x, but that doesn't exists anymore. But your module evidently believes it does, which is strange. Maybe some caching issues -- try to delete file /cache/GitUpdateStorage.php and try again.

What languages do you have installed in your shop? What is the actual warning/error message?