otzy

It seems that with each new version Prestashop gets slower and slower. 1.6 is unfortunately not an exception. I need to manage tens of thousands products in a single category. I understand, that traditional pagination will not work, but even the first page in category takes sometimes 15 seconds to load. Prestashop is the one of the best solutions - simple, user friendly and with a rich set of features. But looking at code I see that approach remained the same as it was in the version 1.3 or even earlier. Just have a loook at SQL in Product->getNewProducts(). Stuffing sql with all data just leads to full table scan. Another example is ProductSale->getBestSalesLight() with it's IN clause, built dynamically as a string from all product ids. Can you imagine the size of resulting string? Layered navigation block - executes individual query for every product in the category. Must be disabled if you want your site had signs of life Category->getProducts() - full table scan and ambigious fields the recordset. I'm pretty sure this is a not complete list of issues. Why I'm writing about this here? I'm a fan of Prestashop since version 1.3, but now I'm thinking about migrating to another platform. I see that Prestashop team does a great job. But may be it's a time now to cleanup the code instead of racing for features?

fine, but one remark - it is better not to change core controller file. Copy attached file to /override/controllers/ and you will be happy with future Prestashop updates. CartController.php

if you don't need dynamic content, you can add script directly to cms page content. Click to HTML button on MCE toolbar and insert any html code you want. For dynamic content I see two ways, the first one is to request data with ajax from the script added to page content html. The second - use smarty plugin function. Earlier I used {insert} smarty tag but it's deprecated from Smarty 3

assign css classes to popup link and popup content, for instance <span class="popup_link">popup link</span> <div class="popup_content hidden">size table ...</div> then add to your theme javascript the code for binding popup widget to class popup_content and clik event to popup_link

looks like opening or closing bracket is missing. Check the hole script for errors

ah, yes $_SERVER['SERVER_PROTOCOL'] always returns 'HTTP/1.0' you need to use $_SERVER['HTTPS']

add line to init.php: $smarty->assign('server_protocol',$_SERVER['SERVER_PROTOCOL']); then you can use variable $server_protocol in any tpl file

Import Fast module contains script for bulk image upload. http://www.prestashop.com/forums/viewthread/56689

thanks Biglama ajax searching is not complicated task. But I think that the development of proprietary search is not efficient way. In my plan to install and integrate some free search engine.

Your site http://www.toolsupplycenter.com is the biggest at the first glance. But any request takes more than 10 seconds, not only search. So if we decrease the time of search response on 10s it will be ok. But if you try to search some popular word, "set" for instance - the response time will be about 14-15s. Try to search something here: http://www.brandwelt.com in order to compare performance. And I agree with Biglama concerning meta tags and other …

insert command at line 277 of Search_Otzy.php (before $result = $db->ExecuteS($queryResults) print '<!--queryResults='.$queryResults.'-->'; then find sql query on the search results page and try to understand why it returns nothing. By the way - ajax search is rather fast.

ok, try the file in attachment. before you try add field active tinyint to the table ps_search_index and create index on this field. You have to set active=1 for active products. Finally replace in search.php all calls Seach::... with Search_Otzy::.... (actually only function find() was changed)Search_Otzy.php

SQL queries in classes/Search.php are not well designed. They use join on category_product, product and category. Along with paging it sometimes demands full scan of some tables. You may also find there the loop on eligible products and IN clause whith huge list of items in your case. I rewrote function Search::find() and added the new field active to the table ps_search_index (this field is calculated regulary). Now there are only one SQL request in find() function. And it is fast. If you are familiar with php and sql I'll send you my solution.

probably it's a bug of jQuery unbind() - I don't know why but it did not unbind onclick assigned in html.

while I was mining your site it got fine. Good luck