Posted by Dave Kinchlea on November 9, 2009 at 2:15pm
3 followers
| Project: | Boost |
| Version: | 6.x-1.17 |
| Component: | Miscellaneous |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
It seems that any use of a non-destructive space are incorrectly translated into  (a capital A with an umlaut) on my utf-8 sites. While there is clearly a workaround (don't use the code) the unfortunate part is that those codes are being put in by TinyMCE which makes it harder to implement the workaround.
Comments
#1
Thats interesting... I use
with no issues. Boost doesn't do any kind of character transformation when saving. Can you give me any other details as to what might be causing this? Are you using the boost preprocessor hook?#2
Nope, not using the hook at all.
Truth is I've seen this miscoding a few times, often on the menu breadcrumbs, but this report comes from a node that had a
<ol> with 4 <li>,three had a which produced the above, one did not and didn't have any -- it made it much easier to find the problem. I removed all the and the encoding issue disappeared. I put the back in, cleared the cache and it is there for the anonymous user but not authenticated users (same as before).Unfortunately, in making sure my reply to you made sense, I found out that it is more complicated than just adding
... I created some new content with that in it and no problems (sigh). I have to admit, my own logic in this reply seems to exonerate Boost so I've closed the issue until I can find the time to investigate further.#3
My latest site build has highlighted this problem once again. I have a panel page that pulls content from a number of different sources (blocks, nodes, and views). When I create this page without Boost caching on, it renders perfectly. When I turn Boost Cache on using "Asynchronous Operation", the page that is delivered WITHOUT the boost identifier renders arrows and ">" "<" characters incorrectly.
Upon refreshing the page and getting the cached page, all renders properly. If I don't use the Asynchronous option then the first page delivered (still without the boost identifier) renders perfectly along with the cached page.
So, I'm assuming this has something to do with the headers being sent from apache when using Asynchronous Operation" .. you mention 'sends "Connection: close" instead of "Connection: Keep-Alive"' but I wonder if there are some other missing headers?
#4
Good Point, I should try to recreate the headers as best as I can using headers_list().
#5
#6
FYI this patch will not be committed until someone tests it & it indeed fixes the issue.
#7
Well, it didn't break anything but didn't solve the problem either Mike, same bogus encoding when delivered Asynchronously, rendered properly otherwise.
#8
Can I get the headers sent? One from the cache, another from the async opp, and one when Boost doesn't run at all (user/login page for example). Just be sure to remove any session information from the headers.
#9
Sorry for taking so long, I have a pending data centre move and have been too busy to get back to this.... I think you'll agree that Content-Type is the culprit. The first is a cached page, the second is the "Asynchronous Operation" after deleting the cached page.
kinch@albertasourus:~/tmp/kinchlea$ wget -S http://www.gatevillage.net/node
--2010-01-07 18:20:37-- http://www.gatevillage.net/node
Resolving www.gatevillage.net... 208.97.113.158
Connecting to www.gatevillage.net|208.97.113.158|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Thu, 07 Jan 2010 23:20:40 GMT
Server: Apache/2.2.11 (Unix) PHP/5.2.6-3ubuntu4.4 with Suhosin-Patch mod_ssl/2.2.11 OpenSSL/0.9.8g
Last-Modified: Fri, 18 Dec 2009 11:03:31 GMT
ETag: "608d-47afeb0accd30"
Accept-Ranges: bytes
Content-Length: 24717
Cache-Control: max-age=1209600
Expires: Thu, 21 Jan 2010 23:20:40 GMT
Vary: Accept-Encoding
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
Length: 24717 (24K) [text/html]
Saving to: `node'
100%[===================================================================================================================================================>] 24,717 --.-K/s in 0.1s
2010-01-07 18:20:38 (163 KB/s) - `node' saved [24717/24717]
kinch@albertasourus:~/tmp/kinchlea$ wget -S http://www.gatevillage.net/node
--2010-01-07 18:24:25-- http://www.gatevillage.net/node
Resolving www.gatevillage.net... 208.97.113.158
Connecting to www.gatevillage.net|208.97.113.158|:80... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Date: Thu, 07 Jan 2010 23:24:27 GMT
Server: Apache/2.2.11 (Unix) PHP/5.2.6-3ubuntu4.4 with Suhosin-Patch mod_ssl/2.2.11 OpenSSL/0.9.8g
X-Powered-By: PHP/5.2.6-3ubuntu4.4
Set-Cookie: SESS7b9af402d0757096b848a751720c77dd=8ab2f82d3bd0bfbe688cc58608106a90; expires=Thu, 14 Jan 2010 23:24:27 GMT; path=/; domain=.gatevillage.net
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Thu, 07 Jan 2010 23:24:27 GMT
Cache-Control: must-revalidate
Connection: close
Content-Length: 28237
Vary: Accept-Encoding
Content-Type: text/html;charset=iso-8859-1
Length: 28237 (28K) [text/html]
Saving to: `node.1'
#10
#11
Hi Mike
This appears to patch a different boost version than I have...
// $Id: boost.module,v 1.3.2.2.2.5.2.262 2009/11/28 07:59:34 mikeytown2 Exp $is my installed code--- boost.module 27 Dec 2009 00:03:37 -0000 1.3.2.2.2.5.2.287is what the patch file is expecting. That being said, I mimicked the patch for this version and Voila, problem solved for me... if I am reading this correctly, though, are there not similar problems awaiting those not using utf-8?In any case, that's a wrap, thanks.
Dave
#12
utf-8 is hardcoded throughout this module; allowing one to set the character encoding might be a good idea.
#13
committed
#14
Automatically closed -- issue fixed for 2 weeks with no activity.