Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.


  • Content Count

  • Joined

  • Last visited

  • Days Won


Traumflug last won the day on January 2

Traumflug had the most liked content!

Community Reputation

807 Excellent


About Traumflug

  • Rank
    Markus Hitter

Recent Profile Visitors

3,887 profile views
  1. Not really. The problem with PHP8 is that PHP introduced a class 'Attribute' as part of the language/library. PS/tb/ME use a class of the same name for product attributes, which results in a conflict. Renaming the class wouldn't be that hard, of course. But it breaks all modules dealing with product attributes, they'd have to rename the class as well. Not easy with the plethora of widely used modules pretty much abandoned by their developer. Currently I have no idea on how to deal with this in a backwards compatible way. Ideally one could simply unload/ignore the PHP class. Not sure whether this is possible.
  2. As the error reads, it's non-fatal. As it's indeed just a build of thirty bees, just like @datakick said, it also attempts to grab translations from thirty bees servers. As there is no 1.1.1 release at these servers, translations fall back to 1.1.0. Which gives about all translations needed for either version. Next steps include to get the Merchant's Edition server for translations up and running, so this irritating error goes away with v1.9.1. PHP8 not before v1.9.2, as there's a serious roadblock to be dealt with: https://github.com/thirtybees/thirtybees/issues/1265 AFAIK, this roadblock applies to all PrestaShop versions as well as all of its forks. Actually, just the first two commits of this list. The other 21 commits came in after the build.
  3. Major part of bugfixing is to check such assumptions. Are they actually true? One way of finding out is to add some debug code into the (assumed) triggered method. For example this: file_put_contents(_PS_CACHE_DIR_.'/debug', __METHOD__.' '.__LINE__."\n", FILE_APPEND); This line of code should create a file 'debug' in the cache directory on execution. If the file appears (or receives additional lines), the hook gets triggered; if not, it doesn't get triggered.
  4. Hello everybody Tired of waiting? You're certainly not alone. We read about hold backs after hold backs for months now, without any substance backing anything up. Even this latest post yesterday asks for yet another two months of waiting. No new code, but new paid plans, apparently giving up free forum support. One could even read it as if they're playing with the idea of going closed source. Seeing this, I could no longer hold back myself and did what thirty bees should have done a year ago already: I made a release from what's there. That's more than 400 bug fixing commits since the last release, certainly not too shabby. So say hello to Merchant's Edition 1.9.0 Technically it's a thirty bees release with a renamed installer package. It'll install as thirty bees 1.1.1. Merchants with an existing shop simply upgrade to the latest Bleeding Edge 1.1.x, that's the same. And remember: 1.1.x as of half a year ago isn't the same as 1.1.x of today. What's the plan? Well, there is no shortage of ideas, including: Rebranding, own translations & update server (obviously). A Core Updater supporting both Merchant's Edition and thirty bees, allowing to switch easily between them. Committing the dozens of bug fixes I already have on my plate. Support for PHP 8.0. Speed improvements. Simplifying back office without giving up the feature richness. There are so many 'features' which barely make sense, just confusing merchants and slowing down operations. Tidying it up will improve the back office experience tremendously. A patch system for third party modules. We all know there are many modules out there which leave room for improvement. Their authors are too lazy to update them, Merchant's Edition is not. A usable version of the freaking freaky full page cache. Ever tried to configure it for best performance? It's currently a mess, and can be done much, much better. Regular releases, like once a month. Of course! About Merchant's Edition: there's a working business model in place already. No need to beg for money. Merchant's Edition may come up with things like Crowdfunding for larger improvements. From my own experience, merchants will happily pay if they get a substantial reward for their money, like fixed bugs and working code. Let me take this opportunity to thank those who did so far, it has been much appreciated!
  5. There is a module Override Check by thirty bees, already listed in your back office. This explains overrides and allows to remove them. And don't forget to delete cache/class_index.php after editing/removing/adding overrides manually.
  6. Traumflug


    As Litespeed claims to be Apache compatible, it should work flawlessly. Be careful with caching, big can of worms. e-commerce page content is inevitably dynamic.
  7. P.S.: ganz ohne Cookies wird es jedoch auch in Zukunft nicht gehen. Für Login und Warenkorb braucht man einen. Das lässt sich jedoch DSGVO-konform ohne Cookie-Consent lösen, da technisch notwendig.
  8. Wenn jemand keine Cookies akzeptiert, kann man ihn derzeit nur rauswerfen. Cookies sind eine von diesen Geschichten, die noch auf eine Anpassung an die moderne Realität wartet. Die werden einfach grosszügig verwendet, auch wenn sie gar nicht notwendig sind. Ich sehe da z.B. ein Cookie für eine PHP Session, obwohl m.W. Sessions nur vom Installer verwendet werden.
  9. Essentially he wants a constant carrier price with tax included, while the tax rate changes according to the kind of products in the cart. To reproduce this, one needs products with distinct tax rate (e.g. German VAT with 7% and 19%) and one of each tax rate in the cart. Also, set the carrier to "no taxes". Third, install module AEUC and enable 'Proportionate tax for shipping and wrapping' there. The latter after setting the carrier to no taxes, because this AEUC setting happens to remove the tax selector on the carrier configuration page. This switch in AEUC sets configuration 'PS_ATCP_SHIPWRAP', which changes behavior in quite a number of places in core code. Current behavior is, carrier price is taken as without taxes, average tax rates of both products get applied on top. Which increases shipping costs seen by the customer. If one increases the number of products with the lower tax rate in the cart, shipping costs get reduced (less increased), due to the lower average tax rate. Increasing the number of products with the higher tax rate accordingly raises shipping costs. What @30knees expects is to adjust shipping costs without tax according to the calculated average tax rate. This way the customer would see a constant price, while the price recorded in core changes. Certainly possible in theory, but to my understanding all price calculations in core are based on a fixed price without tax, so one would have to overhaul half of core to allow price calculations in the opposite direction. Perhaps you have some luck and find some magic place to implement this without a dozen overrides 🙂
  10. It's IMHO quite unlikely that the next tb version breaks module compatibility. Which means, if you buy the module now, it'll most likely continue to work.
  11. Code discussed here isn't part of the AEUC module. The module just provides a switch to enable some code in core.
  12. Non-trivial. See https://github.com/thirtybees/thirtybees/issues/1265 PHP class 'Attribute' needs a rename to something like 'ProductAttribute', because 'Attribute' is a PHP internal class with PHP8. Which of course would break all modules dealing with such attributes.
  13. You're at least now considering the strategy I've brought into discussion in April already. Some people learn slowly.
  14. You have full access to the Github repository and the thirtybees.com server already. Writing code doesn't need a contract, you could do this right now. Which obviously means you plan to keep future additions closed source.
  • Create New...