premanshu

Ok.. Just to make it more easier for everyone here is the manual upgrade steps I have created on my test site (now working fine on 1.5.3) to upgrade my live site from 1.5.2 to 1.5.3.. You can refer to these tables structures if these have been correctly updated or not after upgrade. Change ps_ with your table prefix. Important Note: These steps are valid only for upgrade from 1.5.2 to 1.5.3 and use it at your own risk. Do not hold me responsible. SET NAMES 'utf8'; ALTER TABLE `ps_customer` CHANGE `outstanding_allow_amount` `outstanding_allow_amount` DECIMAL(20, 6) NOT NULL DEFAULT 0.000000; UPDATE `ps_order_state` SET `delivery` = 0 WHERE `id_order_state` = 3; ALTER TABLE `ps_product_shop` ADD `id_product_redirected` int(10) unsigned NOT NULL default '0' AFTER `active` ; ALTER TABLE `ps_product` ADD `id_product_redirected` int(10) unsigned NOT NULL default '0' AFTER `active` ; ALTER TABLE `ps_product_shop` ADD `redirect_type` ENUM('', '404', '301', '302') NOT NULL DEFAULT '' AFTER `active` ; ALTER TABLE `ps_product` ADD `redirect_type` ENUM('', '404', '301', '302') NOT NULL DEFAULT '' AFTER `active` ; UPDATE `ps_order_state` SET `send_email` = 1 WHERE `id_order_state` = (SELECT `value` FROM `ps_configuration` WHERE `name` = 'PS_OS_WS_PAYMENT' LIMIT 1); UPDATE `ps_order_state_lang` SET `template` = 'payment' WHERE `id_order_state` = (SELECT `value` FROM `ps_configuration` WHERE `name` = 'PS_OS_WS_PAYMENT' LIMIT 1); DELETE FROM `ps_configuration` WHERE `name`= 'PS_HIGH_HTML_THEME_COMPRESSION'; INSERT INTO `ps_configuration`(`name`, `value`, `date_add`, `date_upd`) VALUES ('PS_MAIL_COLOR', '#db3484', NOW(), NOW()); ALTER TABLE `ps_order_cart_rule` CHANGE `name` `name` VARCHAR(254); ALTER TABLE `ps_cart` CHANGE `delivery_option` `delivery_option` TEXT CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL DEFAULT ''; ALTER TABLE `ps_currency_shop` ADD `conversion_rate` DECIMAL( 13, 6 ) NOT NULL; UPDATE `ps_currency_shop` a SET `conversion_rate` = (SELECT `conversion_rate` FROM `ps_currency` b WHERE a.id_currency = b.id_currency); INSERT INTO `ps_configuration`(`name`, `value`, `id_shop`, `id_shop_group`, `date_add`, `date_upd`) (SELECT 'PS_GIFT_WRAPPING_TAX_RULES_GROUP', b.`id_tax_rules_group`, a.`id_shop`, a.`id_shop_group`, NOW(), NOW() FROM `ps_configuration` a JOIN `ps_tax_rule` b ON (a.value = b.id_tax) WHERE a.name='PS_GIFT_WRAPPING_TAX' GROUP BY a.`id_shop`, a.`id_shop_group` ); DELETE FROM `ps_configuration` WHERE name='PS_GIFT_WRAPPING_TAX'; ALTER TABLE `ps_cart_rule` ADD `highlight` tinyint(1) unsigned NOT NULL default 0 AFTER `gift_product_attribute`;

There is also another sql step in my view which is needed and not being done during update. "outstanding_allow_amount1530();" step of upgrade run on wrong table ps_address and hence results in doing nothing. After doing manual check I found that column "outstanding_allow_amount" is part of ps_customer table. So you might also need to run below sql to make the changes required by step "outstanding_allow_amount1530();". ALTER TABLE `ps_customer` CHANGE `outstanding_allow_amount` `outstanding_allow_amount` DECIMAL(20, 6) NOT NULL DEFAULT 0.000000;

Its in defines.inc.php Just change define('_PS_MODE_DEV_', true);

Here are the correct sql from from db_structure.sql file: ALTER TABLE `ps_product_shop` ADD `redirect_type` ENUM('', '404', '301', '302') NOT NULL DEFAULT '' AFTER `active` ; ALTER TABLE `ps_product` ADD `redirect_type` ENUM('', '404', '301', '302') NOT NULL DEFAULT '' AFTER `active` ;

Does not work in my case

@Trip.. Thanks for this debug option. This is something new for me on PS and never noticed it. I agree the first byte is 2 sec but only after removing blockspecial module in 1.5.2 installation. If I enables the same module it goes to 5 sec for first byte. In 1.4.7 I have seen the first byte coming within 1.5 sec. Although this is 500ms loss but looks significant when the server is hosted outside the country in remote location due to additional network delay involved. For blockspecial module I have posted in multiple threads and also raised a bug but developers are working on more critical issues right now then to work on fixing the speed related issues. The people who are directly impacted are the one`s who have upgraded their DB. Fresh install is still good.

Hi Trip, How did you compiled this data? Can you provide some info of finding this data so that we can compare our slow stores.

Yes, This getRandomSpecial function is called from Product.php and is actually making a query in DB to get the product. In MySQL stats it is showing that query is taking place on non indexed columns.

Yes.. I tried replacing the module but it is still the same. Changed my DB Engine from InnoDB to MyISAM. Tried all optimizations in MySQL but no help. Finally disabled the module and the speed went back to normal. I strongly feel it is a problem with query being used in "getRandomSpecial" Function in Product.php which is taking too much of the time to fetch the data.

Are you using Blockspecials module on your upgraded shop?? Try disabling it..

Hi bside2234, Are you using a fresh install or an upgraded shop? In my case I am using an upgraded database from 1.4.9 and I am facing many bugs in Prestashop which are only coming in upgraded shops.

Have anyone noticed that Blockspecials module when enabled slows site speed by more than 6 sec. As soon as I disable the module then the site goes back to normal. I am using native blockspecials module without any change. It looks like getRandomSpecial Function is doing a very heavy query. Please reply if someone else also facing similar issue. Raised a bug for it also but looks like this is very low priority for everyone. http://forge.prestashop.com/browse/PNM-674

No replies.. Is it a bug or no -one checked their site speed after enabling this module.

Hi angelac, use these settings: BO > Preferences > Products > Pagination > Default order by > Product Name

Add below code to classes/category.php It works on 1.5.2 as well. public static function hideCategoryPosition($name) { return preg_replace('/^[0-9]+\./', '', $name); }