Hi,

I have in Spree an override like this:

Deface::Override.new replace: "#footer-left",
                 text: "Copyright © 2012",
                 name: "footer"

When trying to start the server I get:

app/overrides/spree_application.rb:4: invalid multibyte char (US-ASCII)
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/gems/activesupport-3.1.3/lib/active_support/dependencies.rb:234:in `block in load'
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/gems/activesupport-3.1.3/lib/active_support/dependencies.rb:223:in `block in load_dependency'
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/gems/activesupport-3.1.3/lib/active_support/dependencies.rb:640:in `new_constants_in'
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/gems/activesupport-3.1.3/lib/active_support/dependencies.rb:223:in `load_dependency'
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/gems/activesupport-3.1.3/lib/active_support/dependencies.rb:234:in `load'
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/bundler/gems/deface-7d097c794fec/lib/deface/environment.rb:52:in `block (2 levels) in enumerate_and_load'
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/bundler/gems/deface-7d097c794fec/lib/deface/environment.rb:51:in `glob'
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/bundler/gems/deface-7d097c794fec/lib/deface/environment.rb:51:in `block in enumerate_and_load'
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/bundler/gems/deface-7d097c794fec/lib/deface/environment.rb:50:in `each'
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/bundler/gems/deface-7d097c794fec/lib/deface/environment.rb:50:in `enumerate_and_load'
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/bundler/gems/deface-7d097c794fec/lib/deface/environment.rb:27:in `load_all'
from /Users/dcrec1/.rvm/gems/ruby-1.9.3-p0/bundler/gems/deface-7d097c794fec/lib/deface/railtie.rb:12:in `activate'

When a Deface override targets 'spree/checkout/_address', even if the override is disabled, it breaks the checkout.js file, which populates a state drop-down when a country with states is selected and replaces it with a text-field box when a country without states is selected. After Deface goes over and rewrites the view (even "without changing" anything), both the drop-down and the text-field box show up - PLUS the states are sorted seemingly randomly.

Steps to reproduce:

1. Install fresh Spree store, version 1.0.4 (I have not tested on other versions, especially since it seems to be a Deface issue)
2. Create a test override that is disabled, something as simple as:

Deface::Override.new( :virtual_path => 'spree/checkout/_address',
                      :name => 'test',
                      :insert_bottom => 'p#sphone',
                      :text => "<% %>",
                      :disabled => true)

1. Run rails s.
2. Add product to cart.
3. Checkout - and you will see the issue on the address form.

I assume this happens because Deface makes subtle changes to the html.erb even when not applying any overrides. Any suggested workarounds?

Hi,

I use Spree, and they use Deface... But all my views are in HAML.

Its possible to add support of HAML to deface ?

Regards,

Spree uses Deface, so I came here to look at your documentation. The part that puzzles me quite a bit is the recommended placement for Deface code. I can pretty much rule out placement in Controller, because it deals more with View (Plus, I like to keep controller slim). But then, where do you put such code inside the view?

So essentially the steps would be like

1. From the controller, render a view (lets call it "foo")
2. the "foo" view contains Deface override block which overrides another view called "bar"
3. Finally output the view would be a combined version of "foo" and "bar"

When using edge Deface to take advantage of the multiple render_original update I ran into this error that didn't present itself while using Deface 0.9.1:

ArgumentError: wrong number of arguments (0 for 1)
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/dsl/loader.rb:28:in `instance_eval'
(eval):3:in `block in load'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/dsl/loader.rb:28:in `instance_eval'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/dsl/loader.rb:28:in `block in load'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/dsl/loader.rb:17:in `open'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/dsl/loader.rb:17:in `load'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/environment.rb:96:in `block (2 levels) in enumerate_and_load'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/environment.rb:95:in `glob'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/environment.rb:95:in `block in enumerate_and_load'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/environment.rb:85:in `each'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/environment.rb:85:in `enumerate_and_load'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/environment.rb:79:in `load_overrides'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/environment.rb:61:in `block in load_all'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/environment.rb:59:in `each'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/environment.rb:59:in `load_all'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/bundler/gems/deface-cc8d0c5ee575/lib/deface/railtie.rb:12:in `activate'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:429:in `_run__3340563893381929601__prepare__2512575180036981927__callbacks'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:405:in `__run_callback'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:385:in `_run_prepare_callbacks'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/activesupport-3.2.8/lib/active_support/callbacks.rb:81:in `run_callbacks'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/reloader.rb:74:in `prepare!'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/actionpack-3.2.8/lib/action_dispatch/middleware/reloader.rb:48:in `prepare!'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/railties-3.2.8/lib/rails/application/finisher.rb:47:in `block in <module:Finisher>'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:30:in `instance_exec'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:30:in `run'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:55:in `block in run_initializers'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:54:in `each'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:54:in `run_initializers'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/railties-3.2.8/lib/rails/application.rb:136:in `initialize!'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/railties-3.2.8/lib/rails/railtie/configurable.rb:30:in `method_missing'
~/spree_gelaskins/config/environment.rb:5:in `<top (required)>'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
/usr/local/Cellar/rbenv/0.3.0/versions/1.9.3-p194/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
~/spree_gelaskins/config.ru:3:in `block in <main>'
~/Library/Application Support/Pow/Versions/0.4.0/node_modules/nack/lib/nack/builder.rb:4:in `instance_eval'
~/Library/Application Support/Pow/Versions/0.4.0/node_modules/nack/lib/nack/builder.rb:4:in `initialize'
~/spree_gelaskins/config.ru:1:in `new'

The issue boiled down to being due to the way I was passing in the sequence option value.

Raises error:

<!-- replace "[data-hook='products_list_item'] .price.selling"
     sequence 2
     original 'f92eb818cbfff0ab67dcce9d43cdb445d510076c' -->

Works fine:

 <!-- replace "[data-hook='products_list_item'] .price.selling"
     sequence '2'
     original 'f92eb818cbfff0ab67dcce9d43cdb445d510076c' -->

So one of the changes since the last release causes sequence to require a string value rather than an integer. May take a whack at fixing this when I have time, but wanted to point it out for anyone else running into this quite confusing error message...

At the least would be nice if we could improve the error message output to indicate which override is causing the error since I thought it was possibly something wrong with Deface itself on edge not one of my overrides.

Hi,

Man, please, update the documentation (mainly the README) about the new place to put the Deface's files. A few months ago the files were put at config/initializers, now the Deface look at app/overrides. There isn't this information at the documentation.

Thanks ;)

Hi

My problem is, if someone defined overrides in a gem with the option

:disabled => false

Example: https://github.com/jsqu99/spree_flexi_variants/blob/master/app/overrides/add_ad_hoc_option_types_to_cart_form.rb

It isn't possible to disable this override in my rails app (which includes the gem) using this:

Deface::Override.new(:virtual_path => "spree/products/_cart_form",
                     :name => "converted_product_price_733808074",
                     :insert_after => "[data-hook='product_price'], #product_price[data-hook]",
                     :partial => "spree/products/ad_hoc_option_types",
                     :disabled => true)

My Gemfile.lock shows this Version of deface:

deface (0.8.0)
      nokogiri (~> 1.5.0)
      rails (>= 3.0.9)

Thanks

Matthias

All my Deface Overrides are being called 3 times in the same page load.

For example, I have the following override:

Deface::Override.new(:virtual_path => "spree/shared/_sidebar", 
                     :name => "subscribe", 
                     :insert_bottom => "aside", 
                     :partial => "spree/shared/subscribe",
                     :original => '583d3e1ae41e681779da7cdac8bee81e4efdb436')

When the page is loaded log shows:

Rendered spree_xxxx_theme/app/views/spree/shared/_cart.html.erb (2.9ms)
Rendered spree_xxxx_theme/app/views/spree/shared/_header.html.erb (6.4ms)
Deface: 1 overrides found for 'spree/shared/_sidebar'
Deface: 'subscribe' matched 1 times with 'aside'
Deface: 1 overrides found for 'spree/shared/_sidebar'
Deface: 'subscribe' matched 1 times with 'aside'
Deface: 1 overrides found for 'spree/shared/_sidebar'
Deface: 'subscribe' matched 1 times with 'aside'
Rendered spree_xxxx_theme/app/views/spree/shared/_sidebar.html.erb (1.4ms)

Everything is working fine in my app, but this behaviour seems very weird. Not sure what I have changed - in past overrides used to be called only once. Any idea on what might be causing it?

Thanks!

Hi There,

Looking at my production.log file, I get the following warnings.

[WARNING] You no longer need to manually require overrides, remove require for....

What does that exactly means?

Thanks for your help,
Michael

I've been trying to wrap the contents of a partial, irrespective of its markup, by selecting the first and last elements.
Although the :surround action doesn't support using a range of elements with:closing_selector I was under the impression that I could replicate the desired behavior using a combination of overrides. Unfortunately I couldn't even select the first document element with Nokogiri selectors. The *:first syntax returns the first nodes for each element type.
This is not a Deface bug, but I couldn't find a group/list to post this sort of question.
Thanks

I'm trying to deface my /products page based on the product name and struggling.

I need to remove any products which contain the string "xyz". I've got as far as the following but i'm not sure how i can specify the string...

Deface::Override.new(:virtual_path => "spree/shared/_products",
:name => "remove_xyz_products",
:replace => "[data-hook='products_list_item']",
:text =>"",
)

thanks

I was looking at working on Rails 4 compatibility, but I'm seeing a few errors like below in master. My ruby version string is "ruby 1.9.3p374 (2013-01-15 revision 38858) [x86_64-darwin10.8.0]"

  1) Deface::TemplateHelper load_template_source with overrides defined should return overridden source for partial including overrides
 Failure/Error: load_template_source("shared/post", true).should == "\n<%= \"And I've got ERB\" %>"
   expected: "\n<%= \"And I've got ERB\" %>"
        got: "\n<%= \"And I've got ERB\" %>\n" (using ==)
   Diff:
 # ./spec/deface/template_helper_spec.rb:53:in `block (4 levels) in <module:Deface>'

I followed the Spree Getting Started guide using Ruby 1.9.3 and Rails 3.1.1 and in a new project the login bar defacement wasn't in effect. I believe that this is a bug in Deface and not Spree.

Apologies, but I haven't had the time to investigate this issue right now. Hopefully this GH issue will serve as a reminder to me to investigate it later if someone doesn't beat me to it first.

Hi, it's Matthias

After bundle upgrade which contained the new versions of deface I got the following error after rails s:

=> Booting WEBrick
=> Rails 3.1.1 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
Exiting
/usr/lib/ruby/gems/1.8/gems/deface-0.7.1/lib/deface/override.rb:98:in initialize': :action is invalid (ArgumentError) from /path/to/railsapp/app/overrides/test_override_without_action.rb:1:innew'
from /path/to/railsapp/app/overrides/test_override_without_action.rb:1
from /usr/lib/ruby/gems/1.8/gems/activesupport-3.1.1/lib/active_support/dependencies.rb:234:in `load'
...

using the following code:

Deface::Override.new(:virtual_path => 'existing/path',
:name => 'existing_override_name_from_extension',
:disable => true)

This error appears with existing and nonexisting override name and on deface 0.7.1 and 0.7.2

If i add an empty insert_top and empty text it works again so its not a big problem.

Thanks

Matthias

Ps: Great Gem

I am trying to override the user login

Deface::Override.new(:virtual_path => "spree/user_sessions/new",
:replace => "[data-hook='login']",
:namespaced => true,
:name => "my_store_login",
:partial => "my_store/user_login")

with the following HAML partial

my_store/user_login.html.haml

= render :partial 'spree/shared/login'
= t(:or)
= link_to t(:create_a_new_account), spree.signup_path
= t(:or)
= link_to t(:forgot_password), spree.new_user_password_path

but an error is raised with haml :
=> undefined method `render' for #Object:0x007ff6b2a80380

trace log ...
(haml):1:in block in render' haml (4.0.0) lib/haml/engine.rb:129:ineval'
haml (4.0.0) lib/haml/engine.rb:129:in render' deface (0.9.1) lib/deface/haml_converter.rb:4:inresult'
deface (0.9.1) lib/deface/template_helper.rb:24:in load_template_source' deface (0.9.1) lib/deface/override.rb:131:insource'
deface (0.9.1) lib/deface/override.rb:185:in source_element' deface (0.9.1) lib/deface/applicator.rb:45:inblock (2 levels) in apply'

what's wrong with haml ?

Not really an "issue" so sorry to post it here, but wasn't sure how else to get in touch! :)

I just wanted to know if there is anything holding back the DSL branch from being merged into master and released as a gem? And if so, if there is anything I can do to help speed up the process, I will gladly work on any bugs/documentation if needed!

The reason I'm asking is I'm developing a gem for conditionally adding new features to a rails app (https://github.com/balvig/chili) and it's making use of features in the DSL branch but as far as I understand I can't add deface to the gemspec unless it is actually released as an official gem!

Hi everyone, When try to migrate I have this error, It 's so strange .
Did you see this before? PLease help me find out this bug

I use rails 3.1.3 , ruby 1.9.2p and ,My gem file:

gem 'deface', :git => 'git://github.com/railsdog/deface.git'
....```

and error in 
```:action is invalid
/home/wf04/.rvm/gems/ruby-1.9.2-p290/bundler/gems/deface-d749e05cc971/lib/deface/override.rb:110:in `initialize'```

Thank you :D

@BDQ: can you please create a branch and bump dependency to rails 4.0.0.beta? 'cause I am starting to poke into making Spree fully-compatible with Rails 4.

The following HAML in spree_application.haml

- x = 1
%body(class='one')

Gets rendered without the attributes:

<body>
</body>

Removing the assignment line makes it render correctly, which doesn't make sense as it shouldn't have any effect on the output.

Happens in any of the following combinations:

• Spree: 1.1.0 - 1.2.0
• deface 0.9.1 - 1.0.0.rc1
• haml: 3.1.7 - 3.2.0.rc1
• nokogiri: 1.5.5

Regression from Spree 1.1.0beta , deface 0.8.0 , haml 3.2.0.alpha.13

Might be a side effect of Nokogiri, from the deface README:

1. Ensure that your layout views include doctype, html, head and body tags in a single file, as Nokogiri will create such elements if it detects any of these tags have been incorrectly nested.

Used to enable / disable overrides by engine.

I have just tried to customize this template in Spree: https://github.com/spree/spree/blob/master/core/app/views/spree/admin/products/new.html.erb

It can be loaded in 2 ways:

1. By going directly to /admin/products/new - then loads properly and deface works as expected
2. By loading via AJAX, then it's rendered indirectly, via https://github.com/spree/spree/blob/master/core/app/views/spree/admin/products/new.js.erb

Problem is with 2nd case: deface cannot handle it and original template is rendered within javascript template.

Hello,

I'm trying to make deface work since a few hours, but with no success.

I've made a very basic example rails 3.2.6 app with:

# Gemfile:
gem 'deface'

A basic controller & view:

rails g controller index home

At this point, my app works, and openig the view in a browser shows the classic:

<h1>Home#index</h1>
<p>Find me in app/views/home/index.html.erb</p>

I'm trying to add a deface override;

#app/overrides/index/home.html.erb.deface:

<!-- insert_after 'h1' -->
<h2>These robots are awesome.</h2>

I restart the server, but no results (server starts, but the view is not 'defaced').

And "rake deface:precompile" outputs:

Unable to precompile 'home' due to: 
can't convert nil into String

I've uploaded the code here so you can take a look:

https://github.com/danielres/test-deface

Any idea ? Am I missing something ?
Thank you.

This is more of a feature request than an issue.

Is there a reason that :insert_top and :insert_bottom require there to be an already-existing element inside the target? It seems to me that if this restriction were not in place, they (or simply :insert) would be a good way of having content inserted inside an empty element. I believe that currently we have to :replace an element with itself plus its new content to achieve this.

(As an aside, I'm a new Ruby/Rails/Spree user and spent about three hours last night trying to figure out how to get Deface rules to stick. I finally figured out it was because I was using :insert_top on an empty element. :-) )

Gets a nil in

/deface-2a1af4fc423d/lib/deface/override.rb:238:in `apply'

when .children is called without checking.

PS: latest source as of 10.9.

The following additional action would help adapt to existing stylesheets or changing the structure of a view.

In it's simplest form it could be documented like this:

Action

• :move_before - Move element selected by parameter :from. The supplied selector is expected to select only a single element.

Optional

• :from - A Selector specifying which element should be removed from it's original place and be inserted at the selector parameter for :move_before

I'm not exactly sure if move_before and move_after should be accompanied by move_to, and move_bottom.

Another possible API would be to add another two source types:

Source

• :cut - A Selector specifying which elements should be removed from it's original place and be inserted at the selector pointed to in insertion actions
• :copy - A Selector specifying which elements should be copied and be inserted at the selector pointed to in insertion actions

Thanx for this gem, btw!!!
Cheers
Simon

Hi, I'm sorry to be posting here. I know Github isn't a tech support forum but I couldn't find anything relevant on google.

For a simple Deface override on Spree 1.0.3, I do

Deface::Override.new(
:virtual_path => "spree/products/show",
:replace=>"div#main-image",
:text=>"Hello World",
:name=>"want_to_do_something",
)

This works.

But what I want to do is to target the product image after the id #main-image. I tried adding :replace=>"div#main-image img" and a few combinations such as "div#main-image img:first", but at no point was the image replaced with hello world.

Sorry what am I missing out? Does Deface work on the ERB layer only and hence "img" doesnt work?

Solved this one for myself, want to throw it up here for posterity's sake.

Basically if you had a manual require in your config/application.rb (or another similar Railtie configuration file) to the file(s) containing your overrides that deface already knew about, app/overrides most likely, it would get loaded twice.

This not a problem normal, but there is an edge case that makes it troublesome.

In production, or any environment set to cache classes with config.cache_classes = true as well as config.deface.enabled = false the following happens:

1. Manual load of app/overrides
2. rake deface:precompile is run, since we disabled it
3. Deface clears its Environment (https://github.com/spree/deface/blob/v0.9.1/tasks/precompile.rake#L13)
4. Deface goes through and loads each railtie's overrides, but in this case it won't be a load, it will be a require instead.

Since the app knows the file to be required already, this will return false, nothing loaded.

Deface already warns about manually requiring overrides, but it can't hurt to have this here.

This is similar to the behavior reported in spree/spree#2633

Test this issue with:

https://github.com/spree/spree/tree/jruby
https://github.com/spree/deface/tree/master
jruby-1.7.3

Look at the HTML source of the index page or run it through http://validator.w3.org/ to see all of the errors this generates. First few lines of the doc as a sample:

<!DOCTYPE html>
<!--[if lt IE 7 ]> <html class="ie ie6"  lang="en"> <![endif]--><!--[if IE 7 ]>    <html class="ie ie7"  lang="en"> <![endif]--><!--[if IE 8 ]>    <html class="ie ie8"  lang="en"> <![endif]--><!--[if IE 9 ]>    <html class="ie ie9"  lang="en"> <![endif]--><!--[if gt IE 9]><!--><html lang="en">
<!--<![endif]-->
<head data-hook="inside_head">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<!-- Spree Analytics has not been initialized correctly -->

</head>
<body>
<meta charset="utf-8">
<title>Spree Demo Site</title>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
<meta content="width=device-width, initial-scale=1.0, maximum-scale=1" name="viewport">
<meta content="spree, demo" name="keywords" />
<meta content="Spree demo site" name="description" />

Seems like deface precompiling does not load engine app overrides.
Or they get overrided by main app overrides during precompilation.

Tested with deface 1.0.0rc1 and spree app 1.2

Setting config.deface.enabled = false in the production environment config when you have initialize_on_precompile disabled in config/application.rb will cause the following error:

undefined method `deface' for #<Rails::Application::Configuration:0x007fce85dc5fe0>

My workaround is to actually add a guard like this - if config.respond_to?(:deface)

I'm guessing there's another place the config setting can be defined so that it's available without initializing?

Hi,

I was really glad to see the precompile option added to deface. I use deface quite widely for Spree Commerce and the precompile would certainly give a great boost - GREAT JOB Deface Team!

However, recently I've added several haml partials rendered through deface. When I try to precompile it on server using:

bundle exec rake deface:precompile

I got an error:

uninitialized constant Deface::HamlConverter

Do you have any idea how to correct it?

It would be very useful to have a syntax in Deface allowing to wrap around a selector-matching element with some two-part code.
The obvious usecases:

• wrapping with conditionals
• wrapping with cache block (fragment cache)

Actually the second usecase would make it an awesome addition.

I have no idea for the syntax extension. How about

:text => '<% if(true) %>{original}<% end %>'

at least for now?

I don't know how hard would it be to wrap my head around Deface codebase, but in case I succeed, are you open to pull requests?

I use rails 4.0.0.rc1and got error

undefined method `all' for #<Rails::Engine::Railties:0x007fcb3c918390> (NoMethodError)

%html{lang: en}

... will fail with a NoMethodError: undefined method lang for Object ...

I recently ran into an issue on a project where one override was removing a block of content with a selector of #header h1, and another override, for the same view, was inserting a block of content after #header h1.

We didn't really notice the issue until we had scaled up in production to two different web servers. Refreshing the page would sometimes insert the block of content, and sometimes it would not. It was baffling, and it took quite a while to track it down. The conclusion we came to is that the order that Deface uses to apply the overrides is not deterministic.

The solution we're going with is pretty much "don't do that", don't write Deface overrides that can be affected by another deface override. But it got me thinking about whether or not there should be some control over the order that the overrides are applied in.

I've listed out a couple of different options that I thought of. I'd like to collect feedback on which direction to go in, and then I'll work towards a patch.

before and after

Add before and after as options to the Override class. These will be used to sort the overrides before they are applied.

numeric order

Add a order option to the Override class. This will be used to numerically sort the overrides before they are applied. A warning (or error) can be produced if there are two overrides with the same value.

alphabetical ordering

Sort the overrides alphabetically by virtual_path and name. This limits the amount of control that users have over ordering, but it would make things deterministic. If someone wants to manipulate the order, they can always manipulate the filename.

Would be great to allow string targets in addition to a view path target.

Hey Brian,

Precompilation of defaced views was broken for me for any environment that had config.deface.enabled = false.

Deface decides whether to load its action_view_extensions.rb at Rails boot time via https://github.com/spree/deface/blob/master/lib/deface/railtie.rb#L53-55

And by the time the enabled flag is turned on by the template_helper.rb in https://github.com/spree/deface/blob/master/lib/deface/template_helper.rb#L17 it is already too late.

This is what I did for now, for my own purposes: jumph4x@f369a79

I am not attaching this as a pull request for the obvious flaw: should this code ever run in the context of a loaded app on a server, the code does not unload the extensions or rewrite the method alias chain.

However, for running rake tasks this is fine.

If you want to throw a suggestion for how you'd rather have this handled, I'll send you a proper pull request.

Cheers

rake deface:test_selector['admin/products/index','table//th[@data-hook]']
Querying 'admin/products/index' for 'table//th[@data-hook]'
---------------- Match 1 ----------------

but when I attempt an insert_top or other , I get a nil exception

I read about the HAML compatibility.
I like to use slim-html (http://slim-lang.com/), is it possible to make deface compatible with slim-html?

It seems deface assumes an ActionView template is either ERB or HAML, but that's of course not the case. I hit the problem when trying to write a plugin for Redmine, which has its own DSL for API, used in views with the same "virtual_path" as some other html views.

I didn't find any way to tell deface to process only app/views/issues/index.html.erb but not app/views/issues/index.api.rsb for instance. Is there anything I missed ?

To be clearer, I reproduced the problem with a minimal rails app available here: https://github.com/jbbarth/defacepb

If you confirm it's a bug, I can work on it and issue you a pull request with corresponding specs.

Using jruby-head, deface outputs erb that is missing the leading <% or <%=...

This Gist shows the output (pasted from firefox)

Swapping to MRI resolves the problem (confirming it's a jruby thing)

Trying to use Deface as a simple way to let people customize Diaspora and I've run into a problem. I've traced this down to Deface::HamlConverter#deface_attributes not liking the following two lines in layouts/application.html.haml

    %meta{'http-equiv' => 'X-UA-Compatible', :content => 'IE=edge,chrome=1'}
    %meta{:name => "author", :content => "Diaspora, Inc."}

I've forked Deface and written tests for this, which I'm about to push to a branch (wanted to open an issue first so I could reference it in the commit message), but haven't found an easy way to fix it without breaking other tests.. lol

Rails server throws and ':action is invalid (ArgumentError)' error when the file has a .deface extension, for example, remove_shipping_phone.deface.

In order to gett it working, the file needs to be renamed to .rb, so no errors are thrown.

This happens with version 0.9.3 and ~1.0.0 of Deface.

@BDQ

This file:
https://gist.github.com/49c9eb8b3987c44b3ca7
results this output:
https://gist.github.com/4d1c4d3bada2608f328e

Looks like Deface DSL treat everything in html comments as ruby code.

Renaming an override between requests in development mode, the old name / override will still be defined.

Need to add clearing of the deface config between each request (as the overrides have to be reloaded on every request anyway).

Hi, here is a live example:
https://github.com/spree/spree/blob/master/core/app/views/spree/address/_form.html.erb

<p class="field" id=<%="#{address_id}address2" %>>
    <%= form.label :address2, t(:street_address_2) %><br />
    <%= form.text_field :address2 %>
  </p>
  <p class="field" id=<%="#{address_id}city" %>>
    <%= form.label :city, t(:city) %><span class="required">*</span><br />
    <%= form.text_field :city, :class => 'required' %>
  </p>
  <p class="field" id=<%="#{address_id}country" %>>
    <%= form.label :country_id, t(:country) %><span class="required">*</span><br />
    <span id=<%="#{address_id}country-selection" %>>
      <%= form.collection_select :country_id, available_countries, :id, :name, {}, {:class => 'required'} %>
    </span>
  </p>

I need several overrides for this one file:

1. Remove id=<%="#{address_id}address2" %>, I've never seen how is it used
2. Set default country for id=<%="#{address_id}country" %>, because my aim is to custmize spree for local, not for world-wide.
   Right now two overrides in one file does'nt work. The last one only works:

#Hide 2nd address
Deface::Override.new(:virtual_path  => "spree/address/_form",
                     :remove => "p[data-erb-id='<%=\"\#{address_id}address2\" %>']",
                     :name          => "checkout_address")

#Set fixed country to Russian Federation
Deface::Override.new(:virtual_path  => "spree/address/_form",
                     :remove => "p[data-erb-id='<%=\"\#{address_id}country\" %>']",
                     :name          => "checkout_address")

I suppose that patting together all overrides declarations for one file into one file is a clean point. Make several files containing 3-5 lines of code is not good...

the info-level logging in lib/deface/applicator should be debug level. It's not necessary to know this detail in production.

cf http://stackoverflow.com/questions/12991000/silence-deface-log-output/13021388

I'm theming a Spree site with Deface. When working with Spree 1.0.3 (Rails 3.1.4) I was able to make changes to Deface overrides and have the changes show up after new http requests, without having to restart the server (in development). Now I'm on Spree 1.1.0 (Rails 3.2.3) and it seems that I need to restart the server in order to see the override. Any idea what this might be?

because deface extensively use activesupport and actionpack, i think deface should selectively choose gem to depend on.