Leaderboard

thirty bees 1.7 is here! 🐝 We’re excited to announce the release of thirty bees 1.7! This version brings a wide range of new features, powerful merchant tools, better performance insights, improved security, and a stronger foundation for the future of the platform. Better tools for merchants Managing your store is now easier with several new improvements: Session-based profiling Find performance bottlenecks without affecting your customers. You can enable profiling for your own session only, analyse real page performance, and optimise your store without turning on debug mode for everyone. Packs with combinations Product packs can now include combinations. Create more flexible bundles with specific sizes, colours, or variants exactly as your customers need them. Advanced list filters Back-office lists are more powerful than before. Create custom filters for orders, products, and customers to find what you need faster. Built-in credit system Issue store credit to customers and automate voucher generation while staying compliant with tax regulations. Official PayPal certified module thirty bees 1.7 includes a new official PayPal module using the latest PayPal APIs, providing a modern and future-proof payment solution. Smoother daily workflows Many improvements make everyday store management easier: PDF documents such as invoices can now be displayed directly in the browser. Create orders directly from abandoned guest carts. Attach files to customer service messages, such as invoices, manuals, photos, or return labels. Improved pack handling across the back office, orders, delivery slips, and dynamic pack synchronisation. More flexible back-office order creation, improved module warnings, better specific price management, custom export filenames, and clearer multistore order views. Better product and shipping management Products now support universal compliance attributes, including: HS codes Country of origin Age verification Dangerous goods information (UN number, hazard class, and packing group) These structured fields make it easier to manage shipping, customs, and invoicing requirements. Product combinations also received improvements: dimensions such as width, height, and depth can now change per combination. This allows carrier selection and shipping costs to be calculated more accurately for larger variants. Reliability, security, and future improvements thirty bees 1.7 introduces automatic database backups with configurable retention periods, helping protect your store and data. The platform also includes preparation work for PHP 8.4 compatibility, ensuring thirty bees continues to run on modern and secure server environments. For developers, version 1.7 adds new hooks and extension points, including improvements for payment options, webservice resources, delivery options, contact forms, custom KPIs, admin order buttons, and namespaced Object Model hooks. As always, this release also contains many smaller improvements, bug fixes, quality-of-life updates, and multiple security fixes. Thank you to the community ❤️ A huge thank you to everyone who contributed code, tested updates, reported bugs, and shared feedback. This release would not be possible without the thirty bees community. Update your store today and discover everything thirty bees 1.7 has to offer! 🐝

OK, thank you Smile for the answer, that makes sense. This release gives me the will to get a nice modern theme to work with. Could that be done natively for once, instead of a theme that drags a pile of modules along with it? A default theme should work on its own, that's also easier for you to maintain. I'd be really happy to see a Bootstrap 5 theme in TB, and I'm willing to do the work. I did one a few years ago (Cisero), so I know where the landmines are. It would ship alongside Niara rather than replace it, so nothing breaks for existing shops, and with no build chain at all, plain CSS and variables, so anyone can edit it. Happy to talk about it whenever you have time.

My idea is to split the RMA process into a tree They choose reason for the RMA: - Exchange. - Warranty claim. If they choose Exchange, they are presented with an option to choose another combination from the same product. If they are at the same price- perfect - the customer sees guidance on how and where to return the item and how/when they will receive the exchange. If the combination they choose is cheaper they are presented with an option to receive store credit or get a refund after the process is completed. If they end up with the first option, we're using the new credit system. If they choose a combination that is more expensive, we might generate them a virtual product, add it to new cart for them and escort them to the checkout after they complete their RMA request. The virtual product should be limited to this customer and hiden from the normal catalog. Product name Price difference – RMA #000184 Short description: Price difference for exchange associated with RMA #000184. Original item: hmlCORE XK Jersey Size M Replacement: hmlCORE XK Jersey Size XL Returned-item credit: €31.95 Replacement value: €36.95 Amount payable: €5.00 Original order: #001284 That way they can use any payment method we offer, even COD which can be attached to the replacement product we ship to them. We only ship the replacement when they have returned the original product and paid the difference (if use of prepayment method like card/bank wire is selected). Same for choosing an entirely different product in the other branch - we can display a normal search field, where they can find all products by name/ref number, select combinations if present and proced with the flow in the same way - same value - perfect, replacement is cheaper - choose store credit or refund, replacement is more expensive - generate the virtual product and make them check it out. For warranty claims, we can have a configurable form where they select a predefined issue (delivered broken, broken after usage, defective part, etc), they might be asked to describe the issue in writing, and of course to upload mandatory images so we can inspect the defect. Then after we process the request in BO the customer receives a special RMA contact email with instructions how we proceed with it. We can even expose hooks so external shipment modules like the one Codex generated for me for our local courier can generate a return label and send it out with the email. In general, the idea of a custom module doing this is good but i think that RMA process should be part of the core as every shop is mandated to have this process in one way or another. We simply have to modernize and optimize it so the customers find it easy to use and detailed enough so they don't think they are left in the deep and have to email or phone us. If the form is descriptive enough and acts more like a wizard with 2-3-4 steps, I think the user will gladly use the RMA flow more and leave the emails as a last resort.

Hallo @Bird der Aufwand ist sehr unterschiedlich. Für das Gewährleistungslabel ist es relativ einfach (das ist das Label das man immer anzeigen muss und auch im stationären Handel aushängt). Für das Garantielabel (das ist auch technisch was ganz anderes als das Gewährleistungslabe), ist es schon deutlich aufwändiger es gut im Shop umzusetzen. >> Wir dürfen die Anforderungen und Technik dahinter keinesfalls vermischen 😝 - das passiert aber leider sehr häufig wenn man online unterwegs ist. (ist dir das soeben auch passiert? )

It's broken as in "We can't guarantee that the page will always display the correct data", not as in "it's not working". It does work, but the cache invalidation is wonky. For a lot of stores (that don't care about the data displayed to be 100% up-to-date) it's still a good option to have a blazing fast shop. Although, I believe with server-side cache for smarty enabled, the difference in speed is not significant enough. So maybe we should finally rip this out

The upgrade to this new version from TB 1.6 was so easy ! Thank you for your hard work!

Any news on a Mollie update? Wero is now actively being pushed.

Great news! Thank you for your hard work!

I’m not using the Warehouse theme, but something else. I’ve started a new thread for a module that should work with any theme.

If you use Warehouse it's breadcrumbs.tpl emits schema. If you use the JSON module (which is complete; very few items are to be improved/added to it), you will have 2 fields for breadcrumbs. Which is not correct but is not problematic; I ran my shop until recently that way and only noticed and removed the schema from the tpl last month. The discovered rich snippets in Webmaster Tools started dropping and normalized to the correct level (from double the amount previously). I recommend using the JSON module as it offers other data for the whole shop too.

Yes, we have decided to deprecate the old paypal module. We thought about creating a new major version of paypal module, but decided to go with a brand-new module, so if any one of you guys wanted to keep using the old one, you could. The new module will be released shortly. It's based on latest paypal API. At the beginning it will not contain as many features as the old one, it just focuses on accepting payments reliably. In the future, we will implement other features like refunds etc, if there is a demand for it. Feel free to use old version of the module for now. Just know that it's been officially deprecated, and we will not invest any time into it.

Maybe it would be interesting to create a special forum topic where people can share their with ai created modules if they want to

Yes, this library introduced backwards incompatible changes. Version 2.8 used Mobile_Detect in global namespace. Since version 3.x, the classname was moved to \Detection\MobileDetect Old version 2.8 do not work on php7.1 and newer, so we had to update it You have to fix the module code that depends on old version of library. In fact, you should rewrite the module to use Context::getDevice / Context::isMobile / Context::isTablet