All Activity

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.

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

Error log is saying Once enabled the homeslider module delivered the header image

1 st part is correct it works with index.php annexed. And mod_rewrite is active on the server.

@wakabayashi I would like to.... I wouldn't need to buy modules ;) but unfortunately no, you're wrong. I like to share good experiences when I have them and I've always had a great experience with PS... I don't think it's a crime to talk about them since they are excellent professionals... maybe they are your competitors, I don't know, if so I'm sorry, I apologize but I trust them and, I repeat, I don't think there's anything wrong with reporting good experiences.

Bro you are not a normal thirtybees user, you are a module seller 🤷‍♂️

So now you have domain.com/admin/index.php and domain.com/index.php - and this is working but with domain.com/ and domain.com/admin/ it is not working? Then you do not have mod_rewrite active on the server, and you can't use 'pretty URLs' or Friendly URL as it's known in BO.

I added the name files name: index.php, into the URL, Sorry if I was that unclear. Anyway the greyed not found issue is still present. 1.5 and 1.6 are displaying a similar behavior.

@Yabber Just look at the screenshots I posted to understand how the module I'm using works. The withdrawal function is so simple: just click the "orange button" in the order detail and confirm with a second click (red button in the confirm page). No form, no data entry, everything is automatic, exactly as required by the directive. I invite you to reread it again, perhaps with the assistance of one of the many feared German lawyers. Sorry to repeat myself, but in this post you're just continuing to create unnecessary confusion. P.S. I apologize for the quality of the images, but I'm not a graphic designer or a technician. I'm just a thirtybees user.

You should always have index.php in every folder. This is not a fix. Something is breaking the installer. Did you have a running install on this setup before?

I used now TB 1.5 and adding the index.php to the admin folders name did reveal the login page. With TB1.6 that did not work.

Both experiments came to the same end. Page not shown on, 1st Intend the clean download, uploaded to a folder and installing to a brand new database as 2 other DB where not found, or not good enough. Result: a greyed out filed with Admin page not found, Meaning instead of the admin login, a greyed out area saying page not found. Shop Url Page not found. Similar result. After deleting everything I tried a Softaculus approach, with the exact same results.

What do you mean by 'installed to a brand new database'? If you run the installer, it should always be in new db. Sounds like the installer choked somewhere and did not complete the install. Did you use Softaculus or a clean download from the site? Did you try the other option?

I just uploaded a recent download TB1.6. It only installed to a brand new DataBase not a renamed one or even an empty one. Upon install I get a page not found and no admin, Shop is the same picture. Shop is in German, no Demo Pictures, Php is se t to 8. I've disabled webservice no changes, Anyone has an idea?

Currently, the returns feature only works for orders with the statuses “Shipped” and “Delivered,” which makes sense, since it would be difficult for a customer to return products they haven't received. Therefore, adding the ability to cancel orders to the returns feature would require a major overhaul of that functionality.

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

Click on the x and then on the last entry on the new page that shows. This will mute the banner for 1 month.

great, care to share the location (s)?

3.8.3 - 03/24/2026 Fixed HTML content displayed as raw code in the front-office form (form text and confirmation message) Fixed hardcoded 'classic' theme fallback, now uses the configured theme Removed unused images and dead code

I don't know the regulation and I am not affected by it. But in general I agree with @Yabber how it should be handled. A clean/standardized process, that is triggred by a button. Afterwards I would check if the order involves multiple products. If yes, I would ask the customer, if he wants to cancel the whole order or only some products. A contact form might work as the oldfashioned solution, but imo it has only drawbacks (for merchant and customer). I would only disagree with @Yabber, that cancellation and refund are totally different things. From a coding perspective, they are pretty strongly related. In both processes you have questions like: Needs the current_state (order) be changed? Is there a money refund involved? Is the whole order involved or only some products? In both cases restock might be needed. So in short I would say, cancellation is a simple case of returns.

Let's keep the discussion polite.

@DRMasterChief Whether a customer sends an email via the contact form or through an email client, it’s always just sending emails with no integration with the store’s functionality. This doesn’t automate any operations in the store and requires labor-intensive handling by store staff. There are industries where the return rate reaches as high as 40%. At a company like Zalando, they have to process thousands of returns every day. So the number of canceled orders will also be enormous.

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.

@vir The module you're promoting includes the following description: “This module adds a withdrawal request button to the order detail page in the customer account.” So I assume that the customer must be logged in to submit a request to cancel an order. There isn't a demo of the module, so it's hard to say much more about how it works. I provided the WooCommerce and Shopware examples to show that in every e-commerce application, the customer must be logged in to manage their orders. Without logging in, the only option is to send emails to the store.