-
Posts
3,120 -
Joined
-
Last visited
-
Days Won
487
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Everything posted by datakick
-
Why would it be bad for SEO? The original image urls still works, and google will (over time) learn about the new urls.
-
I believe this will be a rewrite issue. The friendly-url links for product images changed, it used to look like /35-home/friendly-rewrite.jpg but now it contains /products/ prefix: /products/35-home/friendly-rewrite.jpg. You should regenerate .htaccess (or your nginx configuration if you are not running on apache). I believe this would fix the issue. If not, we could troubleshoot more. That's unfortunate, since we can't figure out what the root cause was now. Please test updates on dev/test site
-
Go to preferences > store contacts, and set Shop email to one that your SMTP server accepts.
-
use SMTP for sending emails
-
Look in the browser console network tab, find the ajax request that failed, and look what response contains. There may be some hints there
-
No, modules for ps17 are not compatible with thirty bees.
-
The only version of this library that exports \Mobile_Detect into global namespace is version 2.8.x. Library author claims, in docs and in composer package.json, that version 2.8.x supports only PHP >=5.0,<7.0. It may be that that version can actually run on php7.4 as well, I don't know. But I believe author when they say that it doesn't. Since thirty bees does not support PHP<7.4, we can't use that version of library.
-
This is unfortunate backwards compatibility issue, but there's nothing we can do about it. Your module directly depends on old version of MobileDetect library (<3.74) -- that version is not compatible with PHP7.4 or higher. Ask the module author to use method from Context class instead. Lines 165...171 should look like this: $layout = Context::getContext()->isMobile() ? 'mobile' : 'desktop';
-
As @wakabayashi wrote, it's somewhat simple to reduce multistore to a singlestore. You need to make sure that all db records are assigned with target shop first. Check all *_shop tables, and *_lang tables and that contains id_shop column, are associated. Once all records are associated, delete the source shop. There shouldn't be an issue. List of related tables: SELECT table_name FROM information_schema.tables t WHERE table_schema = database() AND ( (table_name like '%\_shop') OR ( table_name like '%\_lang' AND EXISTS (SELECT 1 FROM information_schema.`COLUMNS` c where c.TABLE_NAME = t.`TABLE_NAME` and c.`COLUMN_NAME` = 'id_shop') ) ); If you have two stores in separate installations (not multistore), then it would be much more complicated. You would have to probably use data export and import.
-
Thanks for letting me know. This module checks only existence of .jpg source file. With the image rewrite, we can now upload and store source files in different formats as well (webp, avif, png,...) I will have to update the module to check for those as well
-
That still doesn't rule out infrastructure/misconfiguration issue. For example, you can have nginx reverse proxy with low settings for buffer memory. If your php server returns bigger http headers that can be stored, nginx will drop the response and return generic/standard error message similar to yours. One of your thirty bees installation can return much smaller headers, for example because it contains less cookies, or cookie content is smaller. I think that you should really investigate the root cause of this problem. Because it's most likely not a problem with application. You can reinstall your tb from scratch, restore database, and then encounter the same problem once again. But if really want to migrate -- it's easy. Backup your database. Install thirty bees. Edit settings.inc.php and copy all encryption keys there. Restore your database. Then go to core updater, enable debug mode, and in developers tools run database migration and initialization callbacks. That should do it.
-
Well, something is returning 403 Forbidden response. I don't think that it's thirty bees / php application. Thirty bees wasn't most likely even invoked here. I'm 99% sure this is issue with your infrastructure nginx configuration apache config mod_security config firewall settings your server antivirus your computer antivirus your computer firewall your browser extensions some "security" thirty bees / prestashop module (not likely, but could be) ...
-
no, it's standard https
-
The solution is to demand that google fix this bug on their side. If your robots.txt instructs google to ignore some url, then google console should not display warning that the url is not crawlable.
-
Please try to reproduce on bleeding edge - there were few bugs related to product duplication fixed already. If you problem is still reproducible on bleeding edge, file a new github issue.
-
It's hard to compare, as it's very subjective. You have to tweak the Image quality settings. For each algorithm it is slightly different. avif will have better image sizes as you increase compression = lower image quality settings [ quality 50 ] 5950 - 1-Niara_thickbox.avif 8342 - 1-Niara_thickbox.webp [ quality 70 ] 10591 - 1-Niara_thickbox.avif 10196 - 1-Niara_thickbox.webp [ quality 90] 26193 - 1-Niara_thickbox.avif 19052 - 1-Niara_thickbox.webp The nice think about avif is that it generates much less blurry images even at low quality. At q=50, avif is much nicer than webp at the same quality. It is probably at the level of webp at q=70. If you want to have high-quality images, you should probably keep using webp and q=90. If you want to have fast shop with good-enough images, you might want to opt for avif with lower q
-
You can see what events module listens to here: https://github.com/thirtybees/stripe/blob/e6068d34079e6ec38c90c3c23d2392646193120b/controllers/front/hook.php#L133-L145 However, I suggest you just enabled all events, in case module need them in the future.
-
Community themes, and some third party themes, use polyfill.io service to increase browser compatibility. Unfortunately, that service was bought by some chinese scums, and is now used to distribute malware (sonetimes) You have to 1) investigate what js files are fetched from that service 2) download the JavaScript file and verify that it does not include malware 3) upload it to your own server 4) modify theme to use your own copy of JavaScript For community theme, it is this line: https://github.com/thirtybees/niara/blob/341cf27338837191882bbe859c01713c6b1bd9c7/header.tpl#L63 This one is not needed anymore, so the easiest solution us to simply delete this line. If your theme/modules include other polyfills, you should follow the steps above
-
Works properly for me: When this email is sent depends on your verificaiton settings. If you opted for email verification, it will be send only after your customer verifies their email. Also, the voucher is send only first time you register the email address. Subsequent attempts to register the same email address will not trigger new email/voucher, obviously. Check your email settings. Check you email logs. Check Advanced Paramters > Logs to see if there are some warnings related to email templates.
-
Hi, I've just tested this and it works as expected. The cart rule was created for specific customer: There is no email sent by default when cart rule is created. But you can do that by adding another rule 'After conseqs rule'
-
Invoice lists carrier costs wrongly. PayPal sees them correctly.
datakick replied to Pedalman's question in Technical help
It's possible your theme contains overrides for invoice smarty templates. Check if there are any invoice*tpl files in /themes/<your theme>/pdf/ directory -
Check javascript errors in your browser console
-
It didn't work because your changes were overwritten by core. For example, in constructor, you assigned some data to fields_list variable, and THEN you called paren constuctor. Parent constructor assign it's own data to fields_list variable public function __construct() { $this->fields_list = [ // you changes to fields_list ]; parent::__construct(); // this call overwrites the fields_list } You should have called the constructor first, and then merge your changes: public function __construct() { parent::__construct(); $this->fields_list = array_merge($this->fields_list, [ // you changes to fields_list ]); }
-
Could you please share your override, so I can test? It should be still possible to override object model metadata It's a simple change, new html field in back office: You will probably have to modify your theme to display this new field. Simply edit category.tpl file and include this new field at the place you want. You can take an inspiration from niara support commit: https://github.com/thirtybees/niara/commit/beedd63032237293b2be1d5fe1463144d2f82e12