SimChris Posted October 11, 2014 Share Posted October 11, 2014 Warning: Could not change cache path (/var/www/vhosts/sitename.com/httpdocs/ecom-old/cache/) in /var/www/vhosts/sitename.com/httpdocs/ecom-old/classes/cache/file.class.php on line 197 Hi, trying to change directory for CC5 from "ecom" to "ecom-old" and ran into one issue (above). I have emptied cache, and also cleared the cache folders of temp files. /cache/* (except for htaccess deny all file) /cache/skin/* as above. Not sure where the writable file would be that doesn't have permissions or whatever to update the cache path. Any suggestions would be very much appreciated. Thanks :-) Basically cannot login to admin --- warning pops up as response to login attempt at new location. Quote Link to comment Share on other sites More sharing options...
bsmither Posted October 11, 2014 Share Posted October 11, 2014 First, try clearing the browser's cookies for your domain. Second, we can try to find out which of the three possible triggers CubeCart is flagging this error. In /classes/cache/file.class.php, line 197:Was: trigger_error('Could not change cache path ('.$path.')', E_USER_WARNING); Now: $because = ' '; if(!is_dir($path)) $because .= 'is not a dir, '; if(!file_exists($path)) $because .= 'does not exist, '; if(!is_writable($path)) $because .= 'is not writable, '; trigger_error('Could not change cache path because '.$path.$because, E_USER_WARNING); Quote Link to comment Share on other sites More sharing options...
SimChris Posted October 12, 2014 Author Share Posted October 12, 2014 Howdy ... okay, cleared browser cache fully; added above lines to file; and yes (doh), the cache folder was not writable. Changing that to writable, now gives me the dread blank white screen for both the index.php and admin.php?_g=login ... hold on, let me try it the way you suggested ... just in hopes that won't break it ... just renaming the original folder vs cloning it ... okay... that worked... renaming /ecom/ to /ecomold/ works for admin login, and presumably to get the /ecom/index.php to work for visitors, I'd need to update the store URLs in the store setup, which I am *not* going to do on live site right now. Hmmmm..... okay. I think I can wrangle that. For some reason "cloning" the folder and renaming it didn't work as presumably some permissions didn't get copied over. Not sure why, but there you go. I'm going to blame doing that via FTP vs the old fashions Linux way with a d- command and rm- rename or whatever This is one of those instances where I miss being able to set "paths" in a config file. I changed a WordPress blog install from http to https, by simply editing the config file to change "location" of the blog, and took 2 seconds. In this case, little more tricky since some permission wasn't copied over it looks like, and not really a paths issue, per se. Seems like a "repair" install function could fix that, but not going to run the updater on it either since the store paths set in admin would be for old install. Updater with set paths option would be cool. I forget whether it does that or not. I guess the "just rename it" then "update store URLs" method should work. Not quite ready to do that but have to deal with it "this month" for Firefox folk and mod_SPDY, so having to create the landing page for /ecom/ with two screen shots "old store" which will move to /ecomold/ or /ecom-old/ whatever; and temp store at something like /store/ and then tell FF users to use the new store .... Too ..... much ...... fun ... !!! Thanks Bsmithers... AGAIN! :-) 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.