-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Rails 5 Compatibility PR #575
Conversation
Problem: The `bin/merge` script only works for merging in branches on the original repository. Any contributor PRs whose branches live on forks won't be mergeable with the original script. Solution: Create a second merge script that can merge branches from forks of the repo.
…sue was fixed since Rails 4.0.beta.
Allows for rails 4/5 concurrent testing
This can't exist here unless that gem is brought in. The gem itself should require itself- otherwise it's a fake dependency.
config.public_file_server.headers = { 'Cache-Control' => 'public, max-age=3600' } | ||
else | ||
config.serve_static_files = true | ||
config.static_cache_control = 'public, max-age=3600' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer double-quoted strings unless you need single quotes to avoid extra backslashes for escaping.
I've just setting up this gem from this branch in a fresh Rails 5 RC1 app. The generator fails with this error:
I haven't dug into the code but I'm guessing its looking for sub-classes of ActiveRecord::Base and not checking to see if they are abstract? |
@lukeredpath: hey Luke! is your app not hooked up to any db at all? It does appear to use |
@lukeredpath can you open a new issue for this? I have a feeling its because administrate may not be respecting the |
Linking this PR here for historical reasons: BenMorganIO#1 |
@BenMorganIO sure, done |
Alright, so I just happen to be working on a Rails 5.0.0.rc1 app right now that is getting nicely sizable. @imajes I'll be using your branch this week. I totally want to get your work in. Let's aim for Monday next week after some battle testing for Rails 5 compatibility 😄 . In the mean time, how do you feel about splitting you +237 lines of code out into smaller PRs? The |
@BenMorganIO: do you have write access to this repo? |
@imajes that's on the way from what I hear :) cc @Graysonwright |
If you are using this branch with ruby 2.3.1 it won't build, had to fork this branch and change the Gemfile ruby version. Not sure if thats expected behavior... Edit: this gets fixed with #591 |
@Graysonwright: so.... any particular reason you haven't responded to this PR? |
This will be merge any time soon ? |
{params: args} | ||
else | ||
args | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could probably change this to a ternary operator here:
Rails::VERSION::MAJOR >= 5 ? { params: args } : args
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
more than ternary it should be a guard clause, no?
def kwarg_params(args)
return { params: args } if Rails::VERSION::MAJOR >= 5
args
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, that's another solution. I would opt for the ternary mainly because I think the purpose of the method is to format the params if its greater than or equal to Rails 4... If we had to use guard clauses, I think a more optimal outcome would be:
def kwarg_params(args)
return args if Rails::VERSION::MAJOR <= 4
{ params: args }
end
🚲 🏠
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this is the worst place to put in any kind of optimal code. This is a yak shaving method to bring about compatibility in a situation where the api has broken.
It will eventually be removed, but till then it should be as self documenting as possible and as plain spoken as possible lest it turn into an actual valuable feature.
On May 24, 2016, at 22:49, Ben A. Morgan notifications@github.com wrote:
In spec/controllers/admin/customers_controller_spec.rb:
expect(response).to redirect_to(admin_customers_url) end
end
- def kwarg_params(args)
- if Rails::VERSION::MAJOR >= 5
{params: args}
- else
args
- end
Yep, that's another solution. I would opt for the ternary mainly because I think the purpose of the method is to format the params if its greater than or equal to Rails 4... If we had to use guard clauses, I think a more optimal outcome would be:return args if Rails::VERSION::MAJOR <= 4
{ params: args }
🚲 🏠—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
I made a PR to greetpoint/rails5#2 updating kaminari, because if your dashboard needs pagination it will crash with the old kaminari version |
Update Kaminari, bug fix
Maybe update kaminari to 1.0.0.alpha? |
Hey guys, how is your progress? |
How is it going, guys? |
Can this PR be closed? It looks like Rails 5 support has been merged in with #636 |
I don't think the master branch is ready for Rails 5 yet. For example, the app/views/administrate/application/_search.html.erb line 17 still generates this error: "Attempting to generate a URL from non-sanitized request parameters! An attacker can inject malicious data into the generated URL, such as changing the host. Whitelist and sanitize passed parameters to be secure." I've been using @v-kumar's branch from #656 which resolves all my Rails 5 issues, but the current master does not. |
I’ve been using the master branch with Rails 5 for a few days of development now, and am not having the sanitized params problem. I was on commit 84096c for a while, now e533a6:
@pedantic-git, what commit are you showing? |
My bad — the fix isn’t in |
Closing as we now have Rails 5 support in |
There are a couple other PRs to deliver Rails 5 compat, but this one should pass specs, and be mergeable.
I've focused mostly on:
Regarding the strong params issue, my approach doesn't blanket permit (which is going to be a security vulnerability, due to the abstract way it's implemented and the potential for scriptable exploits). Instead it permits specific, expected params. I don't know if this is sufficient, and we may need to extend this with some of the
ATTRIBUTE
constants to encapsulate all of the expected params. Will text this further as I integrateadministrate
into my own app.There is one deprec notice remaining that is particularly annoying; resolving it removes rails4 test compatibility. I considered wrapping the calls in a deprecation silencer, but felt that isn't a good idea given how it may be missed later. One option may be overriding the specific deprecation notice to silence it.-- since resolved that with a wrapper def.