When using Ruby 1.8.7 and Kramdown 0.14.0 and newer, the following build error
would occur if any page in your site contained a `<name@example.com>` email
address link:
Generating... Conversion error: There was an error converting 'contribute.markdown'.
/Users/nick/Documents/puppet-docs/vendor/bundle/ruby/1.8/gems/kramdown-1.0.2/lib/kramdown/converter/html.rb:404:in `obfuscate': undefined method `encoding' for "mailto":String (NoMethodError)
See also:
http://rubyforge.org/tracker/index.php?func=detail&aid=29750&group_id=7403&atid=28673
This problem traced back to the following line in the Kramdown source:
result.force_encoding(text.encoding) if result.respond_to?(:force_encoding)
Strings aren't supposed to respond to the :force_encoding method in Ruby < 1.9,
but lib/jekyll/core_ext.rb was modifying the string class like so:
def force_encoding(enc)
self
end
Strings still won't respond to :encoding, though, so we get an error when
Kramdown tries to read the incoming encoding and everything will blow up.
An ack of the codebase suggests that this was only added so we could force an
encoding for rdiscount on 1.9 without having to check whether we were running
under 1.8. Since testing for said method to learn whether one is running under a
1.9-like encoding regime seems to be a thing in libraries we rely on, we
shouldn't insert this dummy method without also dummying every other part of the
Ruby 1.9+ encoding system.
This commit removes the dummy :force_encoding method to stop poisoning core
classes for libraries we use, and moves the adjustment for 1.9-like encoding
regimes to the one place where it's needed.
Related to #1105.
Sample output:
~/code/jekyll/tsite$ ../bin/jekyll build --trace
Configuration file: /Users/parker/code/jekyll/tsite/_config.yml
Config Warning: The `paginate` key must be a positive integer or nil. It's currently set to 'true'.
Source: /Users/parker/code/jekyll/tsite
Destination: /Users/parker/code/jekyll/tsite/_site
Generating... done.
* Polish blog-post language for a less-technical crowd
* Emphasize that it's not a core issue
* Emphasize that it doesn't affect sites without plugins
* Break into paragraphs for easier skimability
* Explain that it affects users with access to templates, not just plugin authors
Nick Fagerlund
Parker Moore
Clint Shryock
Wlodek Bzyl
Thomas Torsney-Weir
André Arko
Matthias Vogelgesang
MURAOKA Taro
Matt Rogers
Assaf Gelber
Ben Balter