Traumflug

I believe it to be a very big mistake to make core files dependent on modules. It isn't designed to be dependent. It tests whether the module is installed and if it isn't, code should work just fine (not requiring this missing file). Even better would be a hook. Comments in the code already indicate a need for such an enhancement.

I was confused since tb says that the format is “Image URLs (x,y,z…)” Whether , or ; gets used inside fields is configurable. I just wanted to fix this message to make it match default settings, but this apparently happened already: Where is this message which confused you?

You experienced thirty bees self-healing magic :-) Maybe it was a stale cache somewhere. Should it happen again, please look up back office -> Advanced Parameters -> Configuration Information. This lists, among other stuff, changed and missing files.

It looks like your database considers module vatnumber to be installed, while it's actually not present on disk. This require_once() gets executed only if the module is installed. To solve this misalignment, install the module, then uninstall and optionally delete it. This should also solve the error message.

Grep is your friend: none $ grep -rn '"address_delivery"' themes themes/community-theme-default/order-address-product-line.tpl:34: <select name="address_delivery" id="select_address_delivery_{$product.id_product}_{$product.id_product_attribute}_{$product.id_address_delivery|intval}" class="cart_address_delivery form-control"> themes/community-theme-default/order-address-advanced.tpl:58: <ul class="address item box" id="address_delivery"> themes/community-theme-default/order-address.tpl:60: <ul class="address box" id="address_delivery">

without using overrides. Looking up the templates, like themes/community-theme-default/identity.tpl or themes/community-theme-default/authentication-create.tpl, one can find a few hooks which allow extending these fields. Just search for hook. During a TB update you have to remember which modules are overriding which function and update these module accordingly and this is not always possible. Partially true. It's true that sloppily written overrides can mess up a lot. Especially those just copying the entire original method to change just a line or two. One can write better overrides, though: - Check in each invocation whether the module is actually enabled. - Write code for just the change and call the parent method for everything else. That said, a solution using hooks is still the better choice. PS 1.7 removed overrides for a reason.

If you have a backup (or a sandbox), turn off the backup during the update. That's just a waste of time. These errors without message usually get solved by simply reloading the page and trying again. One can run updates over and over again, until it succeeds. Success is indicated by a version change and/or the updater no longer offering an update.

Then you're on 1.0.8 already.

Hmm. Can't find a table or usage of a table tb_product_group. Apparently some module stuff.

Already fixed it, the product didn’t have a group. This is not a fix, it's a workaround. Syntax errors are a bug, no matter what the merchant does.

It doesn't hurt to run the update twice.

I did that and got a 500 error. Report such incidents, please. thirty bees can fix only things it's aware of (filed in the bug tracker).

Filed the second issue as well: https://github.com/thirtybees/thirtybees/issues/803

Filed: https://github.com/thirtybees/thirtybees/issues/802

Is admin/ your actual admin directory? If not, delete the entire directory.

classes/controller/AjaxController.php classes/controller/ModuleAjaxController.php These two can get deleted. They're no longer in thirty bees. vendor/defuse/php-encryption/.gitignore vendor/defuse/php-encryption/docs/InstallingAndVerifying.md [...] Is this a developer installation, perhaps? Or a shop started with a clone from Github? These files aren't necessary either, they should exist in developer installations, only. admin/core.43007 admin/core.52205 admin/core.16100 These look like core dumps. Files written on fatal errors, only useful for debugging the code. Can go away as well. It looks a bit like this page needs a delete button behind each file.

These obsolete files were always there, just no tool existed to notice them. Finding obsolete files is also a new feature. I'd say one can delete them, but I have no idea which kind of files these are. Do you have a few examples?

Easier way to fix it: 1. Go to back office -> Advanced Parameters -> E-Mail 2. In panel EMAIL (the 2nd) find field Email subject template and insert [{shop_name}] {subject} there. 3. Click Save. This is the new feature which allows setting a custom email subject.

If everything else worked and a page reload shows the new version in the upper left corner, one can fix this manually using phpMyAdmin: Go to phpMyAdmin, select the database. Select SQL and run this query: sql SELECT * FROM `tb_configuration` WHERE `name` = 'TB_MAIL_SUBJECT_TEMPLATE'; If this query returns a line, everything is fine, no further work required. If it returns nothing, also run this query: sql INSERT INTO `tb_configuration`(`name`, `value`, `date_add`, `date_upd`) SELECT 'TB_MAIL_SUBJECT_TEMPLATE', '[{shop_name}] {subject}', NOW(), NOW(); To check the result, one can run the query in (2) again, it should return one record (if there's more than one, delete the duplicate).

Which MySQL version is this? It gets listed in back office -> Advanced Parameters -> Configuration Information.

Module thirty bees Updater should see the update now. Happy updating!

Is it possible you have name clashes? Like two categories having the same name? Renaming one of them resolves such a problem, of course. There's back office -> Preferences -> Duplicate URLs, which should find such duplicates.

Having an error with debug mode turned on leads to something obvious. Like a lot of text at the top of the page or a big red box. No need to search.

As mentioned yesterday already, the migration module received a lot of stability and convenience improvements. This resulted in Module psonesixmigrator 2.0.0 These new features are: - Extended directory tests for more reliability. - Compatibility with PHP 7.2. - Known incompatible modules get now moved aside automatically, into a folder modules.off. This should solve a number of cases where these modules had to get removed by FTP to allow loading the list of modules in back office. - No longer needed modules like 1-Click Updater or PS Cleaner get now removed as well. Equivalent replacements (tbupdater, tbcleaner) exist, of course. - Run not the PrestaShop, but the thirty bees testsuite before allowing migration. This is where the shop should run after migration, after all. And give meaningful error messages in case of misalignments, of course. - Synchronized PHP sources with thirty bees 1.0.7. This should bring thirty bees v1.0.7's reliability to the migration module. - URL schema settings now get preserved during migration. If they were never edited before, they previously got lost. For looking up what's going on, see https://github.com/thirtybees/thirtybees/issues/604. - Employees get switched to the thirty bees back office theme, to make merchants aware of the new safe waters visually as well. Supplemental files on api.thirtybees.com were just published as well already, so you get all the goodies immediately. For those shops migrated earlier: no worries, the regular update to thirty bees v1.0.8 will bring the cleaning part of this as well. No need to migrate again. (and I wish I knew how to avoid the following Github preview :-) )

This is nice but I would like to see more bugs fixed Do you indeed? Me as well :-) Preparation for v1.1.x isn't part of the work, yet. This release focused on two parts: Making it harder for new bugs to enter the picture. Fixing a bug is a bit counterproductive, if a sloppy fix introduces two other bugs elsewhere. This opens the door a bit wider for working with inexperienced (voluntary, hired) developers. And there are plans for even more such capabilities, like Travis CI tests for module commits, plausibility tests, even some linting, such stuff. Web development has kind of a tradition of pretty sloppy coding practices, so rigorous testing is IMHO the right answer to this. Making the experience collected by migrating shops available for everybody. The first migration module was certainly awesome work, still a number of issues came up, which get now fixed automatically. Even for those shops migrated earlier. One such issue is e.g. changed defaults for friendly URL schemes, which trashed SEO ranking before, unless the merchant took care of it manually. That said, all PS 1.6 themes still work with thirty bees. There is no limitation to the three most popular ones. And it'll stay this way as much as technically possible, even with v1.1.x.