Traumflug

Undo this commit and see customers deleting their orders 🙂 https://github.com/thirtybees/niara/commit/5991643b278f4f0343dc7e90957984013a6db98f

And yes, I hate to have to sound so disappointing here, being well aware this doesn't make me a hero. Hero will be the next guy coming along with a silver bullet promise, even if it breaks shops.

To add a technical datapoint: page caching of any kind can only cache the HTML part of the page, the initial page load. That's where all the PHP voodoo gets executed. All the stuff after that initial page load, CSS, JS, images, whatever, isn't subject to page caching, no matter how it's configured. And one can easily measure how long this initial page load takes. Instrument #1: use Curl on the command line. Like: time curl https://librairiezbookstore.com/ Instrument #2: browser's developer console. Open it, click on the 'Networking' tab, then reload the page. This generates a list of all the resources loaded, look at the very first one. It should report loading time. With both instruments I get between 540 milliseconds and 590 Milliseconds on librairiezbookstore.com. That's what one can gain. Very good setups take like 350 milliseconds, so even the best imaginable page caching could never improve page loading performance by more than 0.2 seconds. If one sees more improvements for the complete page load, it's the result of content no longer displaying.

Why don't you just believe technicians, then. Quite a number of merchants search for a silver bullet despite it was said many times such a bullet doesn't exist. The guidance you ask for is very clear: don't use full page cache. If you want faster page loading times, reduce modules and content. Uninstall modules, don't just disable them. thirty bees is very fast by default and can be customized heavily with keeping this performance. Good example is @wakabayashi's technically brilliant https://www.chesspoint.ch/

It can't. One cannot cache dynamic content. As people refuse to believe this, Full Page Cache was introduced, which is kind of a simplified template engine in parallel to the already existing one and moves responsibility for correctness from the engine to the user.

It does. Even if it didn't, thirty bee's updater compares distribution files with those on disk and reports differences. It also detects files on disk, but not in the distribution.

You don't talk about the most important topic: was it tested and found to work fine with thirty bees? This penguin in the lower left corner of images isn't exactly convincing.

The software stack part is pretty simple: a commodity LAMP stack is perfectly fine. LEMP (Nginx) as well, if one manages to replace the .htaccess files with Nginx's flavor of configuration.

Looking up one of the major players to get a basic idea about pricing is always a good idea, even when they don't necessarily have the best offering. https://www.hetzner.de/webhosting https://www.hetzner.de/managed-server As one can see, prices largely depend on the expected traffic. Hosting for € 2.-/month should do for a hobbyist site where page loading time doesn't matter much and one rarely expects more than one visitor at a time. The more visitors one expects and the more competitive response times should be, the more expensive it gets. Not an easy decision 🙂 Just one recommendation: if you have the choice, stay away from storage on magnetic disks (often named 'HDD'). Unless one wants to store terabytes of data, SATA SSD or, even better, NVMe SSD is state of the art.

Es gibt sicherlich Module, die Postleitzahlen adhoc überprüfen und ggf. ablehnen. Speichert man die Adresse, rufen die eine Datenbank mit allen existierenden Postleitzahlen auf, um die Postleitzahl auf ihre Echtheit zu prüfen. Keines der thirty-bees-Module macht das, doch vielleicht findet sich ja ein anderes Modul, das da in Frage kommen könnte. "Adressüberprüfung" oder sowas ähnliches. Das dann mal abschalten und nochmal probieren.

Viele Änderungen könnte man automatisch machen. Zum Beispiel die Anzahl der erlaubten Buchstaben in einem Datenbank-Feld erhöhen. Andere Änderungen können zu Datenverlust führen. Zum Beispiel die Verringerung der Anzahl der erlaubten Buchstaben. Das Modul kann zwischen diesen beiden Arten (noch) nicht unterscheiden.

This is a JavaScript issue. JavaScript is used for display during editing. After a round-trip to the server ('saving') everything is fine.

Off the top of my head, these steps are required to duplicate a module: Duplicate the module folder. Give the new folder a meaningful name. Inside that folder is the main PHP file, same name as the folder, plus .php suffix. Rename this to the new folder name. This main PHP file defines a class making up the module. In its constructor, a variable/property '$this->name', change that to the new name as well. Delete all files starting with 'config' and ending with '.php', they'll get recreated automatically. That said, duplication makes no sense for some modules. For example, modules defining a database table; the module copy would use the same database or require more substantial coding efforts.

Kind of funny that distinct cache settings for individual shops are allowed 🙂

Chances are good one imports this trouble by importing the old database. Starting from scratch with an old database doesn't make much sense. To clean an existing installation: Uninstall and delete all non-thirty-bees-modules, delete all overrides, which means, all files ending in .php in overrides/, except index.php, Use Core Updater to update the installation to have no obsolete and no modified files. To move from one domain to another, move/copy all files and move/copy the database. This should give a working back office. To move front office as well, adjust the domain URL in Preferences -> SEO & URLs, third panel from the top.

This printscreen also shows a way to work around the problem. Download these two ZIP files (first line on the printscreen) with some other means and place them where psonesixmigrator wants them (third line from the bottom). This might well give a better idea on why the download fails. Having done these downloads manually, psonesixmigrator should pick these already downloaded ZIPs up and finish the migration.

This would remove customers like me from your shop. I never give a valid phone number. "The Internet" can't abuse things it doesn't know.

"it failed" isn't exactly what one can work with. Which way did it fail, what were the error messages?

Perhaps because the module was installed at some time, then removed again. Many modules don't clean up properly on uninstallation.

Errors in Smarty compiled code doesn't mean Smarty is at fault. It means that code embedded in a template compiled by Smarty is buggy. The template needs fixing.

Firefox allows to ignore third party cookies for years already, and shops continue to work.

What's wrong with https://<your site>/en/manufacturers? Should work without any edit.

Get a better module. APIs can be fast, request results can get cached. Sorry, can't say something better.

A database query returning no results returns boolean 'false', not an empty array. This worked fine before PHP 7.2. Changing this line: if (count($subscribe_products > 0)) to this if ($subscribe_products) should do the trick.

Unless you're prepared to learn Git command line stuff, the best bet is to use Core Updater, the Bleeding Edge versions. Core Updater follows the repository on Github closely and gets updated automatically; each commit to the Github repository arrives there a couple of minutes later. It's designed behave this way and get used like this. This also means: version 1.1.x there as of today isn't the same as 1.1.x last week or next week.