Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

datakick

Administrators
  • Content Count

    1,839
  • Joined

  • Last visited

  • Days Won

    205

Everything posted by datakick

  1. Nice work. I would just suggest you don't use check (70 == $idCarrier), because $idCarrier will change every time you save carrier in back office. It would be better to modify this check and base it on different information from $data, maybe carrier name or carrier reference id
  2. The reason for the delay was caused only by me only, and I apologise for it. The plan was for me to start working on thirtybees full time at the beginning of February. I used to work as an independent contractor for a big client in a bank industry, and I was contractually bound to deliver a lot of work for them. Since the team didn't meet the delivery timeline I was forced to work for them until the end of February. I officially ended that contract last Friday. So, finally, I'm free and able to work on this project 100%. Right now I'm working on initial release, it will be done by the end of this week, probably Thursday or Friday. And then there is a very big backlog of things waiting to be done.
  3. datakick

    Price update

    That is not a bug, it's expected and wanted behavior. Theme shows product unit price on product page. This price can be different for different combinations, it can be affected by quantity discounts, etc. Of course, you can edit theme, and change the behavior. In should be fairly easy modification of product.js file.
  4. datakick

    Price update

    You could achieve this by using combinations -- you could predefine combinations (1m^2, 5m^2), and each combination would have impact on price. Your customer would choose combination instead of quantity.
  5. You can modify the module, and save the information to the database, for example by using something like this: Configuration::updateGlobalValue('MY_CARRIER_DELAY', $webserviceResponse['delay']); And in override you can load this information back by calling $carrierDelay = Configuration::get('MY_CARRIER_DELAY'); $delay = [ 1 => $carrierDelay ]; Or something like that
  6. In general, you want to persist result of webservice call -- real delay value in override, read saved value You will probably also need to implement some cron job to periodically fetch delay value from webservice, unless the webservice is called on every page load of your checkout (which would be crazy performance bottlenect)
  7. I doubt it's performance reason. Many ad blockers actually block google fonts. Also, it's not very GDPR friendly.
  8. That's just not possible 😉 The code specifically tests if the customer is quest, and if it is then it redirects to product page (if guest reviews are allowed). You either did not edit it correctly, or your server caches old php content. Another explanation is that isGuest() method returns false for guests (maybe some override), but that would be bizarre
  9. Are you testing this with 'Guest' or 'Customer' account?
  10. There is a bug in the module. It will be fixed in the next version. Meanwhile, edit file /controllers/front/EmailAction.php and modify method reviewProduct to look like this: private function reviewProduct(RevwsEmail $email) { $email->markClicked(); $productId = (int)$this->getValueOrThrow('product-id'); $this->autoLogin($email->getCustomer()); if ($this->context->customer->isGuest()) { if ($this->module->getSettings()->allowGuestReviews()) { $this->openProductUrl($productId, true); } else { $this->openMyReviewsUrl($productId); } } else { $this->openMyReviewsUrl($productId); } }
  11. If you have modified the email template, then re-download the module and copy email template from there. I'll look into this
  12. Unfortunately yes, there are a lot of these gotchas. I totally agree that themes shouldn't really do any business logic, but they do, due to historical reasons. This is especially true on product page, when there is a lot of javascript that deals with price, discounts, specific prices, quantity discounts, etc... What I plan to do is to implement theme independent javascript layer (managed by core) that theme developers could (and should) use. Theme will just listen to events, such as 'price changed', and react accordingly -- update relevant DOM nodes, etc. When user make some UI interaction, theme will simply fire event such as 'attributed changed' or 'quantity changed'. Core layer will recalculate the underlaying product model, and then fire events to let theme knows what changed.
  13. 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.*
  14. 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
  15. 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)
  16. 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.
  17. 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
  18. 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.
  19. 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?
  20. 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; }
  21. 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.
  22. 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.
  23. @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.
×
×
  • Create New...