If you want to try my patch above, you can force apply it from your app.yml file. At the very end:
## Any custom commands to run after building
run:
- exec: echo "Beginning of custom commands"
- exec: if grep -q 'uri.encoding == US_ASCII' $home/vendor/bundle/ruby/2.3.0/gems/actionpack-4.2.9/lib/action_dispatch/journey/router/utils.rb ; then curl https://meta.discourse.org/raw/67232/17 | patch -p0 -u -d $home ; fi ; true
The “Beginning of custom commands” is already in the standard app.yml, the change is the long line right after that. What it does:
if grep -q 'uri.encoding == US_ASCII' ... then if the patch hasn’t been applied
curl https://meta.discourse.org/raw/67232/17 then download the raw post with the patch
patch -p0 -u -d $home apply the patch (patch is smart enough to ignore the “garbage” post text)
fi; true always return true so Pups will be happy
But note that this is not a Discourse approved patch and hasn’t seen a whole lot of testing. It works for me, but who am I?
(I submitted it to Rails, and it was rejected because this is fixed in another way in Rails 5. But Discourse is still on Rails 4.)
@blake might have already let the team know, but we’re definitely impacted by this one (and we’re paying customers). It’s an issue for our users (biggest concern) and for the old search bots (much smaller concern). Any thoughts on timing/priority for the Discourse team?
It looks like this is fixed in Rails 5 but it is unclear when we can move Discourse to that (we are currently on Rails 4). There are typically a lot of performance regressions in each new release of Rails that we have to help fix, so it takes some time for us to move.
when the slug generation method is changed to “encoding”, the spaces between each two words in the topic titles changes to - and it makes the topic list page very unclean.
if the patch hasn’t been applied
