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


Everything posted by Traumflug

  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.
  15. That's true. None of the modules provided by thirty bees are made for PS 1.7. Some happen to work on PS 1.6, which is more by chance than by intention. As @haylau said, this is thirty bees.
  16. Recently I wrote about embedding portal videos into product descriptions. Using videos from YouTube, Vimeo, etc. is certainly convenient, but they require user consent under EU legislation. The easy way to a smoother user experience for shop visitors is to store such videos locally. No third party server touched -> no GDPR issue. Embedding local videos is even easier, see this blog post: thirty bees and Videos, Part 2 Enjoy!
  17. Probably because PS was the newest version when this spec page was written.
  18. That said, the migration module is free and works just great. It replaces pretty much the entire PS installation and upgrades the database. No need to have two installations for upgrading.
  19. Invoice templates are Smarty templates, which are HTML with variables. You'd need an HTML editor. That said, there are quite a number of 'advanced invoice' modules for PS 1.6, which also work in tb.
  20. Yes, price without tax is the fixed price. Which means, a different tax rate gives a different customer price. That said, in EU legislation VAT gets always paid in the home country. If your shop is in Danmark, you always pay tax in Danmark, even when shipping to Cyprus. When shipping to outside the EU (U.S., Switzerland), you pay no tax at all (but customers have to pay import tax at their customs office). All this to my understanding how current tax legislation in the EU works, it's no authoritative legal advice.
  21. These actions rewrote .htaccess, so it's quite possible this fixed an issue.
  22. Traumflug

    Curl error

    The APT/dpkg package you want is 'php-curl', not 'curl'.
  23. Please right-click on this button and copy the link URL. Then paste it into here and also try this URL in a new tab. Does it show the same behavior? If this URL contains 'tab=AdminAddresses', replace 'tab' with 'controller'. Does it work then?
  • Create New...