Forum OpenACS Development: Has anyone upgraded an ecommerce site to AOLserver4?
When we first switched, certain "special" characters like the pound sign (as in British pounds) and the ellipsis (...) and double-dash from Word were displaying with a capital A with a tilde over it in front of them. I was able to fix some of them by adding
ns_param OutputCharset utf-8
to the ns/parameters section of my config file.
However, the ones that are part of ecommerce product descriptions are still messed up. In IE for Mac, the A is now a solid black box (very attractive :). In Firefox it is inconsistent - one one of my systems it looks fine now, and the other has an A with a black border around it where IE puts the solid box. And in Safari it appears to be correct at all times.
Presumably this is all happening due to the way the pages are generated - the product template is run through ns_adp_parse, and then the result is templated by acs-templating. However, this used to work with the aD patches to nsd 3.3, so something seems to be missing or misconfigured now.
Has anyone figured out a solution to this? I'm working with Dossy on it but any ideas are welcome at this point.
Check that you have all of these in ns/parameters
# Unicode by default:
# see http://dqd.com/~mayoff/encoding-doc.html
ns_param HackContentType 1
ns_param DefaultCharset utf-8
ns_param HttpOpenCharset utf-8
ns_param OutputCharset utf-8
ns_param URLCharset utf-8
That is from the default config file from OpenACS 5.1.1
Dossy says that it's probably caused by pasting Word content into a web form (I'm contacting the client to find out how they are creating their content) and that if I fix the content in the database it should work. But it worked in the other version of AOLserver, and I'd much rather make some global change to nsd than have to go fix several sites' worth of content and make the client change their workflow.
So the search continues...
We also see this with HTMLarea. Not sure if that helps.
For data, our current fix is to:
1. Use a series of regsubs on the data to convert common characters to html entities etc.
2. manually "zap gremlins" (using bbedit) before importing data to ec.
It would be nice to have a filter/converter added to the bulk import and product-edit, product-add pages, but I'm not sure yet of the best approach to handle the various charsets.
Maybe something like this already exists in the forums package?
I've just replied to you on the AOLS list and then just found the same reply here
I started on AOLS4 and then switched back to AOLS3 (becuase of the SSL problems). I have the default UTF encoding as per the config.tcl of v5.1 onwards and that seems to have fixed the problem which we had pasting into the HTMLArea.
However, I don't think our client was pasting from Word documents but I'll check this and let you know.
Who did the 4.0.x character set work, or who else really understands its guts, either the 4.0.x or the 3.3+ad13 version? Most rapid fix might be to get those folks involved, if possible...
Thanks to all who replied!