It's a config option in IIS7 (Homer's webserver) that he has to set to enable utf-8 support in served pages. He should also specify the encoding in the header of the page, as Internet Exploder happily ignores the encoding sent by the server.
Of course, he needs utf-8 support in the database that holds the site contents too, and the actual data has to be saved to the db as utf-8. This is often not the default for hosted sites, as unicode requires more space to store data than eg. iso 8859-1.
It all depends how much control over the server environment Homer has, but it 'just worked' on the old site...
If you look at the headers going back and forth; they are in UTF-8; hence the fact you see a pound sign above. I'm trying to work out why they dissappear (seems to be on the way into the database, but if you do it manually they don't). The database uses the same datatype as the old one; so its not the db. If its in the db, it shows on the page, so its not the response encoding.
Homer, talking about the database did it all come accross cos a couple of times now I have tried to open links and they have come back as 404 not found...admittedly fairly old ones but usweful ones about alternator testing for instance. This was linking from a post that the search facility had found if it makes any difference.
Bump -
Stuart not an error as such but in my details I have the wrong (account closed) e-mail address...
I did change it couple of days back and got a validation code through but notice this morning it has gone back to the dead one again...
Should I update again yet?
Homertrix: If you look at the headers going back and forth; they are in UTF-8; hence the fact you see a pound sign above. I'm trying to work out why they dissappear (seems to be on the way into the database, but if you do it manually they don't). The database uses the same datatype as the old one; so its not the db. If its in the db, it shows on the page, so its not the response encoding.
Firefox 3.5 with 'Web Developer' toolbar, OSX. Looking at the response headers for this page, I get:
I use the "Live Headers" add-in and this shows the content type being set and the charset as utf-8. The .NET Globalization settings are all set to utf-8.
If I use Google Chrome, select "Auto Detect" for the encoding - it returns utf-8.
Homer - " I have tested this and can see no reason why it reverts. PM me the email addresses and I will have a look."
cheers Stuart - I will change it again now and see what happens
changed it - restarted as didn't get sent validation number this time but I'm back in OK so sorted I guess
Some threads not updating correctley on main page. nThey have new posts but the envelope is not showing that it has. Sometimes it does sometimes it doesn't and effects various threads. sorry its a bit vauge but its a bit vauge IYSWIMJ
the stats used in the forum view and top level are updated without locks - this means that if the stats can't be updated when you post (such as two people updating concurrently) the update is ignored rather than queued.
This is done on purpose so that you are able to post quickly. The stats would then be updated by the next thread action or through the nightly checking process.
On the facebook news items, if you click a picture, it leaves the triuphtorque domain name in front of the facebook link, not redirect you to face book.
Server Error in '/' Application. Runtime Error Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "Off".
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's <customErrors> configuration tag to point to a custom error page URL.
.
