In short, it is expected that the only files that are on the server are the ones that were manually placed by those that have been granted the permission to do so. That said, one should always be vigilant and verify that something hasn't been done that has altered that condition. It doesn't have to be nor is it necessarily something caused or allowed by ZC. There are other ways/places that someone could cause an issue, but that too shouldn't make one run for the hills.
It comes down to the earlier question(s) of why does one site behave differently than the other? What are the differences? What changed after the copy?
There just isn't a ZC database switch that says, anytime one of these values in this table is changed, completely delete it's setting/value.
Now as to tools and accessing the site: I believe the first link provided above about working with ZC offers some suggested ftp type programs, working in the filemanager of the host can be troublesome in many ways. A ftp program tends to be written better to ensure complete file transfer/save. A partial file transfer/rewrite can cause trouble and sometimes be difficult to locate. Inspection of information and not saving or allowing the saving of changes well, won't change anything of significance on the server/cause a problem like seen.
So, another thing that we haven't talked about is identification of error logs as relates to the entire process. It may be possible that a debug log has been written to the applicable log folder directly related to the operation that is causing the problem even though there has not been a report of a visual occurrence of a problem (no: Warning an error has occurred style messages, no white screen or partial white screen, etc...). But there could be something(s) logged.
So where is that one asks? For pre-ZC 1.5.1 myDebug-xxxx files are logged in the /cache directory. As of 1.5.1 they are logged in the logs directory. Now... in a situation where there are no recent files in that directory and there seems/might be reason to believe that one should be generated in the directory, there are at least two to take. Simply verify permissions of the folder, and the reference through the applicable configure.php file/path, two force the generation of an error message to validate that one is written.
As for additional file comparison possibilities, may want to export both databases and compare them. Yes, there will be differences in customer history related items as well as settings known to have been "modified", but perhaps there is something else there as well. Basically, I have concerns because the site has been operating for a long time on an out-dated system, is not responding as expected/designed, and seemed to report that something may have been changed in troubleshooting.
As to the long list of other things such as session issues, impatience, etc... well, at least by file review, any accidental differences in files can be ruled out (ie. Truncated file or perhaps some other modification), again there are things of comparison between the two sites to address in addition to the comparison of the vanilla copy to the live site. Based on the earlier discussion of the site history, it sounds like there has been an issue of some type for a while, so it is difficult to say that your recent efforts have been the cause. I'm even wondering if there is an issue with the table format/character set, but trying to work through other potential issues first.
Here's what I have in mind at the moment as potential issues:
1. There is a php version difference as seen by each ZC site such that the live site sees 5.4.xx but the backup site sees something lower and within specification. Data only provided on the live site. Elevated php version has been reported by others to cause the "blanking" of data on save.
2. There is a file difference from the original fileset that includes a difference specific to its current location but that also is interrupting operation but without onscreen notification/disturbance. Looking for unusual changes within a file or a file existing that contains unusual content.
3. The live database has some sort of corruption that was auto-magically corrected when importing the database to the backup location (or some other operation performed when trying to regain access and the operation fixed the issue.) yes attempting to copy and setup another temp site would likely help here, but then the question is/becomes what if the copy of the current live site acts the same way as the current live site? What information has really been gained at that point and why would one expect it to be any different than the current live site?
4. There are some sort of strictness server setting differences between the two locations causing at least operations executed on the live site to store a blank value instead of the intended value, though this could be a case where some sort of sanitization occurs to blank out the piece of data to be saved during the load process of the store after submitting the change(s). (file comparison is likely to provide information related)
Might have a few more, just depends on available information and then how the information is pieced together.
Bookmarks