ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
Wiki diffs: incompatible character encoding error on Ruby 1.9.2 (Bug #707)
On Ruby 1.9.2, showing wiki diffs can fail with an incompatible character encoding error:
ActionView::TemplateError (incompatible character encodings: UTF-8 and ASCII-8BIT) on line #16 of app/views/wiki/diff.rhtml: 13: </p> 14: 15: <div class="text-diff"> 16: <%= simple_format_without_paragraph @diff.to_html %> 17: </div> app/views/wiki/diff.rhtml:16:in `concat' app/views/wiki/diff.rhtml:16:in `_run_rhtml_app47views47wiki47diff46rhtml' <internal:prelude>:10:in `synchronize' /home/mbreit/.rvm/rubies/ruby-1.9.2-head/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /home/mbreit/.rvm/rubies/ruby-1.9.2-head/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /home/mbreit/.rvm/rubies/ruby-1.9.2-head/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread' Rendered rescues/_trace (13.9ms) Rendered rescues/_request_and_response (3.4ms) Rendering rescues/layout (internal_server_error)
This happens if the
WikiJournal content is gzip encoded.
The reason is source:app/models/wiki_content.rb@0462fa9#L107 where
Zlib::Inflate.inflate returns a string with encoding set to ASCII-8BIT.
[#707] Fix encoding error on wiki diffs on Ruby 1.9
WikiDiff#to_html returns a string with ASCII encoding if
the WikiJournal content has been Zlib compressed because
Zlib::Inflate.inflate returns strings with ASCII encoding.
Forcing the encoding to be UTF8 fixes this bug.
A pull request with a fix for this problem is at https://github.com/chiliproject/chiliproject/pull/124
Looks good to me, I'd just like Holger to have a quick look too. The only thing I'm not quite sure about is the
respond_to part, wouldn't it be better to test whether we're on 1.9 or not?
- Target version set to 2.5.0
- Status changed from Open to Ready for review
This is fine by me. The
respond_to? is best practice and better transports the intend of the action.
As a side remark, I'd like to state that the whole gzip-bytes-in-text-field thing that we pull is rather shady. Those things should either be stored in a
BLOB or (even better) be left to the underlying database storage engine to be transparently compressed. However, this is out of scope for this issue.