KirkM Posted August 15 Share Posted August 15 (edited) A strange issue has started to appear in the menu system of the store. It hadn't been touched for a while (6.5.3), and suddenly the menu system started throwing these long, convoluted urls that of course resulted in 404 errors. ALL of the other links on the page work fine with the proper SEO url rewrites. It is ONLY the menu system. Even the little home page button on the menu bar throws those bizarre urls, when it should just go to the base domain. I upgraded to 5.5.6, but that didn't help. I have tried all kinds of things and each time it has been temporarily "fixed" by a different solution. Once it was dumping and rebuilding the .htaccess file, another time it was turning off mod_security on my server, another it was changing the SEO settings in the store, clear the cache and set them back and clear the cache again. Another time it was manually going in and completely dumping the entire contents of the cache folder. Each of those worked exactly once. Now, nothing seems to work. It can be seen at https://anabolnaturals.com Any ideas would be greatly appreciated. Here is my .htaccess file: ##### START CubeCart .htaccess ##### ### GZIP Compression ### <ifmodule mod_deflate.c> AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript </ifmodule> ### Files Expiration ### <IfModule mod_expires.c> ExpiresActive On ExpiresByType text/html "access 0 seconds" ExpiresDefault "access 7 days" </IfModule> ### File Security ### <FilesMatch "\.(htaccess)$"> Order Allow,Deny Deny from all </FilesMatch> ### Apache directory listing rules ### DirectoryIndex index.php index.htm index.html IndexIgnore * <ifModule mod_headers.c> Header always append X-Frame-Options SAMEORIGIN </ifModule> ### Rewrite rules for SEO functionality ### <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / ##### START v4 SEO URL BACKWARD COMPATIBILITY ##### RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule cat_([0-9]+)(\.[a-z]{3,4})?(.*)$ index.php?_a=category&cat_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule prod_([0-9]+)(\.[a-z]{3,4})?$ index.php?_a=product&product_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule info_([0-9]+)(\.[a-z]{3,4})?$ index.php?_a=document&doc_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule tell_([0-9]+)(\.[a-z]{3,4})?$ index.php?_a=product&product_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule _saleItems(\.[a-z]+)?(\?.*)?$ index.php?_a=saleitems&%1 [NC,L] ##### END v4 SEO URL BACKWARD COMPATIBILITY ##### RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !=/favicon.ico RewriteRule ^(.*)?$ index.php?seo_path=$1 [L,QSA] </IfModule> ### Default store 404 page ### ErrorDocument 404 /index.php ## Override default 404 error document for missing page resources ## <FilesMatch "\.(gif|jpe?g|png|ico|css|js|svg|webp)$"> ErrorDocument 404 "<html></html> </FilesMatch> ##### END CubeCart .htaccess ##### Edited August 15 by KirkM Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted August 15 Share Posted August 15 This can happen (I've not seen it for years) when CubeCart caches the URL and path when accessed from incorrect URLs like a hosting temporary URL or alias. I'd suggest three things. 1. Get rid of the "temporary" URLs designed for uses to access your website before the main domain has propagated. 2. Add some code to the htaccess for a permanent redirect from all the URLs you don't want to your main one. It's best to do that by redirecting when the URL doesn't match your desired one. 3. In the includes/global.inc.php file set two values $glob['rootRel'] and $glob['storeURL'] with values like /store/ and https://www.example.com/store respectively. Quote Link to comment Share on other sites More sharing options...
KirkM Posted August 15 Author Share Posted August 15 Thanks Al. I had moved the domain 301 forwarding of two aliases to the registrar level recently from my Plesk server panel and that may have been the issue. I pointed them back to my own name servers and re-created the aliases, re-issued the SSL cert to cover everything and it is back working... for now. Hopefully, that is the problem and this will make a final fix on it. Appreciate the quick response. Quote Link to comment Share on other sites More sharing options...
KirkM Posted August 18 Author Share Posted August 18 This popped up again. I added the two $glob values and cleared the cache and it came back up. This issue keeps returning. We should be able to alias alternate domain names in 301 redirect without it breaking the SEO rewrite or having to do a bunch of code gymnastics. Who doesn't have alternate domain names to capture alternate spellings or other user mistakes? That should be assumed in the store code architecture. I have dozens of other domains with multiple aliases plus SEO rewrites that aren't shopping carts and have never had any issue. What is really puzzling is that I have had multiple domains aliased to this CC store for YEARS and never had this menu problem. Did something change in the 6.5.x versions? Never got it all the way up through 6.4.7. Also, with all due respect, that caching system is not my favorite. Is there a way to turn it off? I'd rather lose speed than deal with the headaches it causes. Thanks Quote Link to comment Share on other sites More sharing options...
bsmither Posted August 18 Share Posted August 18 I think this is not an issue with domain aliases. I see {$ROOT_PATH} getting corrupted somehow. In the template main.php, at the end of the file, add {DEBUG}. In the template box.navigation.php, at the end of the file, add {DEBUG}. Call up the homepage. The browser will want to open a popup window. Let it. (You may need to refetch the homepage.) Now that you have the popup window(s), restore the files from these edits. In the popup window(s), in the left pane, find every instance the variable $ROOT_PATH. Note the value. Are they different from each other? Are they really strange? Could you switch off "Accordion Panel Magic 3" for a brief moment? Quote Link to comment Share on other sites More sharing options...
bsmither Posted August 18 Share Posted August 18 Are you using Dreamweaver? Quote Link to comment Share on other sites More sharing options...
bsmither Posted August 18 Share Posted August 18 (edited) I think it has to do with the Smarty plugin 'combine', where it calls CSSMin::minify() using $dirname that (probably) contains the server's root path, as opposed to the domain's httpdocs path. In the combined CSS file, the set of CSS rules that pertain to the Chosen feature have wrong background:url("path") values. (A clue!) In admin, Store Settings, Advanced tab, set "Enable Caching" to 'Disabled'. Edited August 18 by bsmither Quote Link to comment Share on other sites More sharing options...
KirkM Posted August 18 Author Share Posted August 18 47 minutes ago, bsmither said: Are you using Dreamweaver? Yes. 15 minutes ago, bsmither said: In admin, Store Settings, Advanced tab, set "Enable Caching" to 'Disabled'. Thanks. I looked right at that and didn't see it. 20 minutes ago, bsmither said: I think it has to do with the Smarty plugin 'combine', where it calls CSSMin::minify() using $dirname that (probably) contains the server's root path, as opposed to the domain's httpdocs path. In the combined CSS file, the set of CSS rules that pertain to the Chosen feature have wrong background:url("path") values. (A clue!) So would the $glob['rootRel'] and $glob['storeURL'] additions fix this? It has been working since I added them so far, but every "fix" works temporarily and then it starts again. Quote Link to comment Share on other sites More sharing options...
bsmither Posted August 18 Share Posted August 18 I recommend that one does not use Dreamweaver. (Disclaimer: last time I used it with any seriousness was, like, 20 years ago, and not proficiently, at all. I understand later versions got better, but I still do not trust it to not muck up things.) The file ini.inc.php, lines 143-155, will use these $glob array elements only when the page requested is not using the SSL protocol. The constants are defined accordingly, then the appropriate $GLOBALS are assigned. So, no, I don't think that made a difference with this problem. In addition to all the Category links in the Nav bar, even the Sale Items is corrupted -- and that URL is constructed from some other core function of CubeCart. It will be interesting to see what the differences in the generated HTML page actually are when caching is switched off. Quote Link to comment Share on other sites More sharing options...
KirkM Posted August 18 Author Share Posted August 18 16 minutes ago, bsmither said: even the Sale Items is corrupted I haven't seen that. I checked all of the links every time it happened and the ONLY rewrite issue was in the menu. Featured products, sale items, etc. always worked for me when the menu went sideways. Quote Link to comment Share on other sites More sharing options...
bsmither Posted August 18 Share Posted August 18 Sorry, I meant the Sale Items link on the Nav bar. Quote Link to comment Share on other sites More sharing options...
KirkM Posted August 18 Author Share Posted August 18 19 minutes ago, bsmither said: I recommend that one does not use Dreamweaver. (Disclaimer: last time I used it with any seriousness was, like, 20 years ago, and not proficiently, at all. I understand later versions got better, but I still do not trust it to not muck up things.) I hand code and DW just is convenient for structure, organization and ftp uploading. It isn't anything like what it was that long ago. I have used it for decades and it is now quite good and very handy for app development and coding. I guarantee you the issue isn't with DW. 2 minutes ago, bsmither said: Sorry, I meant the Sale Items link on the Nav bar. When the nav bar goes sideways, NOTHING up there works. Not even the home page icon. It should simply be the base url of the domain, but this issue even manages to mess that up. Quote Link to comment Share on other sites More sharing options...
bsmither Posted August 18 Share Posted August 18 (edited) I had looked at just the Nav bar. (True, links to the products were good.) I wonder what the category breadcrumb link would have been when viewing a product. Now that you have switched off caching, the Combine function is no longer in play. Even the Chosen CSS rules are no longer corrupted. Edited August 18 by bsmither Quote Link to comment Share on other sites More sharing options...
KirkM Posted August 18 Author Share Posted August 18 9 minutes ago, bsmither said: I wonder what the category breadcrumb link would have been when viewing a product. If you searched a product when the nav bar was whacked, it would be fine and the breadcrumb path was correct. In fact, everything worked fine for both SEO urls and the breadcrumbs other than the nav bar. If you used the menu and got the 404 error, I don't think it generated anything. Not completely sure about that, though. I can check it next time but I am hoping there isn't going to be a next time. Quote Link to comment Share on other sites More sharing options...
bsmither Posted August 18 Share Posted August 18 "and the breadcrumb path was correct" The sequence of breadcrumbs may have been correct, but when one hovers the mouse of a category showing as a breadcrumb element, the web address of the category link would be shown at the bottom of the browser window. Quote Link to comment Share on other sites More sharing options...
KirkM Posted August 18 Author Share Posted August 18 Another thing I noticed is the skin is still caching. I FTP'd in with Fetch and deleted all the cache files, including the skin folder's files and the store is back caching them again. It isn't caching the general files. Is the skin caching detached from the overall caching feature? Quote Link to comment Share on other sites More sharing options...
bsmither Posted August 18 Share Posted August 18 (edited) All of the files in /cache/skin/ are skin templates in a 'compiled' state, but not yet populated with data. Compiled means the the templates have been converted to executable PHP code that will iterate through loop structures, make decisions as to what will show, etc. Smarty (at least for me) will re-compile a template when it determines the code of a template has changed. In my opinion, CubeCart does not enable Smarty to cache finalized output. Edited August 18 by bsmither Quote Link to comment Share on other sites More sharing options...
KirkM Posted August 18 Author Share Posted August 18 I'll take your word for it. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.