- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 591
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
V 5.4.0 breaking change to Object.friendly.find method #950
Comments
I'm pretty keen to revert this change and make it opt-in by default. I'll open a PR with the revert to start things off. |
Edit My bad! This will really be "opt-in", and wouldn't be a breaking change. |
This also broke our slugs on wpvulndb.com, reverting back to version 5.3.0 fixed the issue.
|
Me too! updating to 5.4.0 on MilRevolts.life |
In #787 we merged a change which found slugs by `id.downcase` by default, but this has understandably caused issues for other users of FriendlyId who don't want to do this. This reverts that change and introduces a new method, `parse_friendly_id`, which can be overridden similar to `normalize_friendly_id`. Instead of being used for slug generation, `parse_friendly_id` is used for parsing incoming slugs. Fixes #950
Before merge of 787, one could pass a mixed-case slug to friendly.find as such:
Customer.friendly.find(params[:id
])We don't use the customer name for the slug; rather we used SecureRandom.urlsafe_base64 to generate a random string. Thus the slugs for our customers contain a mix of upper and lowercase characters. At this point we have thousands of customers with mixed-case slugs in our databases.
Because this is breaking (for us) some kind of opt-in to the new behavior would seem to make the most sense.
The text was updated successfully, but these errors were encountered: