Traumflug

Impressive efforts. I wish I could get people into giving a migration to thirty bees at least a try. There one gets all this, and is safe for the coming future.

Yes, updating also upgrades the database.

@datakick probably means an update not to 1.0.8, but to Bleeding Edge / 1.0.x. That's currently pretty stable.

Like this one? https://store.thirtybees.com/

You mean this page https://store.thirtybees.com/shop-modules/administration/core-updater ? That's plain wrong 🙂 It also says "PHP 5.5", which is wrong as well; it requires at least PHP 5.6. One can find Core Updater in the module list in back office. There should be no such issues.

Here we go: https://github.com/thirtybees/thirtybees/commit/1818e2aca9b90dbee0553272e45956b275fda334

You mean forward slashes as part of the name? Yes, they were disallowed to avoid names like "cat /etc/passwd". Looks like there's another commit needed. Dealing with names is a tricky matter, see https://shinesolutions.com/2018/01/08/falsehoods-programmers-believe-about-names-with-examples/

True. Core Updater takes care of all these extra steps for updating beyond 1.0.3.

Standard migration method is to upgrade this shop to PrestaShop 1.6.1 using PrestaShop updates, then migrating it to thirty bees. If this doesn't work out, there are modules and services which don't migrate the shop software, but copy products, customers, orders and all this stuff from an old to a new shop. For example these: https://store.thirtybees.com/shop-modules/administration/migrationpro-migrate-from-prestashop-to-thirty-bees-migration-tool http://www.shopping-cart-migration.com/#a_aid=thirtybees

Not really. thirty bees works entirely fine without any caching. Caching shouldn't change shop behavior other than making it faster. Also, some caching methods have benefits on one system, but not on another. When enabling caches one should always test whether there's actually a performance benefit. If there is no such benefit, I'd keep it off. Adding complexity without a gain is rarely a good idea.

Wow. This appears to happen quite often. Three such questions in the last two days. Anyway, here's the solution:

Yes, see

We might be able to be more helpful if you'd share the error message.

The thirty bees solution for this kind of spam is here: https://github.com/thirtybees/thirtybees/commit/c733d5360d5292c12bb6a899748d9094bc608e05 https://github.com/thirtybees/thirtybees/commit/7ad147d991861e498e586f4dfc8ad1ff3cc114c0 https://github.com/thirtybees/thirtybees/commit/f04f1ded917b702465b2da6adfb7d573fdb974ad Three commits, because it's based on this solution in the PS forum, but also more complete. For example, it also updates JavaScript validation to avoid fields turning red on valid names.

Fixed. See https://github.com/thirtybees/thirtybees/commit/dc562ddd0534a21c707741f9a5c52b2256ffd53c

I just tried to reproduce this, but no matter how often I change order status or resend a status email, I can't produce a 500 error. Did this on 1.0.8 as well as on latest 1.0.x. It looks like a more detailed step-by-step procedure to reproduce this issue is required. Where exactly to click in front office, where in back office, which payment method, status change from which status to which other status.

No need to apologize. Looks like I overreacted a bit. You mean this error happens when trying to install the module already? Then there's obviously something wrong with the code installing modules. In back office -> Advanced Preferences -> Configuration Information is a list of changed files at the bottom of the page. Does this list any changes?

Where? thirty bees officially supports PHP 7.2. Also, module GitUpdater is abandoned in favor of Core Updater. Not only a rename, but also latest fixes. It should appear in the module list in back office.

There is some support for it, but not yet ready for consumption. Too many other, more crucial bugs.

This is how Core Updater does it: https://github.com/thirtybees/coreupdater/blob/master/views/js/controller.js#L289 It's JavaScript only (using Bootstrap features), no template, CSS or HTML changes needed. To get this working elsewhere, adjusting usage of the field parameter should be sufficient.

Back office should work right after the move. To get front office working as well, adjust Shop Domain, SSL Domain and Base URI in back office -> Preferences -> SEO & URLs.

Pretty much all PrestaShop 1.6 modules work on thirty bees as well, so the obvious idea is to look there.

This should be solved, the PHP Mbstring extension is a requirement now. Thanks for reporting!

... except that it hurts to see such suffix abuse 🙂 But you're right, even PNGs get a .jpg suffix and it works.

It's the Block Currencies module. It appears as soon as a second currency is installed.