Jump to content

bsmither

Member
  • Posts

    17,084
  • Joined

  • Last visited

  • Days Won

    565

bsmither last won the day on September 13

bsmither had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Pacific Coast

Recent Profile Visitors

95,780 profile views

bsmither's Achievements

Experienced

Experienced (11/14)

  • Well Followed Rare
  • Very Popular Rare
  • Conversation Starter Rare
  • Dedicated Rare
  • First Post

Recent Badges

1.5k

Reputation

  1. By looking at the list of SQL queries in the debug section, it can be determined which method CubeCart finally used: whether there are one, two, or three search queries. The first will be a query, if present, will have the word RELEVANCE in it, the second, if present, will have the word RLIKE in it, and the third, if present, will have the word LIKE in it. (There will also be several queries that have LIKE in them but searching against the CubeCart_manufacturers table. Ignore these.) There is a preliminary test that asks the database what is the minimum number of letters that the shortest search term must have. It will be this query: SHOW VARIABLES LIKE 'ft_min_word_len' The answer is usually 4. So, because at least one of the search terms is less than 4 characters, the RELEVANCE query won't be executed and you won't see it in the list of queries. Instead, CubeCart will skip that and go to RLIKE. Since TAR is a whole word, the search using RLIKE succeeds. Then, you remove the whole word TAR from the description, and now CubeCart uses LIKE which will find 'tar' as part of any word. I cannot explain why the results include obvious non-matches. However, the LIKE query is permitted to use the query cache. So, if there was a recent instance where the data for product_id 7817 (aka TR21-W) did include a word containing 'tar', then maybe we see this because of a cached recordset from an earlier search on 'tar'. We would have to explore your database directly.
  2. The Foundation Vertical Menu mentioned is for Foundation 6 -- not compatible with Foundation 5 that CubeCart uses. The JqueryUI example is intended to show the action - not the styling nor the content. I will play with it and figure out how to integrate it.
  3. Otherwise, we can try this: https://jqueryui.com/accordion/#collapsible
  4. If you are referring to modifying Foundation, then, as an example, you can see Dirty Butter's site (highly customized but still based on Foundation) on the WayBack Machine: https://web.archive.org/web/20190722090647/https://dirtybutter.com/plushcatalog/ I think she used SemperFi's "Vertical Navigation Box". (No longer available, commercially.) Or are you asking about doing this on your existing site?
  5. CubeCart has three methods to ask the database on how to formulate a query: Fulltext Relevance - if nothing found, then REGEX on word boundaries - if nothing found, then REGEX anywhere - if nothing found, then say "No products found." Fulltext Relevance is a somewhat complicated method to explain. Basically, if too few results are returned, the term(s) must not be all that important. If too many results, then the term(s) must not be all that unique. There are nuances. Word boundaries will find whole words. 'TAR' will find "TAR 735" but not "TAR735". Anywhere will find the sequence of characters in "TAR", "TAR367", "STAR-BRIGHT", etc. By looking at the list of SQL queries in the debug section, it can be determined which method CubeCart finally used: whether there are one, two, or three search queries. Several store owners have edited the searchCatalogue() function definition so that the default method is $search_mode = 'rlike', skipping the 'fulltext' method.
  6. Literally, the change involves replacing a digit (1) with the name of a variable ($page). This edit cannot have caused a white screen. Depending on the text editor used, the editor may be doubling the line endings, making the file double spaced. Thus, line 1941 becomes 3882. Do you recall seeing double spacing in the editor you used?
  7. FYI: I now completely understand the nature of this scenario. I was able to reproduce it and have traced the code where the mistake is being made. I am working on a solution: so that this doesn't happen in the future, and to create a 'fix-it' code snippet to solve all existing shopping baskets that suffer this situation.
  8. Please try this edit. In /classes/catalogue.class.php: The line numbers may be slightly different... Lines 1941-1943, find: } elseif ($search_mode == 'fulltext') { return $this->searchCatalogue($original_search_data, 1, $per_page, 'rlike'); } Change to: } elseif ($search_mode == 'fulltext') { return $this->searchCatalogue($original_search_data, $page, $per_page, 'rlike'); } Lines 1998-2000, find: } elseif ($search_mode=="rlike") { return $this->searchCatalogue($original_search_data, 1, $per_page, 'like'); } Change to: } elseif ($search_mode=="rlike") { return $this->searchCatalogue($original_search_data, $page, $per_page, 'like'); }
  9. Searching BPM. I see that the web address indicates that page=2 has been requested, but yes, the twelve results are the same as shown on page 1. Clearing CubeCart's internal cache had no effect. Asking for a sorted list (Price Low-High) got the twelve lowest priced products. Page=2 got the same products. I had a suspicion that the database is resisting in some fashion having to search on a three or less letter search term. The term UNF seems to work, but GRN has only one row returned in the resultset. GRN1 has 12 in the predicted search popover but shows only the two products where "GRN1" is the actual product code. So, I cannot see that there is a fault in the building of the query - specifically calculating the solution to 'per-page' multiplied by 'page-1'. (That is, for page=2: 12x1=starting at the 12th row in the resultset for 12 rows.) There must be a fault in the construction of the wildcards used in the REGEX query sent to the database. Examining the queries that CubeCart sends to the database would be helpful. In admin, Store Settings, Advanced tab, enable Debug Mode. Enter your local IP address in the following text field (www.showmyip.com). Save. Search for BPM. Go to page=2. At the bottom of the screen will be some diagnostic info. Specifically, all the queries sent to the database. Copy and Paste that list of queries into a Private Message to me.
  10. In the PayPal Commerce plugin, there is a hook file named 'controller.index.php'. This hook code creates and registers a Smarty output filter. (An output filter can add, edit, and delete content from rendered sources, usually skin templates.) I assume this output filter is required for displaying PayPal stuff on the PayPal skin template when checking out, but the Smarty output filter also seems to be applied to any and all rendered templates universally, including email templates (the HTML component only). Then, the MailScanner utility catches the email, sees the <script> tag, and disarms it. The result is visible text. CubeCart's email templates do not have the target of the javascript generated by this hook, so it's not necessary. But, as an output filter that is instantiated at 'controller.index', the action this hook provides will get applied to unintended content. Resolving this will require the CubeCart programmers to come up with a solution: possibly testing for what will be using the output filter, or using different hooks. As for MailScanner, according to the documentation posted above, it is unfortunate that there is no choice to 'remove' script tags and the inner content.
  11. When you "click to the next page", do you actually get a new page, with the CubeCart header, sidebars, footer, but an empty main content area? Or is it a just a completely blank white screen? Or when you say "nothing happens" and "does nothing", are you saying that when clicking on the link, there was no effort by the browser to issue a request for a new page? Please remind us of the web address for the site.
  12. Please edit the Mobile skin template content.orders.php: Near line 34, find: <div><label for="lookup_order_id">{$LANG.basket.order_number}</label><span><input type="text" id="lookup_order_id" name="cart_order_id" value="" /></span></div> Change to: <div><label for="lookup_order_id">{$LANG.basket.order_number}</label><span><input type="text" id="lookup_order_id" name="cart_order_id" value="{$ORDER_NUMBER}" /></span></div>
  13. You said (post #3): "It's always passed when I try to recreate the issue." Also, "If I add an item to the basket that doesn't yet contain a matrix entry, then go back and create a matrix entry, this matrix entry is never populated in the basket." So, there exists the frequent scenario whereby a product has been made available for purchase, but has yet to have its Options Matrix table data fully populated (missing product codes). And that product has been put in shopping baskets, but the order has not yet been transacted. Having looked at the sequence of events during checkout, I recall where all the products are 'verified'. I'll see if, during this verification of the contents, the product code is included.
  14. This is found in an email received by the customer? It looks like javascript that would be found in the PayPal plugin module. If possible, look at the plain text component of the received email. (Granted, that might be a feature of the email program you use that simply isn't available.) If not, you should be able to look at the email's raw source. Does the rogue content also appear in the plain text component?
×
×
  • Create New...