Removing the concept of "slugs" for some languages

Probably not, as I’d venture to guess he has zero to little programming knowledge. Discourse is getting a lot more CM (Community Manager) attraction now and a lot of those who are engaging here on Meta are no longer devs/programmers, but the CMs. To ask a CM to submit a PR is just unrealistic.

Just for clarification, there is a big difference between changing CSS/SCSS and actual programming changes. I have no idea what @Qasem_h’s experience is, but I definitely see more CMs participating in Meta than what were here several months ago.

7 Likes

i don’t mean i cant send pull request i mean how i can send pull request for slugs

I think we should add this for 1.4.

1 Like

I am working on it. Maybe I can submit the pr in next 24h.

It depends on your judgement about the release date. So it’s your call to consider whether merge it or not. I hope it can catch up 1.3 personally.

EDIT:

Here it is.
https://github.com/discourse/discourse/pull/3370

7 Likes

@fantasticfears can you give some screen shot of your work ?

Sure.

Settings:

For topics:

english

encoded

default

For categories:

encoded

default

5 Likes

I don’t think that the “default” option is very useful - call it “none” instead.

4 Likes

Would it be possible to rename the English method to Latin, ASCII or something like that? English is somehow misleading…

5 Likes

@fantasticfears this looks great but I agree with @gerhard, name it “ASCII” instead.

1 Like

Updated, just renamed english to ascii. Thanks @gerhard!

6 Likes

I think we are done with this, closing, thanks @fantasticfears

@fantasticfears I am reopening this cause this needs urgent polish (in fact make this your #1 priority)

Issues I have:

  • If a topic has the test งಠಠง and slug generation method is “encoded” the slug is test-งಠಠง. This is a nasty problem cause the actual UI will cause a fight with the browser. The browser sends over the slug as test-%E0%B8%87%E0%B2%A0%E0%B2%A0%E0%B8%87 and we perform no decoding on our side which leads to an infinite redirect in the topic page, if you hit reload. It feels to me like “encoded” should be always percent encoded.

  • If you change slug generation method there is no way of “fixing” the slug cache in “topics” table. There needs to be some mechanism of clearing out the “slug” column on topics. Maybe if you touch that setting it should automatically null out all cached slugs on topic.

As it stands we are seeing some extreme issues here with infinite redirects and there is not clean way of correcting the customer issues.

7 Likes

OK, I’ve researched into Rails router, Rack and Webrick. According to previous dev discussion, I am sure Rails conforms to Rack behaviour. This might not be ideal for us. Though I didn’t check, I have some confidence to say that Puma and Unicorn don’t escape non-ascii for URI. In contrast, Webrick does conforms to this point but it pins the uri into US_ASCII. It would be a complicated debug process to hunt down the cause. It might be regexp failure, encoding problem for Rails router GTG.

My step would be:

  1. Escape our Slug detector fast to fix urgent problem.
  2. Find a place to report this problem or write PR. I am not familiar with Rails community. I would like to ask for your direction later.
4 Likes

Sure, but we also need to make sure we deal with history AND switching slug generation mechanisms. Both are critical we deal with. When you switch mechanisms on categories it is particularly complicated cause we allow overrides.

2 Likes

I think this is all working properly now that we upgraded to rails 5 ? @tgxworld ?

1 Like

Yup, we just had to teach people how to “re-cook” all the slugs

I think only this is left. We had a number of support request coming in asking us how to “re-cook” the slug.

6 Likes

Fixed in

https://github.com/discourse/discourse/commit/d5293aeae258bd298a2d6d49134bca71cb00c6ed

7 Likes