datakick

I have reproduced the problem. Good news is that the issue is limited to display on product page only - if you add the product to cart the final price is calculated correctly. Bad news is that the fix will require theme(s) modification. I guess any theme derived from default theme is affected. We will release fix for community and niara theme. If you use some third party theme, you will have to contact its developer and ask them to incorporate the fix as well. Or you can do it yourself, it won't probably be that complicated. *Rant: we really have to extract these core price calculations from theme layer to core somehow.*

I've just tested on my demo account, and indeed payment request button does not seems to be working. I'm sure it used to work, so this is probably some regression in the latest stripe module. I will create issue in github for this

Are you testing it on apple device with biometrics, using safari browser? Because the button will not display otherwise. For example, I don't see the button on my iPad using chrome, but it is displayed in safari. And on my mac the button doesn't show either (it does not have fingerprint biometrics)

Sure. These kind of issues are exactly the reason why everyone should have staging server (copy of production) to play with. You could update staging server to 1.1.x (matter of seconds) and you would be able to tell immediately whether it resolved the problem or not. And it would, I'm pretty sure.

Yeah, import works for me just fine: There must be some bug, modification, override, or whatnot in your system. Once again, I strongly recommend update to 1.1.x

Hard to tell what's wrong. It works for me fine. If you really don't have any core modifications, I suggest you update to latest bleeding edge - 1.1.x using core updater module. Then try again.

Nope, everything's all right

I have no problems importing the file. Do you have any modification to the tb? What version of tb are you using? Do you have any overrides for Product?

Carrier delay is stored in the database, it's not dynamic at the moment. I guess we could create new hook that would allow modification of carrier list returned from Cart::simulateCarriersOutput. At the moment, I suggest you to create override of this method, call the parent one and modify it's result. Something like this: public function simulateCarriersOutput(Country $defaultCountry = null, $flush = false) { $carriers = parent::simulateCarriersOutput(defaultCountry, flush); foreach ($carriers as $carrier) { if ($carrier['id_carrier'] === <myID>) { $carrier['delay'] = '<delay_from_webservice>'; } } return $carrier; }

Server logs can serve only a very limited use case when it comes to analytics. It can tell you how many page hits you get, and referring sites. That's all. That's not analytics. If this is all you want to know, then it's definitely more reliable source of truth than GA. But if you would like to know how people behaves on your site what does the sales funnel looks like identify pain points (where do people stop from order completion) attribute sales to referrals determine revenue of your campaigns (how much money did you earn by sending that latest email newsletter) etc then you really need to track your visitors. It doesn't have to be GA, you can use self-hosted solution (Matomo), but you need a tracker. Also note that tracker does not slow down your site at all. The only overhead is the <script> tag in your page, and that is just a few bytes. The rest is downloaded async, after the page is already displayed to visitor.

It's hard to tell, from your description it's not entirely clear what the problem is. Please describe how we can simulate this problem, ideally on vanilla thirtybees installation. What product should we create (price, tax, etc), and how to set up other part of the system to reproduce the issue.

@lesley / @Rhapsody I very much agree with the idea of core being aware of all the data. How / where exactly are the data stored is not really important. It could be implemented in different ways -- extending core tables, dynamically create new tables to join, or as wordpress does it. The hard part will be force module developers to adopt this new mindset. However, if done correctly, it could very much simplify and reduce module development time. Core would take care of installing and dropping db tables and columns (both during initial installation and during module updates). All data would be readilly available to all other components in the system, ie. in the theme or in the api. This is definitely a good thing to have. And I'm happy to let you know that it's on our long-term vision.

This enhancement is on the roadmap. The hard work was already done in PR https://github.com/thirtybees/thirtybees/issues/1083. This pull request needs to be cleaned up first, though. It works only partially, and there is a lot of duplicated code.

Also, there is webservice API you can use to export data, including order detail. Webservice does not support csv, but you can get your data in xml or json format. It would be nice if tb supported csv format via webservice. Let's put this to enhancement backlog.

This is not really a core feature, it's a theme functionality. It's up to theme designers to implement these kind of requests. Of course, we could implement this in community theme.

That's very much questionable. The primary function of webshop is to sell. Export / import functionality is a supporting functionality only. Most merchants never really need to export data from their store. There are few that need connector to third party systems (erp, accounting, etc), but not many have need for generic order export functionality. Thirtybees has some basic build in export option in the list. It does not give you details about ordered items, etc, but it's enough for most use cases. (for example to get data to excel for tax purposes). If you need more flexibility you really need to invest into some export module.

You can safely ignore this TLS warning, it's a red herring... the test is using service that is no longer available. You should download latest version of paypal module.

There is probably some javascript that detects mobile device, and then do some image shuffle magic. Obviously not correctly.

I agree this geocoding should be on opt-in basis. Especially since this probably breaks couple of GDPR rules. I have filed an issue to fix this: https://github.com/thirtybees/thirtybees/issues/1278 Since this is security issue, it will have priority

Well, it's a mystery. Everything seems to be setup correctly, exception 'Class 'ZipArchive' not found' should never be thrown. Since it is throws, welll... that suggests some bug in php itself, or in some of its modules. Good news is that it's not a thirtybees issue 🙂I know that does not help you much

depends on a used stack. For example with php-fpm different virtual servers can use different php.ini config files. I suggest you install phpinfo to both your servers, and compare settings.

Installed does not always mean enabled. Check your php settings, ideally using phpinfo()

This is filesystem permissions issue. Smarty cache directory is not writeable -- it is either owned by different user, or is read only. The easiest way to fix this is to delete content of cache/smarty/compile and cache/smarty/cache directories, and ensure that these directories are writeable and owned by user that is used by your web server

Is it tb 500 error page, or server error page? If it's TB, enable debug mode a copy error message here. If it's server error page then consult server error log. The reason will be there.