Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop extending into ERB the t and textilize #19

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

dmitry
Copy link

@dmitry dmitry commented Jan 25, 2015

Prevent injection of the t and textilize methods into a ERB module through the Util module. When using the i18n gem in Rails it uses textilize method, instead of translate (aliased as t) helper. It will be still possible to inject textilize into a ERB after this commit with a manual code:

begin
  require 'erb'
  require 'redcloth/erb_extension'
  include ERB::Util
rescue LoadError
end

@timoschilling
Copy link

removing:

    alias t textilize
    module_function :t

should be enough

@timoschilling
Copy link

This should work as hotfix:

require "redcloth"
class ERB::Util
  alias t translate
  module_function :t
end

@dmitry
Copy link
Author

dmitry commented Apr 7, 2015

@jgarber can you please look into the PR? Thank you!

@dmitry
Copy link
Author

dmitry commented Apr 30, 2016

@joshuasiler please merge this one.

@joshuasiler
Copy link
Contributor

I am happy to take a look, however I'm not 100% clear on what problem this is solving. Can you elaborate further? Won't this break expected functionality for some users?

@dmitry
Copy link
Author

dmitry commented May 3, 2016

@joshuasiler any specific solution?

I think most of the users instead of t they are using textile, as normally t is reserved for the translations. We could do minor release, and tell the users in the gem after install message that they have to update their code from t to textile, in other case it will break their ERB views.

@dmitry
Copy link
Author

dmitry commented May 3, 2016

Including include ERB::Util in the main thread not really good idea...

@joshuasiler
Copy link
Contributor

joshuasiler commented May 3, 2016

This makes sense to me, however I'm reluctant to suddenly change existing behavior on users and force a refactor, just based on my bad experiences with other libraries doing so and causing extra work. What about a version of this patch that adds a config flag? The config flag would default to current behavior, but display a deprecation/recommendation message to users along with the suggested setting. We could then remove it completely in a later major release.

@dmitry
Copy link
Author

dmitry commented May 4, 2016

@joshuasiler great, thanks for the suggestion! I will work on the patch very soon to deprecate it via flag.

@nruth
Copy link

nruth commented May 6, 2016

This does look like it should be opt-in instead of default.
A major version change should stop anyone (familiar with semver) being surprised about the API changing, and there could be docs showing how to transition / new usage.

@dmitry
Copy link
Author

dmitry commented Nov 10, 2016

@nruth any idea how it could be opt-in?

@joshuasiler
Copy link
Contributor

@dmitry Allowing the user to deprecate via a flag would effectively make the feature "opt-in"

@dmitry
Copy link
Author

dmitry commented Nov 29, 2016

@dmitry
Copy link
Author

dmitry commented Nov 29, 2016

@joshuasiler
Copy link
Contributor

We have RbConfig in the stack - you could use that to define a config variable, and then check for that variable and only include your mod if it's turned on.

@dmitry
Copy link
Author

dmitry commented Nov 29, 2016

@joshuasiler where it should be configured in the application? In config.ru before environment/application requirement? This changes are made when the gem loads, normally with Bundle.require method (at least in rails application.rb https://github.com/bundler/bundler/blob/master/lib/bundler.rb#L108).

@joshuasiler
Copy link
Contributor

Good question, and no easy answers. You're right it has to be set fairly early. Adding an optional config file would be one option. Or you could have an optional function to call like RedCloth.disable_erb_extensions() that applies the hotfix above...

begin
require 'erb'
require 'redcloth/erb_extension'
include ERB::Util

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This like also includes ERB::Util in the Object class. Even that t method is not removed I think this line should be removed.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it removed in the commit?

@dmitry
Copy link
Author

dmitry commented Jun 15, 2017

Can we proceed on this issue? I would like to push changes to the master.

Copy link

@kmcphillips kmcphillips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding methods to Object is pretty not great and is causing us problems with internationalization too:

Object.new.method(:t)
=> #<Method: Object(ERB::Util)#t(textilize)>

spec/erb_spec.rb Outdated

describe "ERB helper" do
it "should add a textile tag to ERB" do
template = %{<%=t "This new ERB tag makes is so _easy_ to use *RedCloth*" %>}
template = %{<%= textile "This new ERB tag makes is so _easy_ to use *RedCloth*" %>}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be textilize.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will change that now.

@@ -1,10 +1,11 @@
require File.dirname(__FILE__) + '/spec_helper'
require 'redcloth/erb_extension'

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Requiring this here requires it globally. Not just for this test. Better would be to create a test class and include it in there.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any idea how to do that? To preserve the same functionality (auto-inclustion to the ERB helpers), I believe it's impossible to do. This could be changed to use another module, include it into a ERB::Utils and then remove module later when test unit is completed. Let me know your thoughts.

@joshuasiler
Copy link
Contributor

This looks like a reasonable change, I'm open to merging. As a final step can you submit an update to the readme that explains this change? I'll release as 4.4

Prevent injection of the `t` and `textilize` methods into a `ERB` module through the `Util` module. When using the `i18n` gem in Rails it uses textilize method, instead of `translate` (aliased as `t`) helper. It will be still possible to inject textilize into a ERB after this commit with a manual code:

```
begin
  require 'erb'
  require 'redcloth/erb_extension'
  include ERB::Util
rescue LoadError
end
```
@joshuasiler
Copy link
Contributor

Also it looks like tests are failing - can you make sure they show green before we are ready to merge?

@kmcphillips
Copy link

@dmitry Are you able to complete this?

@GregThoma
Copy link

Attention: BREAKING CHANGE RedCloth 5.x series

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants