Jump to content
thirty bees forum

musicmaster

Members
 View Profile  See their activity

  • Posts

    675

  • Joined

  • Last visited

  • Days Won

    43

 Content Type 

Posts posted by musicmaster

    'native' Mollie module coming?

    in English

    Posted

    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?

    Prestools - the free mass edit toolset

    in Modules

    Posted

    4 hours ago, Lukasz Flak said:

    I'm looking for solution to clean category pages tree with the fastest way.

    I've got old category tree so with seo agency decided to:

    - firstly, remove products from category that are not in the main tree (they come from older version of presta etc)

    - secondly, remove from page category description

    - thirdly, create page FAQ that will cover words from description

    - fouthly, set-up redirection 301 from old category pages to FAQ

    - lastly, delete old category pages.

     

    Can you advise my approch is ok?

    With prestatools I can edit and remove category from each page but its very time-consuming approach.

    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.

    Non ordered

    in English

    Posted

    49 minutes ago, 30knees said:

    I'm getting a couple of these via PayPal. Did your customer use PayPal and are you using our tb native module?

    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?

    Non ordered

    in English

    Posted

    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?

    nonordered3.jpg.088482daf130bde2ca68fe91c2c90ce7.jpg

     

     

    Mobile_detect problem

    in English

    Posted

    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?

    Wrong taxes for some intra-EU orders using Mollie - can others verify theirs? Also: Where does order_detail_tax get filled from?

    in English

    Posted

    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.

    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.

     

    • Thanks 1

    Order times out

    in English

    Posted

    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.

     

    Order times out

    in English

    Posted

    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

     

    Not compatible PHP version

    in Updating thirty bees

    Posted

    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

    New features, improvements or something else?

    in English

    Posted

    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

    New features, improvements or something else?

    in English

    Posted

    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.

    New features, improvements or something else?

    in English

    Posted

    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

×
×
  • Create New...