Leaderboard

Hi everyone, hello @datakick, @Smile and @Acer My premium membership just expired, which felt like the right moment to pause and reflect on the current state of the project. I’ve been here since day one and truly appreciate everything achieved over the years. thirty bees has been a solid foundation for a long time, but I am seriously concerned about its future. Official commits on GitHub have become rare; while community PRs are still coming in, they often seem to go unnoticed. There is a lack of transparent communication regarding the roadmap. This leads me to a point where I have to ask: Is it still worth building on the thirty bees core, or is the project effectively dead as an open-source endeavor? Technical Hurdles and Workarounds In my daily work, legacy issues in the core are slowing me down significantly. Address handling is cluttered, and features like multishipping (used by maybe 5% of merchants) make the code unnecessarily complex and bug-prone. A prime example is the "splitting order" issue that hits me every few months—a bug known in the PrestaShop community for 15 years. To keep the system extendable, I’ve developed a "best practice" over the last few months using classes like OrderDetailExtension or ProductExtension that share the ID key to manage new columns. It works, but it’s a lot of overhead that only makes sense if maintaining backward compatibility with the core actually provides long-term value. If the project is stagnating, it would be more efficient for me to drop compatibility and modify core files directly. Waiting for Features Over a year ago, I had an intensive talk with Petr about a credit system for customers. Since I need exactly that, I waited—but I’m still standing here without a solution. In recent weeks, I haven't been able to reach Petr at all. While there was a recent sign of life on GitHub, it’s not enough for professional planning. I would love to see a Version 2.0 that modernizes the system radically: A rigorous code rewrite (even if it breaks old modules). Support only for currently supported PHP versions and updates for components like Smarty. A Backoffice designed around merchant needs, not just a collection of controllers. Clean Code as AI Foundation: clean, unambiguous codebase is essential today. If the core is logically structured, any AI can easily generate high-quality modules. If the base is "spaghetti," the AI will only produce more spaghetti code. Conclusion Is this vision of a Version 2.0 shared by the team, and is it something being actively worked towards? If not, that is perfectly fine. But then I have reached the point where I will likely move in this direction alone and radically decouple my own codebase from the core. Best Regards Emanuel

A connector to a newsletter service, a modified connector to LexOffice to send Amazon invoices to LexOffice, and a connector to the ShopVote API. But these are already for PS 8.2.

Hi, I understand your concerns. Generally, I still see great potential in Thirtybees. It's just perhaps not being fully realized. It's also difficult to break into such an environment. Either you have good programmers or you have good salespeople. It seems you don't have both, or, as is so often the case, the team fails. But I also understand your concerns, and of course, Thirtybees currently carries a lot of baggage at its core. We know where it comes from... and yes, to lead it into the future, a thorough overhaul would be necessary. But please, no symfony-style strategy 😞

Great notion +1 I guess there is little trust to accept more people, all needs to checked before going public. That is a clear sign that of bureaucracy is creeping in. When getting older we tend to find ways not to fall into action. How many people are candidates to become parts of the outer ring and how many are willing? @wakabayashi is a candidate.

Database, PREFIX_employee table, campaign_disabled field. Set the date 100 years in the future.

Let's keep the discussion polite.

Oh dear, good grief! There's no need to send an email to the shop using an email program. The regulation specifies a button that may link to a form. The form can be pre-filled or not; there are no further regulations regarding this. And yes, when the "confirm cancellation" button is clicked, the shop receives a notification in the background. The regulation, effective from June, simply aims to prevent customers from having to use an email program, a letter, a fax, or even a carrier pigeon. That's the basic idea. The customer simply fills out a form or checks a box, and then submits the declaration that they wish to cancel the order. Why is so much more being read into the regulation than it actually stipulates? Thanks @vir for your post before.

Thank you for doing this ... Enjoy your coffee ... Cheers

Any news on an updated Mollie module?

Hi! Are there any experienced Thiry bees developers here who can undertake paid work with upgrading to Thirybees from Prestasop 1.6.24?

Hi, it is clearly stated: The withdrawal function shall be continuously available throughout the withdrawal period. Even if the button is displayed after the withdrawal period has expired, this is not a legal problem. There is no reliable technical way to calculate the withdrawal period in the shop. It depends on many factors, such as partial deliveries or whatever period the retailer voluntarily grants. The details of a partial cancellation of a larger order are not addressed in the EU directive. Thank you for that 😞 If a reliable way can be found to link the withdrawal period to the withdrawal period, that's fine. Please do so. However, if there is only one instance of an incorrect withdrawal period, it is not good for the retailer. The permanently displayed button naturally carries the risk that it will be used even after the withdrawal period has expired. However, this is not a problem; the withdrawal is then invalid. The retailer will have to check this in any case and inform the customer, etc. Then he has to inform the customer that the cancellation was received after the deadline, but this is no different from before, or if a customer still cancels by email. Just expose your guest tracking controller with a link in the footer for all guests, and that should suffice. >> Yes, that's true, but guests and logged-in customers can use it, except that the login process is (possibly) displayed afterward. This could be seen as an additional hurdle by logged-in customers > not good. I'm not sure if it's clear what I mean by that point? With all this in mind, I have to say that we actually don't have any cancellations/returns. Maybe I'm oversimplifying things? We simply have to implement it; only one customer will use it per year. But please let us discuss here further!

I have been using the free versions of Google Gemini and Microsoft Co-Pilot and am somewhat impressed. Since I'm retired and just do some stuff as a hobby I don't do enough development work to justify paying for a plan. I prefer Gemini since it can "see" the tabs I'm working in. Sometimes it gets stuck in a circular loop that makes the same mistakes when I am trying to debug an issue or it breaks something the was working when it makes a change, and will make the same mistake more than once. In general it is much more efficient than I am. I used Co-pilot to help Gemini solve one of my circular loop debug efforts and it corrected Gemini on the first try. I feed that output back to Gemini and moved on further in my regression testing. I copy and paste between the AI and my source as it has no direct connection to the source. I gave Gemini a set of ground rules and frequently tell it to go back and redo complying with the rules, otherwise it starts changing stuff I did not want touched. Here are some rules I gave it to adhere to when generating or updating my code: The mandatory ground rules found in the testing document are as follows: 1. Preservation of Comments: Preserve any comments or annotations in the existing code. 2. No Unauthorized Optimization: Do not optimize or change any existing code. Suggestions can be made for acceptance or rejection. 3. Patch Formatting: When providing a patch, specify the line before and after the patch for easy location. Use /** START xyz Change **/ as the first line and /** END xyz Change **/ as the last line for inserted code. These may be removed during final cleanup. 4. Incremental Updates: Perform updates one function at a time and ask for permission to proceed to the next item to allow for testing. 5. Source Code Requests: Request the source for whatever is being updated if it was not already pasted. Use that source for the update unless instructed otherwise. 6. Debug Output Encapsulation: All debug output support, which may be done in a production environment, must be encapsulated using the cm_is_super_admin() function to isolate the display. An example provided is: PHP /** START DEBUG ENCAPSULATION **/ if (cm_is_super_admin()) { /*** DEBUG PLACEHOLDER BELOW ***/ echo "<br>". __LINE__ . " data:<pre>" . print_r(array_keys($data), true) . "</pre>"; //DEBUG /*** DEBUG PLACEHOLDER ABOVE ***/ } /** END DEBUG ENCAPSULATION **/

I miss possibility that if superior combination limiter is set then in lower impossible options are inactive. At the moment You can make all combinations and system gives to seller only message "This combination is not allowed" (or something similar).

I see that someone else has also struggling with combinations. I haven't found anything better. Just need to think what You put in combination choice. I'm using also CSV import, without this is very very hard to manage combinations.

I never worked with claude yet. It seems to be the best model. But right now I can use Codex 5.3 with no limits in phpstorm. I only pay the 20$ plan. Codex 5.3 is very strong as well. Maybe there are "political" reason to leave OpenAI but pricing and quality aren't an issue for me right now 😅

All the free AI offerings have a daily usage limit (or they even fake model versions.). Nothing is truly free if you're looking at cutting-edge models. However, http://poe.com/ offers some pretty good models for free.

This is the number of records in the database being sold, not the number of users. One user may have hundreds or thousands of records in the database.

Then the proper message you should communicate is: We need X amount of paying members to do Y. We have Z members. Or: We need X monthly income to do Y. We have Z monthly income. Don't just say: Become a member. Give people data, a funding goal, etc. You see that the calls to donate haven't been working amazingly. Try something new. And yes, it's hard work.

This is just hypothetical, right? Or do you have any powerful prestashop/thirtybees in mind? Cause my company is steadily growing and I am considering hiring a full time dev. If I can find a suitable person. He would ofc also contribute to the core.