Slim templates conversion broken

[gwik]

Hi,

There is a problem when using blocks and slim.

  == render layout: 'partial_layout' do
    div.foo = "bar"

This will result in the block content being escaped and presented uninterpreted.

Also some other slim templates are raising syntax errors. I had to downgrade to 9.1
Is there a way to disable deface for slim templates ?

rails 3.2 / spree 1.3 / ruby 2.0 / deface 1.0.0 / slim 2.0.1 and 2.0.2

[Jaco-Pretorius]

I'm having the same issue. I upgraded from deface 0.9.1 to 1.0.0 and the conversion from Slim to ERB seems to be completely broken. Lots of templates are simply broken while others treat the code as being escaped (so you see things like 'if user' in the view.

[radar]

@Jaco-Pretorius Can you show us an app which clearly reproduces this issue please?

[Jaco-Pretorius]

@radar I'll try to put one together

[Jaco-Pretorius]

@radar I created an example that shows both the problems I am having: https://github.com/Jaco-Pretorius/deface-slim-bug-example

Look at the _nav_bar.html.slim template - when you run the server you should get an error saying the erb is malformed, I suspect this is with the conversion from slim to erb. Now if you look at that template and comment out everything from line 11 onwards you won't get a syntax error, but you will see the interpolation syntax on the page itself (being escaped incorrectly).

That's the 2 issues I'm having. Let me know if what I wrote makes any sense at all.

[Jaco-Pretorius]

I did a git bisect with my example against the deface gem (meaning I'm searching through the deface commits to find the commit that broke my example). The culprit is this one: 415422f (no surprise, this seems to be the biggest change between 0.9.1 and 1.0.0. I'm trying to do more digging to figure out what is going wrong.

[Jaco-Pretorius]

Ok, this is what is going on. The change from tags to tags causes the HTML output to change since Nokogiri treats regular HTML tags and non-standard HTML tags differently. (This actually seems to be a change that was introduced in the upgrade from Nokogiri v1.5.9 to v.1.6.0)

code_tag = "<code>\n</code>"
erb_tag = "<erb>\n</erb>"

Nokogiri::HTML::DocumentFragment.parse(code_tag).to_s
#=> "<code>\n</code>"
Nokogiri::HTML::DocumentFragment.parse(erb_tag).to_s
#=> "<erb></erb>"

This seems to cause serious issues with the Erb interpreter. My suggestion would be that we either fix Nokogiri to treat non-standard tags the same as standard tags, or we revert the change from tags to tags - since currently this completely breaks Slim templates in Deface.

Here is a repo showing the problem in detail: https://github.com/davidoh/TestNokogiri

[wingrunr21]

@Jaco-Pretorius is there a short-term fix for this that you know about? I've got an issue where this is completely mangling a couple of my pages.

[Jaco-Pretorius]

@wingrunr21 AFAIK you can switch off deface for slim completely in the config, but I haven't tried it. Unfortunately I'm no longer on the project where we had this issue.

[davidoh]

@wingrunr21 this issue appears to be fixed with the latest version of Nokogiri (v.1.6.2.1). We are using Slim templates in our project and after we did a bundle update there are no longer any issues with Deface.

Here's the updated repo showing the problem being fixed in Nokogiri v1.6.2.1:
https://github.com/davidoh/TestNokogiri

[davidoh]

After deploying to Heroku, this issue has popped up again. It seems that this issue depends on both the Nokogiri version and the libxml version it is compiled against. In Heroku the libxml version appears to be locked at 2.7.6 whereas our local development environment uses 2.8.0. With 2.8.0 this issue seems to be resolved:

Nokogiri (1.6.2.1)
    ---
    warnings: []
    nokogiri: 1.6.2.1
    ruby:
      version: 2.0.0
      platform: x86_64-linux
      description: ruby 2.0.0p481 (2014-05-08 revision 45883) [x86_64-linux]
      engine: ruby
    libxml:
      binding: extension
      source: system
      compiled: 2.7.6
      loaded: 2.7.6

More information on Heroku locking libxml to 2.7.6:
sparklemotion/nokogiri#458 (comment)

To workaround this issue for now:

• Either disable overrides completely
• Use ERB or HAML templates for the views that the overrides are concerned with

[wingrunr21]

I actually saw the issue in a slim view that was being rendered directly, not via a Deface override. Good information on the libxml version though. I'm guessing Heroku pre-builds Nokogiri since it is such a common gem and Bundler thus uses the pre-built version.

[davidoh]

@wingrunr21 You mentioned your issue was in a slim view that was being rendered directly. Which view in particular?

A slim template will break due to Deface if an override is linked to that template, even if that override doesn't actually result in any changes. So it's not just the "inserted" view that could break, it's also the original view that is being "overridden".

[wingrunr21]

It was completely overridden view for products products/show. It is possible the Deface override I had in place for the nav bar was corrupting it.

[DavidBennettPIO]

Also having the same issue, I overrode "spree/orders/edit" with slim in a spree 1.2 app and the form contents are escaped:

Slim:

== form_tag empty_cart_path, method: :put, id: 'emptycart' do
  = submit_tag t('empty_cart')

Html: (formatted for your sanity)

<form accept-charset="UTF-8" action="/cart/empty" id="emptycart" method="post">
  <div style="margin:0;padding:0;display:inline">
    <input name="utf8" type="hidden" value="&#x2713;" />
    <input name="_method" type="hidden" value="put" />
    <input name="authenticity_token" type="hidden" value="E9OW9sLa2T6sqaziF0+b2LYH/Z7EeLeRsDKaDLslFDA=" />
  </div>
  &lt;input name=&quot;commit&quot; type=&quot;submit&quot; value=&quot;Empty Cart&quot; /&gt;
</form>

This is happening on my local mechine in ruby 2.1.2 with Nokogiri (1.6.2.1) and it's packaged version of libxml 2.8.0

bundle exec nokogiri -v 
# Nokogiri (1.6.2.1)
    ---
    warnings: []
    nokogiri: 1.6.2.1
    ruby:
      version: 2.1.2
      platform: x86_64-linux
      description: ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-linux]
      engine: ruby
    libxml:
      binding: extension
      source: packaged
      libxml2_path: "/home/david/.rvm/gems/ruby-2.1.2/gems/nokogiri-1.6.2.1/ports/x86_64-unknown-linux-gnu/libxml2/2.8.0"
      libxslt_path: "/home/david/.rvm/gems/ruby-2.1.2/gems/nokogiri-1.6.2.1/ports/x86_64-unknown-linux-gnu/libxslt/1.1.28"
      compiled: 2.8.0
      loaded: 2.8.0

And I still get the same error if I install using nokogiri the system library (not the shipped version) like this:
(As I'm using the *buntu repos I have the libxml2-dev installed at version 2.9.1+dfsg1-3ubuntu4.3)

gem uninstall nokogiri
gem install nokogiri -- --use-system-libraries
bundle exec nokogiri -v                                                                                                              
# Nokogiri (1.6.2.1)
    ---
    warnings: []
    nokogiri: 1.6.2.1
    ruby:
      version: 2.1.2
      platform: x86_64-linux
      description: ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-linux]
      engine: ruby
    libxml:
      binding: extension
      source: system
      compiled: 2.9.1
      loaded: 2.9.1

Here is the output from the dev log for that page:

Started GET "/cart" for 127.0.0.1 at 2014-07-08 21:34:27 +0930
Processing by Spree::OrdersController#edit as HTML
  Spree::Order Load (0.5ms)  SELECT "spree_orders".* FROM "spree_orders" WHERE "spree_orders"."number" IS NULL LIMIT 1
  ...snip...
Deface: 1 overrides found for 'spree/orders/edit'
Deface: 'promo_cart_coupon_code_field' is disabled
Deface: 1 overrides found for 'spree/layouts/spree_application'
Deface: 'nav_bar_home' is disabled
  Rendered spree/orders/edit.html.slim within spree/layouts/spree_application (45.7ms)
  ...snip...

As you can see I have tried disabling the two overrides but this didn't help.

---

Just a note this code slim does work like you would expect... but its really ugly:

- f =  form_tag empty_cart_path, method: :put, id: 'emptycart' do
  = submit_tag t('empty_cart')
= f.html_safe

[wilkerlucio]

It's being a while since last post here, did you guys found a solution? I'm still having this same issue that you described here.

[BDQ]

I pushed a couple of Slim related fixes to master, which should also hopefully solve the problems described here.

Please open a new issue with the exact slim syntax if you're still having problems.

[DavidBennettPIO]

Hi, the error I was having is still happening with master. I have opened a new issue with more details at #133 thanks :)