Naldinho

I am looking at various options to fix/replace a TB 1.3 store that is not doing well. One of the issues is that the main product has too many customizations so the traditional way of doing permutations is problematic as we quickly end up with a very large number. With PS and then with TB I was able to avoid that issue by using a module called Advanced Attribute Wizard Pro that stored the permutations in a different manner. With Presto Chango exiting the TB ecosystem I am looking for a module that either solves this issue with permutations becoming too large or that allows for conditional attributes which would likely be the better option. If anyone knows of a module that could help me I'd appreciate being pointed in the correct direction.

I am maintaining a Thirty Bees store that is currently 1.3 and which was originally a PrestaShop store. The store has been getting less and less stable and now I am getting 500 errors pretty much non-stop including when trying to access the modules area from the backoffice. I'm considering starting from scratch with a clean install of Thirty Bees 1.5 on a fresh server. If I was to do this would it be possible to import all the data, images, etc from the old store? The store uses a no longer supported module called Advanced Attribute Wizard that was published by PrestoChango. With Thirty Bees advancing as a project does anyone know if that module will continue to work with 1.5? It is essential to the store but is no longer supported. Would be willing to buy a new module that solved the same problem if one exists.

After applying fix manually I would say those numbers were low -- it was likely double or more. Everything is fixed except the following three

When I did this I got a really long list -- ~30 labeled Critical and ~100 labeled Recommended. Around a third also have the Dangerous tag. Is that normal? I'm going to apply all the fixes and see what happens.

I'm trying to use Tidy to clean up a few hundred thousand abandoned carts. It seemed to work fine when I was on TB 1.2 but now with TB 1.3 I am getting 500 errors. I don't know if that is because of the upgrade or because I moved the site to a different server and need to increase something in php.ini Anyway -- I turned on debug in defines.inc.php and the error I am getting is that my database does not have the table ps_pagenotfound I've confirmed that is true by checking the database directly. Is that normal? I've been having a lot of issues with this store for months and am very close to getting it to work properly so I'm sensitive to anything that could be wrong.

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/.

The store is using the theme from PS 1.6.

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.

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.

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.

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.

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.

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.

Thank you.

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).

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.

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?

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.

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.

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?

I just migrated a day ago so I'm new here and don't know much about the dynamics of either the company or the community but I do recognize the sentiment expressed by datakick. When working on a project-- even if it is something you enjoy and something you believe in-- if there are benefits and they are not being distributed commensurate to the value each person brings to the project then the people who are doing the most are going to start to feel resentment. It is perfectly normal. The only way I'd expect for this to be fixable-- in a form that would be stable going forward-- is to offer equity in the company to the people who contribute value. People need to have skin in the game to feel like everyone is rowing as a team. This particular situation is complicated by the fact that the lead organizer has been MIA since announcing what sounded like a very serious medical issue. That is a very sensitive issue and it brings to the surface what I see as the original problem in that there really is no governance structure -- there are two members of the llc and from reading this thread I don't think anyone can name who the second person is. My guess is that when this fork happened the people who broke away from PS were online friends/acquaintances so the focus was on getting the project going rather than the boring legal stuff. In my experience that always ends badly. As a final comment as someone who just migrated I have no regrets -- TB works and it will continue to work for much longer than it is reasonable to not expect to have to redo an e-commerce site. As a product I have no issue both using and recommending TB. As a project though having it out there that the ship is stalled and adrift is something that is time sensitive so if it is going to be resolved then should be resolved quickly.

Thanks found a bunch -- I had a typo in my original search (tsl rather than tls) so nothing came up.

Under Check Your Configuration it says: Install TLS v1.2 support on your server. Test result: fail What does this mean? My original thought was that I needed to ensure that I was using TSL 1.2 so I ran SSL Server Test and TSL 1.2 is the only one with yes in Protocols so I don't know what the TB warning wants.

This is a minor problem so I am only asking because unexpected behaviour is always a concern but it doesn't actually interfere with my ability to use TB The filter in the backoffice for modules typically doesn't work. It works occasionally but most of the time I just get all the modules even when I clock on say Shipping Modules This was also the case before migrating.

Solved it. In case anyone ends up here by searching for the same issue. The image files get deleted so if you backed up your site before migration by downloading the entire public_html directory then all you need to do is upload the images back to their modules -- in my case themeconfig, homeslider, and blockstore. If you don't know what module you're looking for just go to modules on the local copy and search for .png Once you see the missing image right click and open in location will give you the name of the module. Then just use ftp to replace the image on the server ensuring that it had the right owner and permissions.