datakick

I'm running latest version of paypal module on my demo site and it works just fine for me. You can check yourself https://demo.getdatakick.com If it doesn't work on your site then there must be some interference there

This will be fixed in next major version

No. I originally wanted to implement this functionality into the datakick module, but I dropped the idea. I'm not sure how big of a market is there for such module.

@moaai Yeah, I know that this is the 'common presta' way to implement custom fields, unfortunately. I have seen this kind of recommendation in many posts on prestashop (and even on thirtybees) forum. But that doesn't make it right. Object model definition is a shared class property, not instance property. Constructor (or any other instance method) should not modify it. Redefining the whole property in product override is not an ideal. It can cause a lot of problems in case we change the model definition in core. But I believe it's a lesser of two evils. Regarding restoring the original code in initProcess method -- I (reluctantly) agree to do that. This code was removed probably because the object model is instantiated later (int processSave or processAdd method) anyway. But the instantiation is conditional -- i the object already exists, it will not be loaded again -- so it should not pose any performance issue. And it will make thirtybees codebase a little bit more compatible. I still don't like it because it feels like rewarding bad behavior 😉 The code will be in bleeding edge soon.

Yep. main branch represents future major release (1.3.0). All new features will be committed there. Updating to this branch will give chance to test you new functionality early on. you could also use 1.2.x branch. This is a bleeding edge for upcoming bugfix release 1.2.1. This branch will not contain any new feature work, only selected bug fixes

This is not a problem with tbupdater, this is some other issue with your server. Your thirtybees is probably using wrong version of GuzzleHttp library. This library is part of /vendor directory. First, check (using core updater) that this directory is properly synchronized. If it is, then there is probably some module that includes old version of GuzzleHttp library, and thirtybees is using this version instead of build-in version.

Yes, unfortunately that happens sometimes. There can be various reasons why this happens: Your customer might close the browser before the redirection is done they can have some browser 'security' plugin installed that prevented the final redirect if you use cloudflare (or similar) then they could have mark your visitor as an attacker and block the access to your site your server could have been overloaded and did not accept new connection at the time there could be error inside payment handler on your site etc... All you can do is look into the server logs (both server and thirtybees logs) to see if there was any error in the timeframe of the payment

Related discussion: https://github.com/thirtybees/thirtybees/issues/1157

Try to disable Auto Format on the currency:

You probably have some javascript error on your product page. Look into js console to find out more.

@moaai the cause of the problem is that you choose wrong way to extend object metadata. If I understand correctly, you modify static product metadata definition inside constructor. That's really not ok. Instantiating object should not have side effects. If you depends on product constructor to change metadata, then we have following problem: echo Product::productFieldExists('my_custom_field'); // prints false $product = new Product(); echo Product::productFieldExists('my_custom_field'); // prints true In other words, system is aware of the custom field only after constructor is called. And this is a big problem that can cause a lot of issues. As an example, consider following two code snippets. Because of the side effect of constructor, both would behave very differently, even though they are both perfectly valid: $fields = $this->getDefinedFields('product'); $product = new Product($id); for ($field: $fields) { $output->addOutputField($field, $product); } $product = new Product($id); for ($field: $this->getDefinedFields('product')) { $output->addOutputField($field, $product); } My recommendation is for you to change your code. Unfortunately there is no easy way to extend object model definition (it will be soon, it's on my todo list). Meanwhile, I recommend you use solution #2 - to redefine "definition" variable in the child class.

The check simply verifies that following conditions are met: return extension_loaded('bcmath') && function_exists('bcdiv'); So either bcmath extension is not loaded, or it does not expose bcdiv function. What PHP version are you using? What is the version of bcmath extension?

No problem at all. The actual update of the demo site(s) is trivial, thanks to core updater. The time consuming part is to figure out how to log in, how to manage the servers, etc. That's why some of the tasks take more time than it should. We also need to document all processes so we can do them much more faster next time. Or ideally automate them Anyway, both front and back servers have been updated now. Enjoy

look at the image id -- 3616, and then construct path /img/p/<d1>/<d2>/...../id.jpg, where <d1> is first digit, <d2> is second digit, etc... For example: /store/img/p/3/6/1/6/3616.jpg

Couple of thirtybees modules (paypal included) uses psr-0 autoload functionality, but with incorrect file structure. This was allowed in older version of composer (with warnings). Newer version of composers does not allow this, resulting in 500 error code. I have fixed the paypal module. Will have to go over other modules that uses composer autoload functionality and check if they work or not

As I outlined in other post, the plan is to have 2 major release a year. We believe that this is the frequency that most merchants will find a-ok. Too many releases can be a big headache -- most merchants don't want to update their store every month or so. It can be dangerous, etc... However, 6 months is a long time to wait for a fix of a serious bug to be released. Therefore, we will have couple of bugfix releases as well. These releases will have a very limited scope, containing only a few code changes that fixes these serious bugs. It will contain only fixes that we understand very well, and we are 100% sure that they don't break anything. This should make updating to these bugfix releases very safe and simple. On production servers, most merchants should keep their store updated to the latest bugfix release, for stability and security reasons. On testing servers, it would be amazing if you would run on bleeding edge, as it would give us an early feedback, bug reports, etc. We will release updated version of core update soon -- this new version will make the whole update process more straightforward and easier to understand.

Done, new version 3.2.0 has been released. You should see it in your back office https://github.com/thirtybees/advancedeucompliance/releases/tag/3.2.0

Your home category have probably enabled option "Display products from subcategories"

I'm very happy to announce that we have officially released thirtybees version 1.2.0. This version consists of a lot of enhancements and bug fixes that were implemented in the last (almost) 2 years, including stuff like: PHP 7.4 compatibility - this version is fully compatible with PHP 7.4 Object model audit - database and php model are now in sync. This fixes a lot of weird issues and problems Ability to auto migrate database during update - missing database tables and columns are automatically created by core updater Installation fixes - a lot of bugs were fixed in installation process. Installation should now run more smoother Bug fixes - many issues were solved and more... You can simply use core updater module to update to latest stable release. Or you can download installation package and install it on your test server. I will deploy this version to the official demo servers in upcoming days, so you will have an opportunity to test this version even without the need for installation.

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

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.

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.

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.

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

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)