Traumflug

I fear a white background is pretty much hardcoded. That said, back in the times when tb didn't even exist, yet, I tweaked PS (1.6.something) to allow non-square images, which eliminated added background entirely. Images simply keep their aspect ratio: It was a full implementation, including theme and image manager support. However, I fear I lost this code. I uploaded it to forge.prestashop.com, but this entire tracker was closed, all issues were removed. And I can't find a local copy any longer. *sigh* Nevertheless I wrote this posting here to give a hint on a possible solution for your challenge.

Nah, it should just remove this install folder, rather than asking the user to do it. One of these many features which should have done years ago already, but were always postponed for something more urgent.

Is there a module named 'sconnect' installed, perhaps? Some modules do really funny things, e.g. place some googleable code on the product page to find users of the module which didn't pay (a quite common phenomenon).

If the MySQL server would be running, but no database created, the installer would offer to create this database. Accordingly it boils down to do what the installer says, make sure login credentials are correct. Looking at this very long password, it might be too long (not sure about the limit off the top of my head) or contain characters not allowed to be sent over HTTP.

This error message means code tries to read $variable['debug'], and fails. Where $variable means any variable name. Sounds much like you have some debugging code in this file. Unmodified, Dispatcher.php doesn't contain the word 'debug' anywhere and around line 650 is no code reading arrays. If re-uploading files and deleting cache/class_index.php doesn't help, please post line 640 to line 660 of this file here.

Better comment out with Smarty comment delimiters rather than HTML delimiters. Theses are {* and *}. HTML comments get interpreted and delivered to the browser. Smarty comments not, so it it improves performance a bit. P.S.: as one can see by the code coloring in your post, the HTML comment ends in line 7 already, because there's another HTML comment. This means invalid HTML. Another reason to use Smarty delimiters.

Sendmail is a Mail Transport Agent (MTA), more commonly known as 'Email-Server'. Other choices are Postfix or Qmail. It's true, Ubuntu doesn't come with a mail server by default while PHP's mail() requires a working email setup. Any functioning email setup should work, though.

Man kann sie auch angeschaltet lassen, das macht im Betrieb keinen Unterschied. Die Bereinigung von iFrames findet beim editieren der Texte statt, nicht wenn sie ausgeliefert werden. Sozusagen ein Schutz, dass man sich nicht selbst ein Loch ins Knie bohrt.

Gitter is no longer linked anywhere. No idea how people get there.

Backoffice -> Menu -> Preferences, oberstes Panel, 'Use HTMLPurifier Library'

It's safe to delete image types not needed. However, there might be modules using some of these with direct links. A developer would use something like 'grep -rn thickbox_default modules themes' to find these direct links. Links created with PHP methods (should be done everywhere) are safe. Another approach is to simply delete them and look whether the shop misses some images. One can also restore like-named image types by simply adding them. Yes. Also watch out for image folders with nothing but an index.php file inside. One can delete these as well. All kinds of images are stored there. One can delete them, they'll get recreated. I think so. Fairly easy to find out by simply trying. Look at image file creation dates. @zen wrote some "image laundry" code about a year ago, which does all such cleaning as a background task. But this didn't make it into the distribution, yet.

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.

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.

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.

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!

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.

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.

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.

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.

This, or simply not use APCu.

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 🙂

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.

Code discussed here isn't part of the AEUC module. The module just provides a switch to enable some code in core.

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.

You're at least now considering the strategy I've brought into discussion in April already. Some people learn slowly.