cprats

@datakick the problem was the Knowband Marketplace module old overrides. I've deleted all of them using the Override check module, and I've also had to delete manually a folder: override/classes/marketplace with 17 files: index.php, KbEmail.php, KbGlobal.php, KbPerProductSellerShipping.php, KbReasonLog.pgp, KbSeller.php, KbSellerCategory.php, KbSellerCRequest.php, KbSellerEarning.php, KbSellerMenu.php, KbSellerOrderDetail.php, KbSellerProduct.php, KbSellerProductReview.php, KbSellerReview.php, KbSellerSetting.php, KbSellerShipping.php, KbSellerTransaction.php. I list them here for knowledge base purpose. Now I/O Usage values are normal. Profiling gives a more reasonable load time, but still the double of that shown by @Traumflug : Thanks to you all. I've learned more in 20 days in this forum than in six years in the PS forum.

No overrides for this controller, but I've found 155 overrides of a module (Marketplace, by Knowband) I used a couple of years ago but not longer in use and even deleted. What a mess! Also, there is an override for nocaptcharecaptcha module, which I uninstalled after testing it. Is it safe to delete all these overrides?

@cdwebman said in Back to PrestaShop or stay with Thirty Bees ?: Hé, this forum is alive, and it looks like TB is also very alive ! Sure. It's only 22 days I am using thirty bees and in this time I've asked 11 questions about issues in this forum. 11 of 11 have been answered and solved, even one about a PS module. The day before switching to TB I asked something in PS forum and no one has replied yet. See it yourself here: https://www.prestashop.com/forums/topic/908912-blank-modules-page/

@cdwebman well, it's up to your customer and his willingness to act against his own interest. I switched to TB because of one single module not able to work under PS1.7 and because their API was literally keeping me stopped while the back office was stuck. In those circumstances, it is totally useless if PS has 100k users or ten million. Themes/modules developers opinion is just this, an opinion. Users are who really decide. If they face massive modules deprecation under PS1.7 or a chance to keep them running under TB I think the decision will be very clear. I predict that when PS stops supporting 1.6 after this last minute, surprise support extension until next May, store owners will be willing to pay for a migration to TB.

Sure! But public function_get($key) was in line 59 instead of line 156 I've changed it to &_get($key) and the warning has disappeared when debugging. Thanks for this!

First of all let me apologize for asking this question here, as I am totally conscious it is not the appropriated place to ask it. I have a module built for Prestashop running well under TB, to auction items. I purchased it in Modulesmarket through Prestashop's marketplace. Not a single complaint about the developer. He last updated this module in 2015, and I asked him if he would make it compatible with Prestashop 1.7. The answer was no, and this is why I didn't doubt to switch to TB. After reading some topics in this forum I've understood why the developer didn't want to waste his time updating anything for PS1.7. This is the module, for if it happens anyone has curiosity about it: https://addons.prestashop.com/en/build-auction-site/3438-auctions.html I did a debugging and I got this warning: Warning: Declaration of ProductAuctionObjectModel::__get($key) should be compatible with & ObjectModelCore::__get($property) in /home/xxxx/public_html/modules/auctions/classes/model/object_model/productauctionobjectmodel.php on line 156 Could anyone give me a slight Idea of what does this mean? Obviously I am not asking anyone a solution for a module no one here built, I just would like to understand what the problem is before contacting the developer.

I've found another slowness. I run TB1.0.7 migrated from PS1.6.1.20 and the problem also reproduced under PS. See if it can help to identify any fault: When I click on Advanced Parameters -> Configuration Information the loading time is large. Here a profiling: Doubles seem to be OK: But meanwhile, in the server: When the page finishes loading, I/O Usage and IOPS return to normal values. I'll be happy if this info helps to find a possible bug, and I'll be happier if it can be solved. Additionally (and surely not related to this issue) the Changed/Missing files in Configuration Information warns about this missing file: public_html/administrationfolder/autoupgrade CC: @datakick

I've removed the code you pointed out and now it works fine. Thanks again.

@datakick Thank-you so much for your help

It seems the problem is with idproduct. I am using this route to products in schemaurls: {categories:/}{rewrite} instead of the configuration I had when the core was Prestashop: {category:/}{id}-{rewrite}{-:ean13}.html

@datakick Here is the Doubles section in 6 screenshots:

@datakick I tried again and now I've got one of the slow products. It only happens if I change all categories. For example, a product in Categories-New-Covers will not experience a slow modification if changed to Categories-New. But, If I unselect all categories and I select a different category (for example, Sold Idems) saving process will be extremely slow. Here a screenshot of profiling while editing one of these products:

@briljander said in Auctions module suggestion: I think you need to specify how much you are willing to pay to make people and agency's interested. I just suggest developers to create the module to sell it through TB modules market. I am not requesting a special and private work in this post. I already have an auction module, but it could be improved. If such a module was available in TB modules market I would pay $100 for a copy. If I had to request a special module just for my own use I would pay what is usually paid for this kind of jobs.

Could I suggest anyone willing to do it to build an Auction module for thirty bees? Or could this be a native function of TB? If anyone is interested I would be happy to provide my user experience with this kind of module to improve all those that already exist. I've tried everything and the only one really working is this one: https://addons.prestashop.com/en/build-auction-site/3438-auctions.html But despite of this, it can be largely improved with new or better functions.

@datakick said in Slowness when changing product category and MySQL error: @cprats I don't see anything. Is this a result of a product save operation? Yes. The slowness only occurs with the products that were already in the store before the migration. After the change of category of those products, another change is fast as it should be.

@datakick Sorry, it was debug, you're right. This is the profiling result:

I've enabled debug profiling and I've got all these messages: Warning on line 265 in file /home/xxx/public_html/classes/PageCache.php [2] Invalid argument supplied for foreach() Unknown error on line 280 in file /home/xxx/publichtml/modules/googleshopping/lib/phpseclib/Crypt/RSA.php [8192] Methods with the same name as their class will not be constructors in a future version of PHP; CryptRSA has a deprecated constructor Unknown error on line 82 in file /home/xxx/publichtml/modules/googleshopping/lib/phpseclib/Crypt/Hash.php [8192] Methods with the same name as their class will not be constructors in a future version of PHP; CryptHash has a deprecated constructor Unknown error on line 176 in file /home/xxx/publichtml/modules/googleshopping/lib/phpseclib/Math/BigInteger.php [8192] Methods with the same name as their class will not be constructors in a future version of PHP; MathBigInteger has a deprecated constructor Unknown error on line 115 in file /home/xxx/publichtml/modules/shopgate/vendors/shopgatelibrary/vendors/JSON.php [8192] Methods with the same name as their class will not be constructors in a future version of PHP; sgServicesJSON has a deprecated constructor Unknown error on line 796 in file /home/xxx/publichtml/modules/shopgate/vendors/shopgatelibrary/vendors/JSON.php [8192] Methods with the same name as their class will not be constructors in a future version of PHP; sgServicesJSON_Error has a deprecated constructor I've deleted Google Shopping and Shopgate modules because they were not installed and I was not using them. After deleting those modules, I only get the first warnig: Warning on line 265 in file /home/xxx/public_html/classes/PageCache.php [2] Invalid argument supplied for foreach()

When I edit products, it takes a lot to save the modifications if I change the category. Sometimes I even get this error: ``` Link to database cannot be established: SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2 "No such file or directory") ``` This only happens when editing older products, but newer ones update fast. I'm using TB 1.0.7 migrated from PS 1.6.1.21 Any idea of what can cause this?

What's better for SEO, keeping the ID product number in the URL or using the thirty bees default configuration without ID product number?

@the-rampage-rado I've just installed the recaptcha TB module. Thanks for your recommendation.

@the-rampage-rado I have contact and company info on a link in top menu and all data displayed on a page, and again in the footer. I just want to disable the email form as no one except spammers use it.

I've removed the "contact us" page entry from Preferences -> Seo & URLs, but it is still accessible through the sitemap, in the adress mysite.com/index.php?controller=contact. Is there any way to disable also this "index.php?controller=contact"? I just get spam from there.

Thank-you so much @Traumflug

Hello again, now I've found a bug here: I wanted to revert the changes in schema urls, but it is impossible. I delete the configuration in both languages, click save, and apparently the changes are saved and the routes are deleted. But when I click any of the language selector for the form the just deleted routes appear again. No changes in front office, now with products and categories appearing with id number. Any solution?

Ooops!!! Sorry, It has been my fault. I have two languages enabled and I didn't notice the schema urls also have routes for both languages. No errors, no bug, no problems. Can someone please close this thread or mark it as solved?