keat

I restored 'fulltext' and then removed '.$order_string.' (around line 1816), and this also seems to have fixed the issue. So I guess we now need to understand what it does and why is it in there ? And just as importantly, why is it only me who has this problem ?

That seems to have fixed the issue. However, having said that, I'd already tested with catalogue.class from 6.0.12, and the search worked. The string in catalogue.class is also: public function searchCatalogue($search_data = null, $page = 1, $per_page = 10, $search_mode = 'fulltext') { So whilst changing the entry from 'fulltext' to 'RLIKE' appears to have solved the issue, it must be something else that's actually causing it.

I've definately narrowed it down to a change in 6.1. I'm trying to compare 6.0.12 and 6.1.0, but there are sections which are so different, that i've no chance of figuring it out. Any thoughts where I might comment out the step 'Order by Relevance',

It's happened to me when I've done an automated update.

happened to me too.

It seems that it's something in catalogue.class.php but what. If I restore catalogue.class.php from V6.0.10 in to the 6.1.5 classes folder, the search works. If I resore catalogue.class.php back to it's original 6.1.5 version, it stops working again. I've had a little look and tried to compare the two, but it might as well be encrypted.

My server ft_min_word_len = 4. However I've just created a new install of 6.0.10, and added 2 x test products. TP1 and TP10. I can search and find both. I then updated this to 6.1.5 and get the following error when searching TP1 [10] SELECT SQL_CALC_FOUND_ROWS `id`, `hits` FROM `CubeCart_search` WHERE CubeCart_search.searchstr = 'TP1' LIMIT 1; -- (0.000303983688354 sec) [NOT CACHED] [11] SELECT FOUND_ROWS() as Count; -- (8.98838043213E-5 sec) [NOT CACHED] [12] UPDATE `CubeCart_search` SET `hits` = '5' WHERE CubeCart_search.id = '1'; -- (0.0791778564453 sec) [NOT CACHED] [13] SHOW INDEX FROM `CubeCart_inventory`; -- (0.000940084457397 sec) [CACHE WRITE] [14] SHOW VARIABLES LIKE 'ft_min_word_len' -- (0.000609874725342 sec) [CACHE WRITE] [15] SELECT I.* FROM CubeCart_inventory AS I LEFT JOIN (SELECT product_id, MAX(price) as price, MAX(sale_price) as sale_price FROM CubeCart_pricing_group WHERE group_id = 0 GROUP BY product_id) as G ON G.product_id = I.product_id WHERE I.product_id IN (SELECT product_id FROM `CubeCart_category_index` as CI INNER JOIN CubeCart_category as C where CI.cat_id = C.cat_id AND C.status = 1) AND I.status = 1 AND (I.name RLIKE '[[::]]' OR I.description RLIKE '[[::]]' OR I.product_code RLIKE '[[::]]') ORDER BY Relevance DESC LIMIT 12 OFFSET 0 -- (0.00070595741272 sec) [CACHE WRITE] [16] SELECT I.* FROM CubeCart_inventory AS I LEFT JOIN (SELECT product_id, MAX(price) as price, MAX(sale_price) as sale_price FROM CubeCart_pricing_group WHERE group_id = 0 GROUP BY product_id) as G ON G.product_id = I.product_id WHERE I.product_id IN (SELECT product_id FROM `CubeCart_category_index` as CI INNER JOIN CubeCart_category as C where CI.cat_id = C.cat_id AND C.status = 1) AND I.status = 1 AND (I.name RLIKE '[[::]]' OR I.description RLIKE '[[::]]' OR I.product_code RLIKE '[[::]]') -- (0.00115895271301 sec) [CACHE WRITE] [1] 1: Unknown column 'Relevance' in 'order clause' [ERROR - CACHE WRITE] This is a virgin site, absolutely no mods, snippets or plugins. The only changes from stock, are the changes to ini.inc.php to get around the PHP 5.4 limilation and config.class from 6.0.12 Something must have changed in 6.1 that wasn't there in 6.0 Here is the search from a working 6.0.10 [25] SELECT `id`, `hits` FROM `CubeCart_search` WHERE CubeCart_search.searchstr = 'UG3' ; -- (0.0163061618805 sec) [CACHE WRITE] [26] UPDATE `CubeCart_search` SET `hits` = '1' WHERE CubeCart_search.id = '44901'; -- (0.000336885452271 sec) [NOT CACHED] [27] SHOW COLUMNS FROM CubeCart_customer_membership; -- (0.000882148742676 sec) [CACHE WRITE] [28] SELECT `group_id` FROM `CubeCart_customer_membership` WHERE CubeCart_customer_membership.customer_id = '19834' ; -- (0.000330209732056 sec) [CACHE WRITE] [29] SHOW INDEX FROM `CubeCart_inventory`; -- (0.000654935836792 sec) [CACHE WRITE] [30] SHOW VARIABLES LIKE 'ft_min_word_len' -- (0.000591039657593 sec) [CACHE WRITE] [31] SELECT I.* FROM CubeCart_inventory AS I LEFT JOIN (SELECT product_id, MAX(price) as price, MAX(sale_price) as sale_price FROM CubeCart_pricing_group WHERE group_id = 0 GROUP BY product_id) as G ON G.product_id = I.product_id WHERE I.product_id IN (SELECT product_id FROM `CubeCart_category_index` as CI INNER JOIN CubeCart_category as C where CI.cat_id = C.cat_id AND C.status = 1) AND I.status = 1 AND (I.name RLIKE '[[::]]' OR I.description RLIKE '[[::]]' OR I.product_code RLIKE '[[::]]') LIMIT 12 OFFSET 0 -- (0.141498088837 sec) [CACHE WRITE] [32] SELECT I.* FROM CubeCart_inventory AS I LEFT JOIN (SELECT product_id, MAX(price) as price, MAX(sale_price) as sale_price FROM CubeCart_pricing_group WHERE group_id = 0 GROUP BY product_id) as G ON G.product_id = I.product_id WHERE I.product_id IN (SELECT product_id FROM `CubeCart_category_index` as CI INNER JOIN CubeCart_category as C where CI.cat_id = C.cat_id AND C.status = 1) AND I.status = 1 AND (I.name RLIKE '[[::]]' OR I.description RLIKE '[[::]]' OR I.product_code RLIKE '[[::]]') -- (0.13321018219 sec) [CACHE WRITE] [33] SELECT SQL_CALC_FOUND_ROWS `array` FROM `CubeCart_config` WHERE CubeCart_config.name = 'category_product_options' LIMIT 1; -- (0.000521183013916 sec) [CACHE WRITE] [34] SELECT FOUND_ROWS() as Count; -- (0.000123023986816 sec) [NOT CACHED]

My 6.0.10 site doesn't have this limitation, so I'm guessing therefore that this is something to do with 6.1.5. I never noticed if 6.1.2 suffered the same issue.

The live site crimp connectors has no snippets or mods. A few plugs like PayPal and all in one shipping. That's it. Is it possible to reduce that search limitation to 3 characters.

I think it might be related to the length of the search string ?? eg, if I search for product_code R16 (it does exist), nothing comes back If I search for R16-BUTT (it also exists) then results come back. Also search for AT9, no results, AT97 works. Could 3 carachters be to few www.crimpconnectors.co.uk is the live site. Debugging is enabled if anyone wants to see. Search TR1 and then search TR10

With it being different, I wouldn't know which lines to add or take away. I also have a live 6.1.5 site and get a similar issue, only the error in debug is a little different. This live site (IIRC) is untouched virgin site. [13] INSERT INTO `CubeCart_system_error_log` (`message`,`time`) VALUES ('File: [catalogue.class.php] Line: [1760] \"SELECT I.* FROM CubeCart_inventory AS I LEFT JOIN (SELECT product_id, MAX(price) as price, MAX(sale_price) as sale_price FROM CubeCart_pricing_group WHERE group_id = 0 GROUP BY product_id) as G ON G.product_id = I.product_id WHERE I.product_id IN (SELECT product_id FROM `CubeCart_category_index` as CI INNER JOIN CubeCart_category as C where CI.cat_id = C.cat_id AND C.status = 1) AND I.status = 1 AND (I.name RLIKE \'[[::]]\' OR I.description RLIKE \'[[::]]\' OR I.product_code RLIKE \'[[::]]\') ORDER BY Relevance DESC LIMIT 12 OFFSET 0 \" - Unknown column \'Relevance\' in \'order clause\'','1487172183'); -- (0.00065803527832 sec) [ERROR - NOT CACHED] [14] INSERT INTO `CubeCart_system_error_log` (`message`,`time`) VALUES ('File: [catalogue.class.php] Line: [1760] \"SELECT I.* FROM CubeCart_inventory AS I LEFT JOIN (SELECT product_id, MAX(price) as price, MAX(sale_price) as sale_price FROM CubeCart_pricing_group WHERE group_id = 0 GROUP BY product_id) as G ON G.product_id = I.product_id WHERE I.product_id IN (SELECT product_id FROM `CubeCart_category_index` as CI INNER JOIN CubeCart_category as C where CI.cat_id = C.cat_id AND C.status = 1) AND I.status = 1 AND (I.name RLIKE \'[[::]]\' OR I.description RLIKE \'[[::]]\' OR I.product_code RLIKE \'[[::]]\') ORDER BY Relevance DESC LIMIT 12 OFFSET 0 \" - Unknown column \'Relevance\' in \'order clause\'','1487172183'); -- (0.00065803527832 sec) [ERROR - CACHE WRITE] Live site and troublesome v3 to v6 site are on different servers.

The git hub post refers to this being fixed in 6.1.2 or 6.1.3, this site is 6.1.5. ?? catalogue.class is slightly different than the one referred to in this github post, so I dare not start modifying it willy nilly. https://github.com/cubecart/v6/commit/55e2b4f2ee462a146c094670d1d04ac9cdc5d0ab

Back to this troublesome V3 to 6.1.5 site. I've noticed the first search for a product code comes back empty. with an error in debug [1] 1: Unknown column 'Relevance' in 'order clause' [ERROR - CACHE WRITE] [16] SELECT I.* FROM CubeCart_inventory AS I LEFT JOIN (SELECT product_id, MAX(price) as price, MAX(sale_price) as sale_price FROM CubeCart_pricing_group WHERE group_id = 0 GROUP BY product_id) as G ON G.product_id = I.product_id WHERE I.product_id IN (SELECT product_id FROM `CubeCart_category_index` as CI INNER JOIN CubeCart_category as C where CI.cat_id = C.cat_id AND C.status = 1) AND I.status = 1 AND (I.name RLIKE '[[::]]' OR I.description RLIKE '[[::]]' OR I.product_code RLIKE '[[::]]') ORDER BY Relevance DESC LIMIT 12 OFFSET 0 -- (0.000586986541748 sec) [CACHE WRITE] Any subsequent searches for that product_code are OK. Any pointers ?

Brian, the logs should be in your email. Incidentally, I'm happy that the upgrade copied all the data, just maybe didn't remove the UTF8 suffixed tables, as the site appears to work,

I've just jumped on the server and taken a quick look at the original V3, and all tables witch exception to one are latin1_swedish_ci, what ever that means. There is one table (cats_idx) which is UTF8 On one of the test updates, I took a sneaky look in PHP MYAdmin to see what tables were being created, and somewhere around V4 upgrade processes, I could see tables with a UTF8 suffix

I believe the originals are Latin Swedish.I could take a look in the morning as this is only a dummy run

There were about a dozen utf8 tables, all of which were empty. I performed a clean install and made a note of the database tables then compared against my updated site. The database user had full privileges. I can't see anything missing from the site. I seem to recall that my original site did this a year ago. I updated another v3 last week which is sitting on a different server and this has no rogue utf8 tables.

I know. I couldn't figure that out either. I did go back a few days and numerous hours after

<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Forbidden 403</title> </head> <body> <h3>Forbidden 403</h3> You are forbidden from viewing this directory. </body> </html> index.html is there in the V3, so I guess it copied over with the upgrade. Thanks

I've seen this a few times today when uploading an image Not enough memory to create thumbnail from `index.htm`. Please optimise this source image. The file is 12KB. Any thoughts v6.1.5

I've about 3 test sites on the go at the moment, one that I'm testing a few mods and plugins on, one that i'm using for testing a V3 upgrade and another that I'm using with BSmither, so I'm starting to lose track of which one is which. Although I'm pretty certain the scenario went like this. The site was on 6.0.12 and had a manual edit to the admin.php url It was upgraded to 6.1.4 last week, using the upgrade feature in Maintenence, I manually modified the admin.php back to its 6.0.12 url so the office staff could access it. It was upgraded to 6.1.5 yesterday, and I left the admin.php as per Cubecart had configured, only for some reason it didn't.

On the admin side, if I search for an order using 'Search Orders' and then select a date range of 1 day 'Nothing Found' comes back. If I search using an order number, the search results shows the order I searched for. And if I search via 'Customer Name' then every single order for every customer comes back. This is on a 6.0.10 and 6.1.5 site, both sites on the same server. Edit. If I search for a single day, No results are returned. If I search for 2 days, then only the first day is returned. If I search for 4 days, only the first 3 are returned.

This particular site has been messed with, updated, moved servers so many times, I'm not surprised that there would be errors. I re-ran the upgrade, but there are still a number of UTF8 tables. I'm now going to perform a clean install and compare.

I've restored a copy of the V3 and am running the upgrade to 6.1.5 again. The site was reporting it's self as 3.0.18 however, I've no idea how accurate this is, as all these V3's are hybrids. Could that make a difference ?

Site appears to work OK, although i've not put it in to production yet