Traumflug

This screenshot looks much like broken code. No matter what's up with password or cookies, the full login screen should appear. Time to look up whether all files are still there.

Why do you bring this up, then, like so many other do? Makes no sense. Constantly asking for the impossible is, ... well, I'll stop talking here.

That's pretty much on every page load. Even when visitors just look around, sections like "recently visited" changes on about every click. Don't believe it? How about a look from the opposite direction, an e-commerce solution for Hugo, a static(!) web page generator: https://snipcart.com/blog/hugo-tutorial-static-site-ecommerce Essentially they use their static pages just as a placeholder for a dynamic e-commerce solution just like PrestaShop/thirty bees/Merchant's Edition. Third, page caching can apply to the initial HTML page load, only. And that's less than a second on a decent hosting already, so there's simply nothing which could be taken away by caching. All other time spent until the loaded page is completed is for loading images, fonts and embedded stuff like Google Maps, Google Translate, whatever. Full Page Caching for e-commerce is a pipe dream which simply doesn't want to die.

Wieso denn als ZIP? Diese PrestaShop-Leute machen immer alles viel komplizierter als notwendig. Falls alle Stricke reissen, hier ist die config.xml von PrestaShop 1.6.1.20: config.xml

Probier's halt einfach aus. Die beste Anleitung nutzt ja nichts, wenn bei Dir das vergleichen zweier Textdateien unter "Bahnhof" läuft.

Bleeding Edge currently lists '1.0.x', 1.1.x', 1.2.x' and 'main'.

It's new to me that PS offers upgrading from 1.6 to 1.7 at all. Module 'autoupdater' allows upgrading up to 1.6.1.24, only, AFAIK. Given this, it doesn't work with tb either, of course.

"Einfach reinkopieren" geht nicht ganz. Die Themes sind zwar ähnlich, aber nicht gleich. Man muss also schon die Änderungen extrahieren und erneut anwenden. Was auch geht: das ganze PrestaShop Theme rein kopieren. Dann kann man es in Preferences -> Themes auswählen. Es gibt durchaus tb Shops, die so öffentlich laufen.

Ich rate mal: es geht um das Front Office* Theme. Das wird bei einer Migration gar nicht überschrieben, denn das Standard-Theme von PrestaShop nennt sich 'default-bootstrap', während die neueren Themes andere Namen haben. Nach der Migration hat man drei Themes nebeneinander. Das alte Theme funktioniert weiterhin. Die Bugfixes der letzten beiden Jahre fehlen in diesem Theme natürlich. * "Front Office" ist die übliche Bezeichnung für das, was ein Shop-Besucher sieht. Das andere ist "Back Office", der Bereich mit all den Einstellungen.

Reduce the height of your window a bit. There is a mode for low height windows, which kicks in at < 850px window height.

Unter die Arme greifen? Das kitzelt doch nur! ? Ansonsten ist die Sache relativ einfach: PrestaShop 1.6 und thirty bees und Merchant's Edition sind alle miteinander Theme- und Modul-kompatibel, so dass man migrieren kann, ohne die bisherige Arbeit zu verlieren. Vorsicht ist natürlich geboten, wenn man am offiziellen Code gebastelt hat. Solche Änderungen sollte man an eine sichere Stelle kopieren, damit man sie nach der Migration wieder einbringen kann. Die Migration ist recht einfach: Modul 'psonesixmigrator' installieren und los geht's. Ist in etwa so kompliziert wie ein Upgrade von PS 1.6.1.10 auf PS 1.6.1.12, dauer nur etwas länger. Das Backup im Modul schaltet man einfach ab, wenn es nicht funktioniert. Die Warnung bei der Installation klickt man auch weg, dieses Migrationsmodul ist natürlich kein offizielles PrestaShop-Modul. https://github.com/thirtybees/psonesixmigrator/releases/tag/2.1.0

One has to find out what 'the database' is. This is where looking into install() helps. If there's no longer any code touching this database table, the table can get removed, of course. It gets a bit more complicated with modules putting their stuff into the general configuration table. To clean this, one literally has to grep through the code for calls to Configuration::updateValue() and Configuration::updateGlobalValue() to find them. Such stuff is often not initialized in install(). No rules without exceptions: payment modules often create their own order status, like 'Waiting for Bitcoin payment'. Order states can be still in use after module uninstallation, so the safe way is to just mark such states with 'active' = false and 'deleted' = true.

Many many modules don't even try to uninstall properly, I fixed more than a dozen already. The probably only way to get this done right is to look into the install() method and undo everything done there. That said, core does a few things automatically: unregistering hooks and removing everything module related installed by core.

Glad to see there's finally a release. Competition is encouraging. It's about the same as 1.1.x as of two weeks ago. On a quick glance, two commits actually affecting code, a dozen commits affecting the build system and source code comments.

You'd be surprised how many modules try to reinvent the wheel and request such stuff them selfs. One really needs to grep (multi file search) all templates and style files to find them. Like 'grep -rn awesome.min'.

There is a public Slack channel for all, PrestaShop 1.6, thirty bees and Merchant's Edition:

Not a guide, but the task is fairly simple: Find the URL in your (S)CSS. Download the file behind this URL manually and place it somewhere on your server. Change the URL found earlier to point to the file on your own server. To verify, reload the page in your browser and watch which font files get downloaded. Extra challenge in case of fonts is, they are not one, but many files. Which means, one has to download all the files. Usually, formats .woff and .woff2 are sufficient, one can drop all others (.ttf, .svg, ...). Experts also tweak their CSS to embed used font glyphs, and only the used ones. This eliminates downloading FontAwesome altogether. Requires tools like PostCSS, post-url, NPM, ... well, for experts.

Actually, I enjoy hacking away on this software more than ever. Often deep into the night, because I somehow can't stop. BTW., it's not "my" Merchant's Edition, it's "ours". We just don't make a big issue about ownership, bureaucracy. Enjoying improving this software and enjoying life is much more fun. It gets a tiny bit better almost every day, this sums up.

I hope you don't expect me to answer this in public. To those into the matter, reasoning for creating Merchant's Edition is pretty obvious.

Merchant's Edition made a new release, version 1.9.1. To keep things short here, see the blog

To get the same behavior on a desktop, make the window less than 400px wide. That's not a solution, of course, but helps debugging. Clicking on the image to get a large view doesn't work either, at no window width. Is there a module 'easyzoom' ? I'd disable/uninstall it and try again.

Did you delete cache/class_index.php? One can always do this, it'll get rebuilt automatically.

Let me guess: you cloned this shop not by installing both, but by copying the shop directory on the command line. Doing it this way makes all copied files owned by the command line user. Which is usually a different one than the web server user. To make sure, look at the details of some files in either installation. That's 'ls -l' on the command line. To fix this, one can either fix ownership using 'sudo chown -R <server user> <shop directory>' or install the shop both times properly.

Useful steps in such a situation: back office -> Advanced Parameters -> Performance, enable 'Disable non thirty bees modules' and 'Disable all overrides'. If the problem persists, file a bug on Github. If it doesn't persist, it's a module bug. In case it's a module bug, turn the override switch back on and try again. If it appears then, it's a bug in an override coming with one of the modules. ... and so on, until the culprit is found.

Looks they want to tackle those merchants which raise the price for 5 minutes, just to proudly announce its reduction for the next 2 weeks.