James S Posted July 10, 2017 Share Posted July 10, 2017 Since upgrading to 6.1.8 we seem to have an issue with deleting backup files and the database from "dashboard - maintenance - backup" the files do delete but this error is displayed; /sources/maintenance/indexbackup.inc.php - not found. Checking with FTP the path and file does not exist, should it? has something gone missing? or what.... any ideas or anyone had the same problem. James Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 11, 2017 Share Posted July 11, 2017 The construction of that file path is bad. We will look into why that is. I am confident that no damage is being done to your store. Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 11, 2017 Share Posted July 11, 2017 Having upgraded to CC618 from a prior version several versions back, you may be experiencing a disconnect involving a new approach to obfuscating the admin directory. Please confirm that your installation has only one folder named /admin_aBcXyZ/ and that there is no folder present that is simply /admin/ (where aBcXyZ is a sequence of random letters). Also, examine the contents of /includes/global.inc.php to discern that the value for the ['adminFolder'] variable matches the name of the admin folder. However, if this proves to be the cause, then probably much more about CubeCart would fail to operate. Quote Link to comment Share on other sites More sharing options...
James S Posted July 11, 2017 Author Share Posted July 11, 2017 10 hours ago, bsmither said: Having upgraded to CC618 from a prior version several versions back, you may be experiencing a disconnect involving a new approach to obfuscating the admin directory. Please confirm that your installation has only one folder named /admin_aBcXyZ/ and that there is no folder present that is simply /admin/ (where aBcXyZ is a sequence of random letters). Also, examine the contents of /includes/global.inc.php to discern that the value for the ['adminFolder'] variable matches the name of the admin folder. However, if this proves to be the cause, then probably much more about CubeCart would fail to operate. The folder named /admin_rOqekV/ does match the variable adminFolder name in the global.inc.php file, however there was a second admin folder without the suffix (an old version I assume). There is no folder named maintenance in admin or admin_rOqekV and no indexbackup.inc.php file anywhere on the site. I have renamed the admin folder (to old_admin) and there is no difference to the sites operation, I still get the original error on removing a backup file. Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 11, 2017 Share Posted July 11, 2017 I have been tracing the code for CC618 and have not found a specific cause. I have found where a problem might occur but only if the URL is bad. CubeCart sends a message to the browser to make a page request (a 302 redirect) after deleting the file. Are you able to discern what that URL is? It should be visible in the browser's address bar. It should be something like:admin_xXxYyY.php?_g=maintenance&node=index#backup Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted July 11, 2017 Share Posted July 11, 2017 It looks like an issue that was fixed for some other places. It's caused, if I remember correctly, by the tab # code being changed. https://github.com/cubecart/v6/issues/1639 Quote Link to comment Share on other sites More sharing options...
James S Posted July 11, 2017 Author Share Posted July 11, 2017 3 minutes ago, bsmither said: I have been tracing the code for CC618 and have not found a specific cause. I have found where a problem might occur but only if the URL is bad. CubeCart sends a message to the browser to make a page request (a 302 redirect) after deleting the file. Are you able to discern what that URL is? It should be visible in the browser's address bar. It should be something like:admin_xXxYyY.php?_g=maintenance&node=index#backup This is what I get as the landing page url after a delete http://www.sitename.co.uk/shop/admin_srdcxI.php?_g=maintenance&node=index%23backup#backup and get "%s deleted." in the red banner Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 11, 2017 Share Posted July 11, 2017 The %23 is the bad part. That is the code for the hash mark. Continuing to look at the code. Thank you for this info. Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted July 11, 2017 Share Posted July 11, 2017 Try taking out the # in the code and replace it with a comma as shown below: Backup WAS httpredir('?_g=maintenance&node=index#backup'); CHANGED TO in 6.1.8 httpredir('?_g=maintenance&node=index','backup'); Quote Link to comment Share on other sites More sharing options...
James S Posted July 11, 2017 Author Share Posted July 11, 2017 I can do that but need to know which file we are looking at here? and in which folder. Thanks Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted July 11, 2017 Share Posted July 11, 2017 Sorry, I wasn't on the computer and couldn't look at the code. In maintenance.index.inc.php about line 933 foreach ($sorted_files as $file) { $filename = basename($file); $type = preg_match('/^database/', $filename) ? 'database' : 'files'; $restore = preg_match('/^database_full|files/', $filename) ? '?_g=maintenance&node=index&restore='.$filename.'#backup' : false; $compress = (preg_match('/.zip$/', $filename) || file_exists($file.'.zip')) ? false : '?_g=maintenance&node=index&compress='.$filename.'#backup'; $existing_backups[] = array('filename' => $filename, 'delete_link' => '?_g=maintenance&node=index&delete='.$filename.'#backup', 'download_link' => '?_g=maintenance&node=index&download='.$filename.'#backup', 'restore_link' => $restore, 'compress' => $compress, 'type' => $type, 'warning' => ($type=='database') ? $lang['maintain']['restore_db_confirm'] : $lang['maintain']['restore_files_confirm'], 'size' => formatBytes(filesize($file), true) ); } } The delete link and the download link each have an #. I'm GUESSING that needs to be changed to commas somehow. Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 11, 2017 Share Posted July 11, 2017 (edited) I think not this exactly. In the code above, I think simply: Find everything that looks like this: .$filename.'#backup' Change to: .$filename Leaving everything before and after on the statement line exactly the same. Four locations. Once CubeCart is finished with the job, the bounce will be to #backup - which means having it in the URL at these locations is superfluous and may be causing the problem. Edited July 11, 2017 by bsmither Quote Link to comment Share on other sites More sharing options...
James S Posted July 11, 2017 Author Share Posted July 11, 2017 OK, altered the file and reloaded, cleared the cache, created a backup, then deleted it and the same problem occurs. My maintenance.index.inc.php file only had 3 instances with .$filename.'#backup', the rungs with $compress and compress in did not exist. Does the ',' and ':' remain after $filename? My modified file; foreach ($sorted_files as $file) { $filename = basename($file); $type = (preg_match('/^database/', $filename)) ? 'database' : 'files'; $restore = (preg_match('/^database_full|files/', $filename)) ? '?_g=maintenance&node=index&restore='.$filename : false; $existing_backups[] = array('filename' => $filename, 'delete_link' => '?_g=maintenance&node=index&delete='.$filename, 'download_link' => '?_g=maintenance&node=index&download='.$filename, 'restore_link' => $restore, 'type' => $type, 'warning' => ($type=='database') ? $lang['maintain']['restore_db_confirm'] : $lang['maintain']['restore_files_confirm'], 'size' => formatBytes(filesize($file), true) Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 11, 2017 Share Posted July 11, 2017 The commas at the end of the lines are there to separate the elements of an array, so they are necessary. Your edit looks good. Quote Link to comment Share on other sites More sharing options...
James S Posted July 11, 2017 Author Share Posted July 11, 2017 If it helps the puzzle the last upgrade was done on 10th June and I am sure there was not an issue with the deletion until last week, and no other site changes. Al did the upgrade from version 4.0 to 6.0 in May 2015 Upgrade History CubeCart Version Date 6.1.8 Saturday, 10 June 2017 6.1.7 Saturday, 10 June 2017 6.1.6 Saturday, 10 June 2017 6.1.5 Friday, 17 February 2017 6.1.4 Friday, 17 February 2017 6.1.2 Friday, 17 February 2017 6.1.1 Wednesday, 23 November 2016 6.1.0 Wednesday, 23 November 2016 6.0.9 Friday, 29 January 2016 6.0.7 Tuesday, 20 October 2015 6.0.6 Monday, 6 July 2015 6.0.5 Monday, 15 June 2015 6.0.4 Wednesday, 20 May 2015 6.0.3 Wednesday, 20 May 2015 6.0.2 Wednesday, 20 May 2015 6.0.12 Thursday, 25 August 2016 6.0.11 Friday, 15 April 2016 6.0.10 Friday, 29 January 2016 6.0.0 Wednesday, 20 May 2015 5.2.9 Wednesday, 20 May 2015 5.2.6 Wednesday, 20 May 2015 and more before this ... Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 11, 2017 Share Posted July 11, 2017 If your copy of maintenance.index.inc.php, starting near line 933, does not have a $compress statement, then you are not at CC618. I have a suspicion that the file /includes/functions.inc.php is also not at CC618. It may be the case that your installation of CubeCart may be a mix of two or more versions. Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted July 11, 2017 Share Posted July 11, 2017 Quote may be the case that your installation of CubeCart may be a mix of two or more versions. This has happened over and over with forum threads for the last month or two. Quote Link to comment Share on other sites More sharing options...
James S Posted July 11, 2017 Author Share Posted July 11, 2017 Oh Great! Guess there is not a simple solution? Any threads or guidance on reinstalling a shop/site on a virgin 6.1.8 base? Thanks for the assistance... Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 12, 2017 Share Posted July 12, 2017 Download CC618. Unzip the file on your local workstation to some folder. Using an FTP program, simply upload the contents of that folder having the FTP program to overwrite everything. The database will not be molested. Then, make sure the name of the admin folder and admin.php file are the same as the values in the file /includes/global.inc.php (which should not have been overwritten as this file is only created on installation and is not included in the distribution package). Quote Link to comment Share on other sites More sharing options...
James S Posted July 12, 2017 Author Share Posted July 12, 2017 That's good - have tried the problem site on a test domain and all looks to be working well now. Just for completeness on the instructions... Having FTP'ed the new folders and files to the domain, Deleted the 'setup' folder, the old 'admin_******' folder and the old 'admin.php' file. As you say the global.inc.php file does not get overwritten. Incidentally when using a test domain with an alternative path to the live site, documents lose their link to any in-bedded images as the path is changed - do you know of anyway round this without opening up each and every image link and editing the path? Many Thanks for your Invaluable Help and Assistance Again. - I am sure I will be back before long! James Quote Link to comment Share on other sites More sharing options...
bsmither Posted July 12, 2017 Share Posted July 12, 2017 Links to all page resources are not hard-coded. That is to say, CubeCart figures out the address used to get to it, and uses that to construct a full URL for the page's resources. However, unless changed in CC618 (I have not yet checked), CubeCart creates a complete menu navigation in HTML and caches it. Thus, when accessing Site-A using a different URL, the menu still has the prior links. But, CubeCart's templates have relative image links - requiring the browser to re-use the domain address of the page that is requesting those images. 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.