MrPhil

Did you verify that the permissions actually changed? It's common for servers to silently ignore chmod requests by FTP browsers, so you end up not changing permissions. If so, use your hosting control panel to change permissions. Also confirm that you are the owner of the file, and not some other account. After that, possibly you're missing the correct file(s) -- did you ever change your "admin" to a different name? Are you installed under a different path? After that, permissions vary on what's needed for osC (via PHP) to write to a given file. 644 may work, 444 definitely will not. Go systematically, not at random. If osC can't write with 644, try 664. Only as last resort try 666, and restore to 644 when you're done with the operation (666 is a security hazard, as is 777).

When you say "wrong name or address", do you mean a completely wrong name, or a corrupted name (all or some accented characters not shown correctly)? If corrupted, I would guess that the payment system is expecting data to be passed to it in a specific encoding, such as Latin-1, and doesn't handle UTF-8 correctly. If that seems to be the case, can you ask your payment system provider if there is a setting to accept UTF-8 text? If not, it would be some work, but the text could be translated "on the fly" between UTF-8 and Latin-1 so your store has UTF-8 and the payment system is happy to see Latin-1. If the text is being emailed to someone else (that seems awfully insecure!), something would have to be done to tell their email to handle the text as UTF-8 rather than the default Latin-1.

Those "unreadable characters" are UTF-8 being displayed in Latin-x (single byte) encoding. Is the text in question something you just entered, or is it really old (from before some change, or even from the initial sample store)? Check the page encoding when you are seeing these characters -- it's probably Latin-1 or Windows-1252. Is that phpMyAdmin you're seeing it in? Is this a PC encoding rather than a site server encoding (you're looking at data on a PC and not through a Web interface)?

Are you using osC 2.3.1? If so, it should be displaying pages in UTF-8, and language files should already be in UTF-8. The only thing remaining is the database, which needs to be UTF-8. The collation order ('general' or 'unicode') isn't that important, but at least should be consistent. Now, as Julian said, the default installation for MySQL is Latin-1 (ISO-8859-1). It sounds like you initially left the database as Latin-1, and your data from that period is Latin-1, which causes the errors you see when you attempt to display accented characters. If you changed the database encoding at some point, from Latin-1 to UTF-8, were you careful to check that you translated the existing data to UTF-8? If not, I think there's a MySQL command to translate, but it may be difficult to use if it's not available in your phpMyAdmin. The alternative would be to back up (export) the database to .sql, fix any characters with an editor that are in the wrong encoding (so the .sql file is consistent), empty out the database, double check that the database definitions are UTF-8 throughout, and restore (import) the .sql file (being careful to tell phpMyAdmin what the encoding on the file actually is, so it can translate it on the fly).

If your site does not seem to be recognizing when SSL is available, the problem can be that some servers output '1' for getenv('HTTPS') instead of 'on'. You may need to change code in two or three files to recognize what your server is doing.