Unable to Update Product and Shipping Costs

[SevenCubed]

The Background:
1) The website was migrated from an old host to a new one about 2 months ago - I performed the migration. Afterwards, as is sometimes the case with different host configurations, I ran into a problem with products being dropped from the cart. 2 hours of analysis and changing server configurations resolved the issue (PHP session variables related). All was well. Person confirmed everything was functioning properly and she was receiving and processing orders.
2) About 2 weeks ago I get a call from this person telling me that her PC crashed and someone fixed it for her (less the website files) and she needed help to restore the local files. (Didn't have an external backup copy!)
3) I still had the backup copy that created prior to migrating her to new host. I asked her if she had made significant updates to the website since then to which she replied yes. Fine, I figure that the backup copy wouldn't be sufficient so I indicate that I would download the entire file structure again from the live server version, burn it to disk, and drop by to restore her local copy. That too turned out to be a 3 hour adventure for something that should have taken 15 minutes. Tested again and all was well and confirmed by this person.

The New Problem:
It's an ecommerce website developed in PHP (that I didn't build but inherited to casually maintain only for major problems), using a popular commercial WYSIWYG editor (specialized for ecommerce), it's not updating files to reflect product and shipping price changes when she uploads new changes from her local PC copies.

My Early Assessment:
I'm going to have to drop by this local based company to check it out because I know it's not a matter to attempt to resolve over the phone.

I'm suspecting it's a problem related to file permissions:

Folders from example.com on old host == drwxr-xr-x == 755(?) - verified permissions from my original backup copy
Files from example.com on old host == -rw-rw-r == 0664(?) - verified permissions from my original backup copy
Files from example.com on new host == -rw-r-r == 0644(?) - verified permissions on live version right now via FTP

I've had other issues with other websites when exchanging files between Windows and Linux systems. I'm using Linux, the server is Linux, the person's PC is Windows.

Is it likely that my Linux system changed the permissions on original and subsequent transfers from the old and new server from -rw-rw-r to rw-r-r and that is preventing related scripts on the server from writing to each other?

For quick reference:
r = 4
w = 2
x = 1
- = 0

If it's related to file permissions I guess I'm going to have to change them manually on the server then download the entire directory structure to her local PC again, or is there a way to change them manually in a Windows environment (I don't think I've ever tried that before). Or maybe I can configure the WYSIWYG application to set the file permissions prior to uploading them? Ah yes maybe that's the problem! Because it has a built-in FTP program that wasn't properly reconfigured after the program was reinstalled? (ha, my ego so wants it to be someone else's fault).

One last tidbit, the orders are processed by handing it off to PayPal in a new window, it's not integrated into the site.

Any insight at all would be appreciated even if you think it's not related to what I've outlined above. I want to keep it simple before looking for a potentially more drastic problem and file permissions was the first lightbulb that went on. Thanks in advance and sorry if this is waaaaay more info than is required but my brain builds stories around everything!

[swa66]

It's not just the user/group/other bits that you list that are important, but also what user/group is actually set on the files as well as as what user/group the httpd is runnign at (that's configurable in apache's httpd.conf)

Windows doesn;t ahve a clue when it comes to unix permissions.
That clue has to come from the transfer program. I'd guess it's a ftp client? It needs to be configured, or the user needs to be taught to set the right permissions manually.

On a unix machine it's pretty easy to set permissions (even automated).
E.g.: [php.net...]
but if you run that from the httpd server it's likely it'll already needs more permissions that it's got if the user messes up things.


Now properly coded your PHP application should catch the error that it cannot write to the files it needs to write to.

[SevenCubed]

Thanks for the quick response.

It is an FTP client that's built into the application itself.

It's also on shared hosting, not my own server, so I don't have access to Apache's httpd.conf -- only .htaccess

I'm not sure how much detail I can get from shared hosting log files but that's where I'm going to go check now.

I'm going to digest what you've pointed out here and see if I can glean some clues from that. Thanks.

[SevenCubed]

The logs were not helpful. I should say log. There's only 1 and it contains some PHP warnings but no error. The warnings had no evidence of failing to write to files.

Soooooo, I was thinking okay it probably isn't related to file permissions afterall. That's probably true because in fact the rest of the store functions fine in every way. It's just that her price updates aren't transferring. That points to maybe a configuration file or two, or three...

At this point I'm going to throw out the name of the application because it has been around a long time and is mainstream so I'm not trying to promote anything here. It's CoffeeCup. I'm doing this because I haven't been able to find any clues elsewhere on the internet as to a potential solution, or even where the root of the problem may be, so maybe someday this might become the go-to-source. Who knows.

I thought about it, and browsed the server directory, and tracked down some xml files containing, guess what, prices! And more importantly a critical file that ends with a .scc file extension that is THE main file for a site.

To speed things up here...it exists in 2 folders on the remote server and has conflicting price data in them, ah ha. I suspect that the person's local copy is updating one but uploading it to the wrong directory on the server.

I think this is going to be the solution but I won't know until I check it out tomorrow. I'll post the results when I know one way or another.

This is a prime reason why I don't like working on websites I didn't assemble, especially something built in a proprietary application. It can be a frustrating challenge at times.

Maybe then, an admin might also be able to change the thread title and subtitle to more appropriately match the symptom and solution. I'll dream it up when/if the time comes.

[SevenCubed]

Resolved. I'm exhausted.

And there's no need to update the thread title or subtitle. The issue did in fact revolve around the person sending updates to the wrong folder but it wasn't their fault. Nor was it mine. It's a loooooong story not worth getting into dating back to prior to moving the site from the old host where someone (who knew very little about web directories) had managed to created about 6 versions of the site by copying it inside of itself as well as outside the domain root. At the time I thought I had managed to untangle the mess prior to migrating it but in fact figured out today that I had missed 2 more copies.

By default there's only supposed to be 1 master .scc file. Turns out there were 3 on the new server. Few weeks ago I had a 33% chance of restoring the right one (not knowing there were 3) after her OS was rebuilt and CoffeeCup reinstalled. Of course because I was only expecting to find one I restored the first one I came across. The wrong one.

So it wasn't a file permissions issue at all.

But, when I was sipping a coffee afterwards I was thinking about how I used to do this for a living 5 days a week in IMAC onsite desktop support. Sometimes up to 4 or 5 cases a day. I don't think I could handle that kind of frustration anymore.

[SevenCubed]

Oh snap I can't even get the story straight! I didn't restore the wrong one. But CoffeeCup's default setup after reinstalling it was simply pointing the the wrong path on the server where a directory did actually exist but not the live one. That's why she was getting a "successful update" message but yet not changes the live files. A root copy was being updated.

Nevermind.

It's done and so am I.