musicmaster

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.

I uploaded a new version of Prestools. Quite a lot of changes. @CassimMulti-feature should now work for Thirty Bees. You need to download both to download this version and the newest version of the paid-for software. @30knees"Proportionate tax for shipping and wrapping" should now work as in Thirty Bees. Other parts that had major revisions: - the repair part of integrity checks - the adding of images in product-edit - indexation The manual also got some updates. Don't forget to use ctrl-F5 on your PC after the update in order to reload ignoring the browser cache. Otherwise you might be running the new version with the old javascript file.

Probably a few weeks. There are also some other changes I am working on.

Once under Prestashop I built a custom validation routine for the address2 field of the customer registration form. It was quite simple: In classes/Address.php I gave address2 it own validation routine (in the original it uses isAddress: 'address1' => ['type' => self::TYPE_STRING, 'validate' => 'isAddress', 'required' => true, 'size' => 128], 'address2' => ['type' => self::TYPE_STRING, 'validate' => 'isAddress2', 'size' => 128],` address2() was then declared in classes/Validation.php. public static function isAddress2($address) { return empty($address) || preg_match(Tools::cleanNonUnicodeSupport('/^[^!<>?=+@{}_$%]+$/u'), $address); } However, this doesn't work with Thirty Bees. I get a javascript error as soon as I add some content in the address2 field. The strange thing is that it doesn't even make an ajax call. The error (in js/validate.js) I get looks so: What is going wrong here. And what can I do to have a custom validation?

Not yet

Your SSL problems are still there. https://librairiezbookstore.com works but https://www.librairiezbookstore.com gives an error. Also when I am on the checkout page (https://librairiezbookstore.com/en/quick-order) and I open the browser console I see several errors.

Something is wrong with your SSL. Test your site at https://www.whynopadlock.com/

Try pressing the "source code" button after the text has been rejected and look for any illegal characters incl html. In some rare cases modules might try to put illegal text in the field.

Some people report better results after first truncating the tb_search_index and tb_search_word tables and then running the re-indexation.

I assume that the new version solved your problem.

BTW: do you use the most recent Prestools version? This part of the code recently had quite a few changes.

Which program are you using? I don't recognize the page. This is not order-edit.php.

I noticed that a lot of VAT numbers that are rejected are not really bad. Instead they are not correctly formatted. - Many people enter use separators like a space or a dot. So "123 456 789" instead of "123456789". - The entry is case sensitive. Quite a few people enter lowercase where as far as I have seen always uppercase is required. - For some countries the country iso-code is part of the string. For others not. This goes often wrong. In some cases people don't notice the rejection and without noticing it pay the VAT. It would be good to have a popup when a VAT number is rejected. It would also be nice when the software provided automatic correction.

Yes, this is 1.3.