Traumflug

What's the point of this switch? It's hardly imaginable a merchant does not want SEO fields.

Guess: one of the products in the pack has zero quantity.

See https://duckduckgo.com/?q=prestashop+dual+price+display Remember, all PS 1.6 modules still work on thirty bees.

Yes, that's what I meant and how I understood the question. Glad to see you answered this as well, so @simon can pick what he actually needs.

It's a per-country setting, so one finds a switch to turn this label on and off on back office -> Localization -> Countries, then click on the country, then near the bottom. For displaying both prices one needs a module.

D'oh. Forgot the question about whether the old updater should get uninstalled. The answer is No. The old updater is still needed for updating not thirty bees core, but modules. Plan is to move code needed for updating modules back into core, so eventually the module becomes obsolete, but not for the time being.

Currently one can use both. After an update with the old updater, the new one would see everything is fine already and do (almost) nothing. Using the new updater first, the old one would refuse to do anything and just report 'your installation is up to date'. That said, forthcoming thirty bees releases are planned to get provided by the new updater, only. Less work for thirty bees developers, more reliability for merchants. I don't think anybody will miss the old one.

For the records, this is a common message for failed Ajax requests. Which usually means a problem on the PHP side, so one likely finds more help in the thirty bees or the Apache/PHP error logs. That said, Core Updater v1.0.0 chokes on large ( > ~60 MiB) files in the file system. They just have to exist. That's why a fixed version was just released, v1.0.1: https://github.com/thirtybees/coreupdater/releases/tag/1.0.1 P.S.: this version should also show up in the modules list in back office.

Do you have some huge files lying around? Yesterday It occurred to me that every file on disk gets loaded into RAM for a short moment. That's not a problem with thirty bees files, but if there's something like a 100 MiB log file, it exhausts RAM. Removing these huge files should help. It'll take a couple of days until I can fix this. If this still doesn't help, it's time to look up error logs. The one in log/ in the web root and the one for Apache/PHP-FPM.

Is it the latest version? https://github.com/thirtybees/coreupdater/releases/tag/1.0.0 One of these previews had some debug code inside.

Announcing this here, because this module doesn't appear in your back office automatically and bugs prohibiting migration from an entire group of PrestaShop versions were fixed. Fixed one general bug which could cause downloads without timeout, leading to unhandled script abortion. Fixed two bugs prohibiting migrations from PrestaShop 1.6.1.7 (and probably similar versions). Make it pass validatemodule.sh as far as expected. As always, find the download on the release page: https://github.com/thirtybees/psonesixmigrator/releases/tag/2.0.1

True. Installing tbupdater should mark all the native modules as in need of an update and doing these updates switches to the thirty bees version. Should work just fine. Well, except for modules on disk, but not installed, as uninstalled modules don't get checked for updates.

It's a supported module: https://store.thirtybees.com/shop-modules/payment/cheque These module directories with just translations inside get generated by the translations machinery. It unpacks all available translations rather than only the ones for existing modules. Not pretty, but also harmless.

Yes, Page Cache is a module known to be incompatible with thirty bees. The migration module even removes it automatically. When migrating a shop I usually make a naive speed test (just load the page a couple of times and jot down the loading time). After migration, so far all shops were faster after the migration and after turning on Smarty caching as well as CCC (both on back office -> Advanced Parameters -> Performance) than with Page Cache before. Having a full page cache sounds good in theory, but in practice it's pretty limited. There are many reasons why page requests are not entirely identical (different language, different currency, different country, ...) and in each case, caching doesn't speed up, but slow down page generation.

There's a module Override check, which lists all the overrides. With some luck, sorted by the module which installed each override. Find it in the list of modules in back office. Other than that there's not much choice than to go through all the PHP files in the overrides folder, to find hints on why they're there. One override = one PHP function. One removes an override by deleting the PHP function.

These empty Ajax responses (no text behind errorThrown) are hard to reproduce and thus, hard to fix. My guess is, they're a result of PHP timeouts. Does the shop work after the migration? Being thrown to the login page is expected, a migration invalidates cookies. Just log in, same username/password. If the version shown in the upper left corner reads thirty bees, the migration went fine.

If a module developer tries, he can find distinctions in the API, of course. Like by testing for features introduced by thirty bees. Or by testing for the _TB_VERSION_ constant in code. There's nothing thirty bees can do about it, short of going out of existence. That said, I agree with @datakick. Not supporting a platform (like in "we don't care") is one thing, intentionally breaking it (like adding code to prohibit it from working there) is another one. Only an investigation about what goes wrong with this module can shed light on this.

Not really. PS 1.7 did a few things right and if thirty bees needs something similar, it'll implement this in a similar fashion. No need to alienate module developers more than necessary. But that's about it. thirty bees simply has distinct goals. Like improving reliability and ease of use. Look at the upcoming GitUpdater, Lesley has something in the works, too.

D'oh. That's debug code and fits my local installation only. You can delete this line or wait a few days for the release. TODO list has become short: Find, report and uninstall known incompatible modules (which should solve the problem with statistics modules). Add a switch to ignore the community theme.

Glad to see this module works for others, too. Y'know, operating it as the developer, who knows every detail, is a different thing than handing it out to people just trying intuitively. Give me another day or two for getting this module ready for release. Over the recent days I tackled all the smaller details, like actually removing marked obsolete files, like backing up manually edited files, like reviewing update script execution to avoid this CORS problem, such stuff. Also a new thing is a class for requirement checks. Not much inside, yet, because requirements didn't change between 1.0.0 and 1.0.8. Still it should meet this suggestion of "adding requirements". Having it in the update module means that it's also there for older versions. Nah, instead of talking so much, here's another preview: gitupdater-2019-01-29.zip

Some databases like this syntax, others not. Before committing this query I tested it, of course. In my local DB it works. There is this Gitub issue with a (hopefully) better syntax: https://github.com/thirtybees/tbupdater/issues/15 Being knee-deep into the new Gut Updater (which solves this without SQL), I didn't come around to test this, yet.

Was ist denn da das Problem? Dass das Fenster beim letzten Schritt einfach weiss bleibt? Der Admin-Ordner wird auch beim ersten Zugriff umbenannt. Also bitte nochmal per FTP nachschauen, welchen Namen er bekommen hat und dann mit diesem Namen versuchen.

> The errors I got when I turned debugmode on were : You did clear the cache, didn't you?

One can only import language packages from translations.thirtybees.com. There's kind of a voodoo compilation step between the download from there and the download from Crowdin, done for every release. Also, not all thirty bees ISO codes match the codes on Crowdin.

6 hours ago, datakick said: Works very nice and fast. Congrats on this release! I tested it a bit, and here are my notes: 1. my locally modified files are correctly listed in Files to get changed, but are not marked as M (this worked when I updated from 1.0.8 to 1.0.x, but when not when downgrading back to 1.0.8) Uhm, it's not a release, yet 🙂 As you noticed, Bleeding Edge versions mess up the file comparison. To make functions like version_compare() work, Bleeding Edge versions set the shop version to something like 1.0.8-1.0.x, where the part before the dash is the version found in install-dev/install_version.php and the part behind the dash is the name of the Git branch. This doesn't get resolved backwards, yet. It's on the TODO list.