bsmither

So, when the order was created, the state name was correct, but then at some time later, when viewing that Order Summary in admin, the state name shown on the Overview tab is not correct? In admin, Admin Activity, scan the list for anything that looks suspicious.

That's my question: where does the index name come from? Is it auto-generated the first time ElasticSearch builds the index? Does the hosting provider assign it? sack123, where did you get the value for 'es_i'? (Note: The forum will not let me use the '@' notifier -- it refuses to allow a post that was edited to use it get re-saved. I hope you see this.)

Sorry, I would not know. We will need to wait for Al or HavenSwift to advise.

I would think not. What you refer to is the access credentials to the MySQL database server. The mentioned $glob array elements for ElasticSearch would/should be different. If your site is hosted, and your host gives you a site management tool (such as CPanel), and if ElasticSearch is installed by your host, the access credentials to the MySQL database and ElasticSearch engine should have been emailed to you in your new subscriber "Welcome" notice, or, at least, these connection details would be shown somewhere in the management tool.

There is no legitimate way to do this. During setup, CubeCart looks at the language file definitions.xml, 'navigation' group, "seo_path_*" strings, and populates the database table CubeCart_seo_urls with records for the search, certificates, contact, register, recover, and login URLs. Also, certain redirects are created so that, for example, 'register.html' will bounce the browser to 'register'. (This is for a work-around for skins with hard-coded URLs.) However, another redirect can be created. In admin, Redirects & 404's, Redirects tab, the top row of the table allows to add a redirect from, for example: Page: Contact Us Redirect from: get-in-touch.html The web address "example.com/get-in-touch.html" can be used out on the inter-webs, and when CubeCart gets this, will bounce the browser to "example.com/contact-us". Sorry, you are asking for SEO Titles? That might be customizable in the Language Editor. Let me find it. Nope. Not there. The Contact Form allows to set a Meta Title. I thought a mod had been created to add meta data to these pages, but I cannot find it. Would you be interested in testing one?

This query comes from using the Quick Search text entry box or the Advanced Search page. Perhaps you were checking to see if the new products would show in a search? But for 700 times? (a pair of queries, one at line 1988 and one at line 1990) The term being searched on is "gQiz/**/ORDER/**/BY/**9977#", which looks to me like some joker is repeatedly feeding junk into the search box. Unless "gQiz" looks familiar? The error log should have the time the error took place. Are all the times really close together? And recent - as when you were adding products?

This data is provided to the skin. It just becomes necessary to figure out how to display it. Try this. Using a programmer's text editor, make the following edits to the template file element.navigation_tree.php: Lines 4,9, and 14, change this: {$BRANCH.name} To this: {$BRANCH.name} ({$BRANCH.product_count}) Have CubeCart clear its internal cache after saving this edit. This simply appends the product count in parentheses to the category name. Anything more than this may require some fancy CSS rule changes.

Was all of this put in place? https://forums.cubecart.com/topic/58270-photo-enlarge/ Especially the javascript edit? Looking at the GitHub issue #3202, it seems the javascript edit wasn't made.

There is a module that one can add custom 'common' stuff. Send me a PM with your email address.

Above, these images do not show what we need to see. Bring up the category "Powerball" for editing. Take a screen grab of the Search Engines tab. Bring up the product "Powerball" for editing. Take a screen grab of the Search Engines tab.

I am sure it could, as it seems most of the structure is already there - according to the description. But because Noodleman encodes the plug scripts, only Noodleman can make these changes.

The screen grab in the first post shows the View Category page - which, unless you implement a certain plugin, options for the products listed on a category page are not to be shown. Clicking on the product image or title is supposed to take you to the View Product page, but CubeCart is delivering the View Category page again. I would look at the product "Powerball" and category "Powerball" and determine which one is supposed to have that specific path on the Search Engine tab when editing a product or category.

As you describe it, it is odd. I have never seen this happen this way. Just to be clear, when entering terms to search in the "Quick Search" text entry box, the magnifier icon is what is getting clicked on to submit the search? But not clicking on the link that says 'Advanced Search' located just below the text entry box?

In CC652, the Foundation skin was coded to show traditional pagination - a series of page numbers, but only for when the page is not on a mobile device. If on a small screen (that is, mobile), then the More button is used. But if the store owner wants to use the More button on wide screens, CC652 now uses a cookie that lasts for 10 minutes to store where in the scroll the browser was last showing. So, let us know what skin if not using Foundation, and what version of CubeCart if using Foundation. (Please see GitHub issue #3344.)

Yes, there have been some changes in the javascript plugin 'DropZone', that when an image is dropped onto the zone, the image is resized at the browser - thus reduced in size - then uploaded to the server where CubeCart will accept the uploaded image. The point of this is to make sure the image is below the filesize threshold (used to be limited at 350kB). But, in resizing, the javascript changed all images to a jpg type. I *think* this was changed to webp recently because jpg images does not do transparency, but webp does. (I am not 100% sure of the final resolution on this. The reason for the filesize limit is because the filesize implies image dimensions. When creating specific-sized variants, PHP's GD Image Library decompresses the image to work on it. The image's decompressed size in memory could - and has - exhausted the memory in PHP's operating environment.)

If so, then using a programmer's text editor, in the file /classes/catalogue.class.php: Near line 1990, find: $indexes = $GLOBALS['db']->getFulltextIndex('CubeCart_inventory', 'I'); Change to: // $indexes = $GLOBALS['db']->getFulltextIndex('CubeCart_inventory', 'I'); Near line 1786, find: $original_search_data = $search_data; After that line, add this: $indexes = $GLOBALS['db']->getFulltextIndex('CubeCart_inventory', 'I'); This edit just moves the statement to a place above the hook call. A Code Snippet will be used to add a column of the Inventory database table to search for keywords. In admin, Manage Hooks, Code Snippets tab, click the Add Snippet link. When the Snippet form appears, enter: Enabled: checked Unique ID: add_search_columns@CC6 Execution Order: 1 Description: Adds more text columns to search on the CubeCart_inventory table. Trigger: class.catalogue.pre_search Version: 1.0 Author: https://forums.cubecart.com/topic/58751-including-product-identifiers-in-search-results-upc-isbn-jan-mpn-etc/ PHP Code: <?php /* Specify the name of the column, * with 'I' table identifier, * of the CubeCart_inventory table * to search for keywords. */ $indexes[] = 'I.gtin'; Save. Test.

Quick question: are you able to make a small edit to the core code?

I'm taking a good look at how the Search happens, planning how to best use a Code Snippet to get another database table column searched. So, still working on this.

So, if the product's description made mention that this card/player is associated with the Cincinnati Bengals, how would CubeCart's search not find this? I assume, then, that for good reason, the description will not or cannot make this mention. Maybe using GTIN is a more broadly appropriate solution? I am also thinking of a different solution -- changing the columns that CubeCart searches in. The first search looks in the aggregate of the product code, product name, and description. If a (rather weird) search fails to find results, a second search is made against whole words that might be found in any of these columns. If that fails, a third search is made using the given string of characters that might be found as a part of any word in any of those columns. The current problem is that the first search uses the columns declared as a group (fulltext), but the second and third search uses hard-coded names of columns. The idea is to change the FULLTEXT search group to include GTIN. This action must be performed directly against the database. To solve the problem mentioned above, there must be some edits to the code. Creating a Code Snippet is better than this solution. I will be back later with a suggested snippet.

Let's look at Advanced Search. This page gets populated and rendered in the CubeCart->_search() private function. This function gathers certain information, prepares it if necessary, and assigns it to respective template variables. Currently, the only info that needs to be prepared is the list of manufacturers (and maybe a list of sort choices). There is a hook allowing to gather and process more info to be shown on a customized template. The search parameters get POSTed to the CubeCart->_category() private function. The search term(s) get logged in the Search Log. (See in Admin, Statistics.) In this function, the search parameters are passed to the Catalogue->searchCatalogue() function. Right at the start of searchCatalogue() is a hook allowing to add more search parameters. For example, a new search parameter might be: $where[]="I.isbn='978-1-890774-44-8'"; One needs to figure out how to get a search term and the database table and column identified. One suggestion is to enter a term that looks like: "ISBN::978-1-890774-44-8" The code would explode() the string on the '::' to an array, list() the array elements to $custom_key and $custom_value, and finally: $where[] = "I." . strtolower($custom_key) . "=" . $custom_value; Looking at columns in another table is a bit more involved by pushing strings onto the $join array. The search code should continue with appropriate results retrieved from the database. The mentioned hooks are the tools you use to get CubeCart to do what you want. And in Admin, Manage Hooks, Code Snippets tab is where these tools are created.

This was fixed in CC6.2.4: see the GitHub issue #2187. https://github.com/cubecart/v6/issues/2187

Please think about doing this: Keep the product record for the product that is no longer available, but set its Status to unchecked. Clone that product to a new product record, make appropriate changes, save. (The parts of the source product for cloning can be selected in Store Settings, Extra tab.) This keeps the sales records straight. This strict bookkeeping might not be important to you now, until it does. Keep the 404 result, but give some consideration to enhancing the 404 skin template to say, "That item has been sold, but view this category for similar products." * I would say to redirect from the product's seo path to the category's seo path, but there is something stopping this from happening.

Version 1.0.6 says: "Custom Order Status now offers a new setting: "Count As Unsettled Order". When enabled, the custom status is counted (included?) in the Unsettled Orders tab of the CubeCart dashboard."

This is not 'hacking'. (It is an unfortunate choice of word, but) In this context, it is a term to mean "time hack", as when marking the time from a timer or stop watch. The value after the work 'Hack' is the UNIX Time value -- number of seconds since 12:01am, January 1, 1970 (including microseconds after the decimal point). Technicians assigned to troubleshoot slowdowns or bottlenecks will use these values to determine where and what took a long time to get from one database query to the next.

A very brief run of the storefront and admin dashboard shows that CC6114 has preg_replace() issue. See the Github issue #2220. But, since you are running this under PHP 7.0, you should have already made that fix.