Jump to content
thirty bees forum

musicmaster

Trusted Members
  • Posts

    691
  • Joined

  • Last visited

  • Days Won

    47

Posts posted by musicmaster

  1. 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.

     

    • Thanks 1
  2. 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.

     

  3. 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.

    quirk.thumb.jpg.9e170ec380cc6161fb4f3e83e764a8e5.jpg

     

  4. 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?

     

    • Like 1
  5. 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.

    • Thanks 1
  6. 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. 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

  8. 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.

    • Like 1
  9. 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:

    address2.jpg.87aebeef60b4238bc90e04de1e2e1394.jpg

    What is going wrong here. And what can I do to have a custom validation?

  10. 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 padl
    ock 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.

     

×
×
  • Create New...