musicmaster

I am now running the 3.3.1 version of Mollie with Thirty Bees 1.4.0 (compiled for PHP 7.4) and PHP 8.1. It works but I am stuck. Upgrading Thirty Bees will crash my Mollie module. And newer versions of the module don't make a difference. Are there any plans for an upgrade?

You can use my free tool for that https://www.prestashop.com/forums/topic/445453-copy-shopdata-script-for-upgrading-and-fixing-buggy-shops-by-copying-business-data-and-images/

If you find the Prestools mass edit functions time-consuming then you will need to build your own tools. But it is not even clear to me whether you are using mass edit.

Yes, I am using the native Paypal module. But two things puzzle me: - I have disabled the guest checkout. Yet this cart has no registered customer - the cart and the mail have the same time (2:27am). One would expect someone to expect at least five minutes before sending a mail that you didn't receive an order confirmation. Those things make me wonder: is something going wrong in the shop or is someone trying to get products for free?

This morning I received a mail from a customer that he had placed an order and paid but that he hadn't received confirmation. There was no order in the orders list and I couldn't find his name in the customers list either. Finally, when I looked at the carts I found something relevant: a recent cart with the product he had mentioned. But it was also puzzling. The cart contains the label "Non ordered" and has no customer name. Also puzzling is that the cart has exactly the same date/time as the mail that he sent me. What is going on here?

I am busy making my webshop fit for PHP 8.1 and Thirty Bees 1.5.1. Now when I run the shop in this new constellation I get an error 'Class "Mobile_Detect" not found' for my Whatsappchat module. The offending line is "$mobile = new Mobile_Detect();" It looks like this is a Thirty Bees problem. In the TB 1.4 version I see in /classes/Context.php "new Mobile_Detect();". In 1.5.1 this is "new MobileDetect();". So something was changed. However, making a similar change in my Whatsappchat module doesn't solve my problem. I still get a class not found error. Does anyone know the solution?

no, both Paypal

I did some investigations on this phenomena. I have a customer who made two orders. He provided his VAT number so his intra-EU tariff is zero. In his first order everything looks correct. However, for his second order the ps_order_detail table looks correct but the ps_order_detail_tax looks strange. The id_tax and unit_amount fields look as if tax must be paid. However, the total_amount field is zero.

It appears there is an update of GMnumeric that solves the problem.

Solved. It was the GMnumeric module. That is a module that takes care that the reference number is the same as the order number. The problem was in the function validateOrder() in /classes/module/PaymentModule.php. The following code had become an eternal loop: do { $reference = Order::generateReference(); } while (Order::getByReference($reference)->count()); GMnumeric overrides generateReference(). Now it always returned the number of the last order. I don't know why this happened on one server but not on the other.

I have another - much smaller - shop running on the same account and it doesn't give problems. Most of the account is fast but some other pages are slow too. I booked some improvement in speed by truncating the ps_log table. But the total block in the validateOrder() function puzzles me.

DMarc is for mass mailing. Not relevant here.

I have changed nothing in the browser settings. I am amazed to see that https://privacyscanner.aesirx.io/ tells me that I am placing Google Analytics cookies without asking.

The above was in Chrome. In Firefox there is a timeout too, but this time I get a message that the secure connection failed.

I have a problem receiving orders. I made a test order with payment by bankwire. When I click to confirm my order the page keeps hanging (you keep seeing the busy pointer) and finally times out. When I open my browser console I see many times "Third party cookie will be blocked. Learn more in the issues tab.". Unfortunately the issues tab isn't very informative (see below). I am running a version of TB 1.4. Customers complain that they place an order and get a confirmation of the payment but not of the order itself. Strangely enough they mention the id_cart number as order number. This started happening after the move to another server (both PHP 8.1). Most orders do not become visible in the orders list in the back office. What is happening here? I would be happy to disable third party cookies, but I don't know which modules place them.

I see now that I should be under Modules to make this setting.

I have finally started to make moves in the direction to an upgrade towards 1.5. Things first went wrong when I updated the modules and got a 500 error. Enabling debug mode didn't work. I next downloaded the file in the logs directory and saw that there was something wrong (unexpected 'Settings') with the collectlogs module. I deleted this module and then could finish this step. Next I went to Coreupdater. That gave a message that I was using PHP version 7.3 that was not compatible with the newest TB version. So I upgraded my PHP to 8.1. However, the Coreupdater page kept showing that I had version 7.3. Emptying the cache didn't help. I went to the Advanced Parameters->Configuration Information page. That showed 7.3 too. However, after a page refresh it showed 8.1. However, when I went back to Coreupdater it still showed 7.3. Only a considerable time later this message disappeared. What still keeps puzzling me is that I don't see a choice between stable and bleeding edge. Has that disappeared?

The reason for forking Thirty Bees was discontent with the way Prestashop was going with 1.7. And its promise was a continuation of the 1.6.1 line. Prestashop could get away with 1.7 because its huge market share guaranteed that module developers would provide all the necessary modules for the new version. Thirty Bees doesn't have that luxury. What I see now is that compatibility issues are treated as low priority. And in much of the new development maintaining compatibility seems low priority too. It gives me the impression that Thirty Bees is becoming a hobby project of a few people who are developing custom modules for their own or their customer's shops. Yes, it was possible in 1.6 and I encountered a module that did have a capital in its name. In TB you could install it but then it was invisible in the backoffice. Whether it was intended is rather irrelevant. It is the PS 1.6.1 ecosystem as it exists that TB needs to maintain compatibility with. Yes, you can work around many bugs once you know them. But often you will have wasted hours or even days to pinpoint them. And maybe the worst part is that it detracts your attention from the rest of the upgrade - what can lead to problems elsewhere. In this case I ended up creating an override that disables the TB code that causes this problem. As this is not a module that I created I consider it rather tricky to rename it. Not to mention the complications that could arise when the shop owner might at some day upgrade the module.

No, I am not a module dev. And your attitude is exactly the kind of attitude that makes me giving up on Thirty Bees. You look at it from the point of view of a module developer. And from that point of view uppercase module names are irrelevant. My point of view is that of someone who helps people migrate from older Prestashop versions towards TB. And it is exactly things like these that cause most of the trouble. It is not just uppercase module names. There are dozens of such minor incompatibilities. And often they take many hours to solve because I have no idea where to look. It is a death by a thousand cuts. There are still many shops around using PS 1.6 or older. Thirty Bees could be an attractive option to them. But not as long as TB takes the position that everything that deviates from its strict interpretation of the PS 1.6 model can be ignored. People don't like to see their shop crash when they make the migration. They don't like it even less to be ridiculed by TB maintainers afterwards because their shop didn't adhere to some strict but arbitrary rules.

Examples: - new modules that store their configuration data under the /img directory and completely erase their /module directory with each update - the "recommendation" to delete the extra columns that have been added by modules to system tables - upgrades impose their indexation on the database - and crash when some module had changed that indexation so that the old key was no longer unique - as far as I know the bug that doesn't allow uppercase in module names still hasn't been solved

My preferences are in keeping compatibility with Prestashop 1.6. Unfortunately Thirty Bees is disappointing me in that respect.

Be careful what you wish for. I haven't checked the latest version, but in the past such suggestions including the deletion of fields that had been added by modules.

The previous release (1.32a) had some problems that made that it didn't always save texts in product-edit. I made a new release that corrects that: 1.32b. Please update when you downloaded 1.32a.

I had a problem with a non-latin language that the sender was completely encoded. It looked like: =?utf-8?Q?=D8=A2=D7=92=D7=9A=D7=9D_A2=D7=92= The most likely cause was mixed content/encoding. After I removed the underscore it displayed correctly.

I found one more problem. A fix has been uploaded.