bsmither

Scanning through the XML file posted earlier, I see several URLs that are in the /store/ subdirectory, and the /quickbooks-pos-imported-inventory/ subdirectory. These obviously are vestigial remnants of an earlier crawl. One other URL has me puzzled, however: /r45-htlo.html This was last seen 3/22 and then not seen 3/22.

Are we assuming this report is the direct result of having Google crawl (verify) your site from the sitemap most recently given to it? Or can we guess that this report is NOT from a direct result of having Google verify from the most recent sitemap, but rather an aggregation of 're-verification' checks to make sure what was found earlier is still there? If the latter, then it would seem to me that the appropriate response would be to tell Google to delete everything it has ever crawled from that site and then to make a fresh crawl, indexing only what is in the sitemap located at the store.

The "Shop by Category" reference is the default title of the sidebox of nav links on skins designed for CC5 (which still work with CC6). It is not a "file", per se. You can see this in the MarketPlace. The Foundation skin does not use a title for the top menu bar. A 'title' would be what you see in the "Best Sellers" box, or "Featured Product" box. CubeCart uses a template rendering engine that will cache compiled templates - needing only then to fill in the variables with values. When making edits to templates, you will need to clear the cache of already compiled templates. One way to do this is in admin, Maintenance, Rebuild tab, check Clear cache, click Submit. Another way is to make the browser request this URL: www.store.com/index.php?debug-cache-clear=true

The 'top menu' is the "Navigation" bar (or sometimes "Shop by Category" box). The menu is built from all the categories (enabled and unhidden) there are. There are also three special items: Home, Sale Items, and Gift Certificates. To add any other links to this group would require editing the skin template "box.navigation.php".

If I use the URL for that product from the XML file I downloaded from the link posted earlier, I do get that product. The XML file has this as the URL: www.csrocketry.com/recovery-supplies/skyangle/deployment-bag/xxlarge-skyangle-deployment-bag.html What would be another bad URL from that XML file?

The sitemap to which you posted a link a few posts back? That site map has only one instance of "xxlarge-skyangle-deployment-bag.html" (line 5784).

" Some of those changes are months old " Such as the one we are just now exploring? You may have to tell the search engines to completely drop prior crawls and/or sitemaps, then give them a fresh sitemap. I am not one to answer questions about SEO.

If you cleared all SEO links from admin, Maintenance, then this issue in the Github may explain what is happening. On the other hand, a search for skyangle includes this product: www.csrocketry.com/recovery-supplies/skyangle/deployment-bag/xxlarge-skyangle-deployment-bag.html Note that the category's seo_path has been prepended to the product's seo_path.

As there is no console to select what gets in the map and what doesn't, your quickest solution is to manually edit the XML file. But, the code that makes the sitemap will check to see if the store sale mode is not off, and if not in the global sale mode (leaving per product), then include the link. But you say the sale mode is off, so there should be no link.

Please send a PM with your email address.

Yes.

With regards to "Admin" appearing in the login field, when that happens, have the browser show you the HTML source it has received. Assuming there is nothing changing the source between CubeCart and the browser, the source will show us if "Admin" is actually the value of the text entry field. If the value of that field is blank (like it is suppose to), then we need to look at some browser feature interfering.

I will try to find the conversation where I suggest an alternate approach. The maximum value is the longest side -- not to be assumed this is "width". A number of checks would need to be edited in the core code. That limit is in place because when editing a compressed file (JPG, PNG, GIF), the entire file needs to be loaded into memory - uncompressed. Depending on how well (or not) the image was compressed, a 350K file could decompress into memory exceeding what memory can be allocated to the task. PHP then crashes. So, a 800x800 image that is nearly uncompressable may result in a file that is approaching 350K.

The optimal size is the largest size specified in the skin's config.xml file. For Foundation, an image 600px on the longest side is optimum. But be sure the filesize is 350K or less. CubeCart uses PHP's GD library to resize the image, saving the resized images in the cache. As for the image being cut off, there is a conversation that mentions an alternate approach to preventing the image gallery from jumping up and down. The current attempt doesn't work so well, IMHO.

The CubeCart template file "box.basket.php" is really standard HTML code. There is no PHP code in it. So, if your browser calls for this file directly, you will get whatever HTML is in the file. However, a standard web page makes use of resources: images, CSS, javascript. The code to have the browser request these resources would need to be added. Then, in the template code are extra things that are understood by the template rendering engine. This will populate variables with the values, evaluate conditions, and iterate through loops. So, in short, yes, you can create a PHP script that will render the box.basket.php template.

This is very weird. Please create the error_log. https://forums.cubecart.com/topic/51550-how-to-create-the-error-log/

Calling for that script should get you a screen that looks far different than the pictures posted. This is Cubecart's demo store: https://www.cubecart.com/demo Click the link to the administration and note the page design. If you do not get this page, then maybe the web browser is faulting with a 404, and if the .htaccess file specifies a certain CubeCart page to show for 404 situations, that may be why you are not getting what is expected.

An install of CC615 would have named the administration script something like: admin_aBcDeF.php Are you requesting that script? You say the storefront page reloads with the word Admin in the text field asking for the email address. CubeCart doesn't do that. A failed login gives you a red banner and empty text entry fields for Email Address and Password. Note, however, a fresh installation does not have any customers, so trying to login using your admin credentials on the storefront will not work. Does your browser have any sort of form auto-fill add-on?

You would get a different error message if CubeCart was not able to open communications to the database server. Such as not having the mysql or mysqli functions to use, or the database server not being where the globals.inc.php file says it is. Also with not having the correct name of the database to use. You might get a different error message if the database server has not given permission for the user/pass to access the name of the database. The error you did get has been seen when making queries to the database has been denied for some reason. Sometimes when the database server has been overloaded. So, in your hosting account's control panel (Cpanel?), make sure you have the correct database URL (probably not 'localhost') and your user/pass is correct. You say you have an existing store online? Check the globals.inc.php file for that store.

This is my very initial guess at changing this. The reason this ends up looking like it does is because another fix was needed to stop crashes in other situations. In /controllers/controller.index.inc.php, near line 38, find: //Initialize language $GLOBALS['language'] = Language::getInstance(); //Initialize hooks $GLOBALS['hooks'] = HookLoader::getInstance(); //Initialize SSL $GLOBALS['ssl'] = SSL::getInstance(); //Initialize SEO $GLOBALS['seo'] = SEO::getInstance(); if (isset($_GET['seo_path']) && !empty($_GET['seo_path'])) { $_GET['seo_path'] = preg_replace('/(\/\~[a-z0-9]{1,}\/)/', '', $_GET['seo_path']); // Remove /~username/ from seo_path $GLOBALS['seo']->getItem($_GET['seo_path']); } Change to: //Initialize hooks $GLOBALS['hooks'] = HookLoader::getInstance(); //Initialize SSL $GLOBALS['ssl'] = SSL::getInstance(); //Initialize SEO $GLOBALS['seo'] = SEO::getInstance(); //Initialize language $GLOBALS['language'] = Language::getInstance(); if (isset($_GET['seo_path']) && !empty($_GET['seo_path'])) { $_GET['seo_path'] = preg_replace('/(\/\~[a-z0-9]{1,}\/)/', '', $_GET['seo_path']); // Remove /~username/ from seo_path $GLOBALS['seo']->getItem($_GET['seo_path']); } The above has been tested only to show that after the customer changes to a different language, the URL is still "friendly".

Actually, try this new statement: if(empty($word) && !is_numeric($word)) continue;

Well, I was writing up a nice report and hit the wrong key. Ugh! if (!empty($search_data['keywords'])) { $searchwords = preg_split( '/[\s,]+/', $GLOBALS['db']->sqlSafe($search_data['keywords'])); foreach ($searchwords as $word) { $searchArray[] = $word; } Change to: if (!empty($search_data['keywords'])) { $searchwords = preg_split( '/[\s,]+/', $GLOBALS['db']->sqlSafe($search_data['keywords'])); foreach ($searchwords as $word) { if(empty($word)) continue; $searchArray[] = $word; } That was one too many times I hit the wrong key and lost the entire composition. Never again am I composing a post in a web-based editor.

The FULLTEXT mode works: SELECT I.*, MATCH (I.product_code,I.description,I.name) AGAINST('BlahBC ' IN BOOLEAN MODE) AS Relevance 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 (MATCH (I.product_code,I.description,I.name) AGAINST('BlahBC ' IN BOOLEAN MODE)) >= 0.5 AND ((I.use_stock_level = '0') OR (I.use_stock_level = '1' AND I.stock_level > 0)) ORDER BY Relevance DESC LIMIT 12 OFFSET 0 Note the BlahBC<space> in apostrophes. The next test is to force the code to use RLIKE mode. The RLIKE mode did not work, but the LIKE mode did. If RLIKE failed, CubeCart is supposed to retry with LIKE. The LIKE mode worked. What went wrong? Looking.

To clarify: searching on my local debugging store worked. I did not search your store.

What you see in the skin code is so that, after plugins use hooks in the /classes/ code to add their results, there is now the means of displaying this additional data if any exists. The hooks and plugins do not assign any data directly into $DOCUMENTS_LIST_HOOKS (technically, they can, but that's bad programming), but rather indirectly through the hook that listens for plugin code. There is nothing bad that will happen if your skin has that code and $DOCUMENTS_LIST_HOOKS is empty. But if not empty, and the code isn't there, you will be missing out on what the plugin is providing.