datakick

It's a module, so you have to chose 'Installed modules translations' and not 'Front office translations'

Controllers can (and often do) use helper function like Tools::parseNumber to process input values. This allows merchant to enter formatted strings that includes spaces and different separators, for example "$1 012,10". In core and native modules we try to use these helper methods everywhere user can input values. But of course, there are places we missed. You can file issues for those.

Look to file /vendor/composer/platform_check.php It should start with something like this: <?php // platform_check.php @generated by Composer $issues = array(); if (!(PHP_VERSION_ID >= 70400)) { $issues[] = 'Your Composer dependencies require a PHP version ">= 7.4.0". You are running ' . PHP_VERSION . '.'; } This is the stop-gag measure that prevents your store to run on older / non-supported versions of PHP. If it says 7.4, you are good

That's strange. Try to manually edit settings.inc.php and change value of _TB_BUILD_PHP_ to 7.4 Then go to core updater and try update. It will probably display something funny (manual modifications warnings, etc), but you can ignore these and perform the update.

Go to Preferences > SEO & URLs and enable Emit SEO fields

Maybe your config/settings.inc.php file is not writeable? This is where core updater saves information about revision and php build.

You have to go to core updater settings and change target php version to php7.4. Then you can downgrade your php version. Looks like your php8 is not installed properly. You need pdo extension enabled. You probably don't.

Your server respond with 301 REDIRECT for 'add to cart' POST request 🤦‍♂️ and ask your browser to fetch page to https://<domain>/en/?rand=<rand> Browser do exactly that, and perform GET request for that page Now, this is GET request without original POST parameters, so nothing is added to the cart.

I agree. I just want to see different implementation of such feature, and not pollute transactional data with guesstimates. Order table should contain facts only

Number of rules you can create. Free version allows you to create 2 rules only.

my consequences module can do that. It allows you to create rule that will attach file before email for specific template is sent.

This is wrong. You always exit from foreach with a return, during the first iteration. You want to return only when error is encountered. Add {...} to your if statements, like this: foreach ($banned_in_email as $string) { if (strstr($from, $string)) { $this->errors[] = Tools::displayError('This email address is not allowed'); return; } }

Both are issues with your theme That's enough. Just don't post your admin dir anywhere. It was visible in your previous post -- I have edited it already to remove this sensitive information.

This error message suggests that you were logged-out during update. This can happen because coreupdater is a module that depends on core which is being updated. If something related to authentication process (encryption algorithm, cookie serialization, etc) changed in the new version, the current back office session is invalidated. That's quite stupid. No, it's very stupid. One of the high priority task on a todo list. We need separate updating tool that does not depend on core. Such tool could be even use to migrate ps16 directly to latest thirtybees. Anyway -- you should run core updater again. If there are no changes listed, go to Database tab and apply fixes. At least all missing tables and missing columns -- that would be performed automatically, but was not due to the logged-out bug.

So you probably have access to some control panel. It should contain some SQL tool (PHPMyAdmin or similar). Use this to connect to your database, and run this query: SELECT * FROM tb_employee; That will list all employees in your database. If this does not work, you have different database table prefix -- the table can be named like tb123_employee, ps_employee, or whatever. Look into the list of employees, and find the employee email address for which you want to change password. Let's say it's employee@email.address.com Then run this SQL query (change email address with the one you chose in previous step) UPDATE tb_employee SET passwd = '$2y$10$tGwJd/0V1mZJM0ZlHYdUkebHMr/5dJzl3N0UAt2e3IfWwQP.JJPmC' WHERE email = 'employee@email.address.com'; that will change passwords for this employee to changeme1234 Now you can go to your admin login page, enter the employee email address and this new password, and you will be able to log in. Then go to your preferences in upper right corner dropdown menu, and change your password to something more secure.

Good points. In the upcoming version of module there is a new validation for prefix, and that it matches country address. We could also implement regexp check, if the vat formats for different countries are know. That should fix the problems you mentiioned

Yes, I was thinking about similar solution. It does not even have to be integrated with payment solutions, but vatmodule could do that automatically after order has been created. If the order contains address with VAT# that is not validated yet (validation failed during checkout), vatmodule would set the order status to 'Awaiting VAT Number validation'. Merchants could manually verify the vat number, or the module could use some cron job and try to validate against VIES webservice. If the validation fails, the status would once again be switched, this time to 'VAT Number validation failed' status, and merchants would have to contact customer and ask for valid vat#, or for additional payment, or cancel order and refund money. The important thing is that the invoice should not be generated before the vat# has been validated.

Thirty bees vatnumber module can do automatic vat number check using VIES webservice. Unfortunately, VIES webservice is very unreliable. It very often returns error messages like TIMOUT or SERVICE_UNAVAILABLE. When that happen during checkout the order process is blocked. Customers are unable to complete the order, and leave the site. Not nice. For that reason, I disabled automatic check. But that brings other problems. Customers from other EU states sometimes enter invalid vat numbers (or valid vat number that is not eligible for cross-border transaction). System accept these invalid VAT numbers, and creates order without tax, and customers pay less. I will detect this situation later, but it's too late. Payment is already made, and goods are delivered (I sell virtual products, so there is no delay). I can ask the customer to pay the VAT. Sometimes they do, sometimes they ignore me. If that happen, then I have to pay the tax myself. In any case, there is a need to modify or issue a new invoice... it's a lot of hassle. How do you do that?

You can do this in javascript. Use page onload event, get url parameter from url, and put it into dom element with some ID.

We just released new version of module that fixes this api change issue. Please test. update module version go to https://dashboard.stripe.com/developers and upgrade your API version to latest

They should not be in sitemap: https://github.com/thirtybees/sitemap/blob/c1ade8ced29c953c5dd2e19d992cbcf437628066/sitemap.php#L697 Sitemap shows only products that match both these criteria: active = 1 AND visibility != 'none'

That's true, and it's terrifying. We will "fix" this issue

If you don't have access to back office, and you don't even know what email address was used for administration account, then you need to use FTP and upload unlock php script to your store. You should have some access to your hosting provider control panel. If you don't know access credentials, contact them, and ask them to provide one. Using control panel you should be able to set up FTP access. It might even be possible to directly upload files using web interface. Script to reset passwords for all employees is here: File to download: reset-admin.php Content: <?php include_once __DIR__ . '/config/config.inc.php'; header("Content-Type: text/plain"); $employees = new PrestaShopCollection('Employee'); /** @var Employee $employee */ foreach ($employees as $employee) { $newPassword = Tools::passwdGen(8); $employee->passwd = Tools::hash($newPassword); echo $employee->email . " = " . $newPassword . "\n"; $employee->save(); } Upload this script into root directory of your thirty bees installation under file name reset-admin.php And then visit your shop www.domain.com/reset-admin.php The script will change passwords for all employees, and displays the new passwords on the screen. Very dirty and unsafe 🙂 After you do that, delete the script from your store!!!!

What kind of access you do have? FTP/SSH/MySQL ?

If feature and feature value already exists in database, you can associate it with product by calling $product->addFeaturesToDB($id_feature, $id_feature_value) To dissociate product from all feature values, call $product->deleteFeatures();