

musicmaster
-
Posts
691 -
Joined
-
Last visited
-
Days Won
47
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Posts posted by musicmaster
-
-
14 hours ago, the.rampage.rado said:
You moved servers - look into that. Configuration of the new server, especially https settings on it as it says that the connection is not secure.
Also those messages in the console are coming from Chrome, not your site. They will ban all third-party cookies soon (https://developers.google.com/privacy-sandbox/3pcd) and your checkout does not care for tracking, etc cookies at this point.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.
-
2 hours ago, nickz said:
Maybe related:What mail is used for the sending?
As Google Microsoft and Yahoo are having new guidlines
https://www.darkreading.com/cybersecurity-operations/google-yahoo-push-dmarc-forcing-companies-to-catch-upDMarc is for mass mailing. Not relevant here.
-
30 minutes ago, 30knees said:
Can you adjust the settings in the browsers to be the most permissive to see which cookies are set?
Can you figure something out via a tool such as https://privacyscanner.aesirx.io/?
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.
-
-
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?
-
1
-
-
On 7/25/2023 at 11:35 AM, datakick said:
So yes, there are some (maybe lots of) backwards compatibility issues. Still, it's orders of magnitude less than what ps17 forced upon their user base.
The only way to not have backwards compatibility issues is to stop development.
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.
On 7/25/2023 at 11:32 AM, wakabayashi said:If this was possible at PS 1.6, then there is some point in your request. I am not totally sure, if it was and if it was intended...
On 7/25/2023 at 11:32 AM, wakabayashi said:But ok lets get productive. What is the problem in renaming them? I understand that this is no option for a merchant, but I am asking YOU as a DEV. Which modules are you actually talking about, cause in my years I have never seen one with capital letters...
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.
-
1
-
-
On 7/19/2023 at 9:24 PM, wakabayashi said:
Not worth the time 😅 Sorry, but if you are a module dev you have no reason to use uppercase. It's just not clever. Exactly as naming your module generic "paypal" is also not clever...
Luckily I read at the beginning of my coding "life" the book from Fabien Serny about prestashop (modules). He explained this very well... That's why all my modules have prefix "genzo_".
@musicmaster Are these really the main issues you have with tb and ecommerce in general? I mean then you are the luckiest dev/merchant around here.
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.
-
7 hours ago, the.rampage.rado said:
Few things had to be change in order to allow php8 compatibility and move the project forward. Other than that each and every PS1.6 module I tried this year (I'm using always the edge TB version) has no problems.
Of course some 'edge' cases like powerful modules that manipulate stock or other aspects will be affected but I believe if those are so important you might pay additional funds to fix them for TB.TB becomes better and better each day!
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.
-
1
-
-
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.
-
2
-
-
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.
-
1
-
-
19 hours ago, Cassim said:
Something your working on.?
Or do you have a date on when it will?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?
-
20 hours ago, Cassim said:
Do your newest version support adding/removing/updating the Multiple Features of TB ?
Not yet
-
On 3/26/2023 at 11:40 PM, movieseals said:
You probably caught it while it was renewing. Just checked and everything is fine: https://www.whynopadlock.com/results/b6467bb6-d31e-4837-9104-5dc0cc4ca4b6
The padlock is working even when there was cart issues.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.
-
16 hours ago, movieseals said:
OK. So how do I fix that? What might be causing it?
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.
-
On 3/22/2023 at 8:32 AM, musicmaster said:
BTW: do you use the most recent Prestools version? This part of the code recently had quite a few changes.
I assume that the new version solved your problem.
Order times out
in English
Posted
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.