Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I didn't notice this before because it is in yellow rather than red but this warning appears before the error Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.
  2. The store is using the theme from PS 1.6.
  3. This is a page with a product that uses Attribute Wizard Pro https://thetabdepartment.com/black-and-white-custom-tabs/7-custom-tabs-set-of-8.html#/stock-90lb_index_stock/sides_printed-front_and_back/spine_reinforcement-reinforced/drilled-3_hole_punched/collated-collated/turnaround-3_business_days_standard/paper_size2-letter_8_5_x_11/orientation_2-long_edge/mylar2-clear_mylar/portrait_or_landscape-portrait_binding_on_left_tabs_to_the_right_tabs_start_from_top I now believe the issue is that combination.json.php from that module as I can see a ERR_EMPTY_RESPONSE when using developer tools. I've contacted the developer and am waiting to hear back but if you happen to have any suggestions it would be greatly appreciated.
  4. The change delayed the issue but did not fix it. When you go to a product page now everything is fine but as soon as you change an attribute for the product it reloads the top left of the product page causing the same error as before. The difference is that now the page is fine when you first arrive 100% of the time and it breaks 100% of the time. It also breaks it in all browsers now. The issue is limited to products that take advantage of Attribute Wizard Pro but the store requires that module.
  5. No cache. I'll try for performance tweaks once everything is working perfectly but I made sure all cache/performance features were set to off. I do have AttributesWizardPro which is a module that involves a lot of changes to files (at least more than most modules) and that is the only module on the product page that I did disable because it is essential to the store. During the first few hours of testing I suspected it was AttributesWizardPro as the issue would only occur on products that used that module. It is hard to know for certain because as I got frustrated my record keeping of when the issue presented became sloppy but I do believe it happened on product pages without AttributesWizardPro but I can't be certain. In addition to that module I also use a module that displays the discounted prices in the top right also from PrestoChango but wanting to eliminate that as a possible source I disabled it and the problem persisted. Other things I noticed It was Chrome only (once in Brave but that is Chrome-based) and I could never get the error to happen in Firefox. That could just be variance but I tested this for ~6 hours and got zero instances in Firefox and it happened around 25-30% of the time in Chrome. Once it happened it would continue to happen 100% of the time even if I left the site and returned to it. Likewise if it worked it would continue working and not break no matter how many times I went to the site. Launching an incognito window would lead to a new probability of it working or not which would be permanent for that incognito window. You could tell the Add to Cart button was broken even before testing it because when the problem presented itself the minimum quantities would not be set -- it would say 1 instead of 25. Also if the discount display module was enabled it would also not display. So the error when it happened would kill those processes Not sure if that sheds any light on what caused the issue. I have made the changes you provided and will test later today. I'm very grateful as this is not something I would have figured out on my own so thank you.
  6. Naldinho

    tool.js error

    I have a shop that has had issues with the ability to add products to cart -- the issue seems to be limited to Chrome and is intermittent which makes no sense to me. I was hoping someone with more knowledge could help. The shop is now running on TB 1.3 but the problem existed before that so it is not because of upgrading to 1.3. The theme is the old default theme from PrestaShop 1.6 as that was what the store was running before migration. In developer tools I see the following error tools.js:105 Uncaught TypeError: Cannot read properties of undefined (reading 'CAD') at displayPrice (tools.js:105) at formatCurrency (tools.js:83) at writeDiscountsContent (196-custom-tabs-set-of-5.html:592) at HTMLDocument.<anonymous> (196-custom-tabs-set-of-5.html:676) at j (jquery-1.11.0.min.js:2) at Object.fireWith [as resolveWith] (jquery-1.11.0.min.js:2) at Function.ready (jquery-1.11.0.min.js:2) at HTMLDocument.K (jquery-1.11.0.min.js:2) The store is multicurrency with CAD being the default currency. I'm really at a loss on this. Intermittent issues don't make sense to me.
  7. Yes it was a permissions issue. Everything inside the public_html directory had the correct owner and permission but the public_html directory itself was owned by root. Once I chanced that to www-data the update worked fine. Fairly specific issue but figured I'd post the solution on the off chance that someone else has this issue in the future.
  8. I am trying to update to 1.3 and I get an error that says Failed to create update file Any ideas what would cause this? I suspect it is a permissions issue with the server but I believe I have everything set correctly 644 for files and 775 for directories. That said I just finished moving the site and the original site on the original server had no issues updating but this one won't.
  9. When I go to update to 1.3 i get a long list of modified and extra files. I expected a few as a I have a module that requires making changes to core files but this is probably more than 150 files. Is that normal? It seems that when I upgrade to 1.3 it will remove all the extra files and the modified files -- is that correct? Basically I'm concerned that all these extra/modified sites might be some kind of exploit (years back under PrestaShop there was an issue with some modules and I thought I had cleaned all of that up but now I'm concerned).
  10. Thank you for the responses. I expected the 7.1 was out of date Ok so 7.3/7.4 sounds like the way to go and since 7.4 is the default on ubuntu 20.04 LTS that seems easiest. I will use a VPS -- gave up on shared hosting at least 5 years ago. Transitioning from Digital Ocean to Linode planning to use dedicated CPU 2 CPU 4GB RAM. Cost is is not a issue but for a single store that is low traffic I don't think there would be benefit in going higher than that. This is a old store -- originally PrestaShop then came to 30 Bees. Even before switching to 30 Bees the store was experiencing issues that have gotten worse -- not one thing in particular just a bunch of things that on the surface don't seem related. I'm hoping that the move + upgrade and some work solves that.
  11. I'm going to be setting up a new server for my 30 Bees store -- I was just looking at the requirements page and it mentions PHP 5.5 to 7.1. Is that still correct even with the recent release of 1.3? I did some searching on the forum and people seem to be saying to use 7.3 but not 7.4. That discussion was mid-2020 so a bit old. I'm starting from scratch and 30 Bees will be the only thing on the server so I am free to set things up in the optimal way. What would that be?
  12. I don't know what you mean by server mail -- I am not running my own mail server but rather the email is handled by Office365. I enter the Office365 settings and press send a test email -- everything works fine. I then leave the settings area and do anything in the store and when I return to the email settings they have changed from using SMTP to using php mail. This is not an issue with my email server. The problem is with the store and for some reason it will not change the settings of how the store handles email permanently. My assumption is that the email works fine when I change the settings because the store is using the settings that I just set. When I leave that page and return the store pulls the settings from the database and they are the wrong settings. As such what is broken is the Save button in the email settings page of by thirtybees store. Since this doesn't seem to be a common problem I have to assume it is something wrong with my store -- possibly some kind of corruption occurred that makes it so tat whatever table the email settings are saved in either is missing or corrupted. What I am hoping to do this weekend is to manually change the setting in the database. The actual sending of email mechanism works fine as long as the settings were just entered. The problem is the store lacks email setting permanence. What I need from either support or someone in the community is some direction on the structure of the thirtybees database -- basically what table is the email settings stored in and anything else I might need to know. Rather than trying to figure out why changing the settings is not resulting in the changes being permanent I figured this isn't a setting that needs to be changed often so I'm just going to try to do it manually.
  13. I asked this in Technical Help last week and got no responses so maybe get something here, I can't set my store to use SMTP email -- when I set it and send a test email it works and no matter how many times I press save when I come back the settings have changed to php mail(). If I could get it to stay SMTP I think that would fix the issue since the test email works but I can't -- can someone tell me why? Since I can't get 30 Bees to change this setting I was thinking that I could manually edit the database to change the setting. Can someone tell me what the value and where in the database this setting is saved.
  14. I'm having issues with emails -- if I go to Advanced Parameters -- > Email and select Set my own SMTP parameters and press save then leave the page and return it has reverted to Use PHP's mail() function. No matter who many times I change it to Set My Own it will not stay set. Can someone tell me why?
  • Create New...