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
Support backslash in getSlug util #6691
Conversation
Signed-off-by: tedraykov <tedraykov@gmail.com>
🦋 Changeset detectedLatest commit: 8392ba1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
@@ -4,7 +4,7 @@ | |||
# | |||
# See comment in docker-compose.dev.yml if you want to run for development. | |||
|
|||
version: "3.4" | |||
version: "3.9" |
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.
Why does this PR include a change to the docker file?
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.
The syntax we use for the network declaration in the docker compose file is not supported in 3.4
networks:
reaction:
name: reaction.localhost
external: true
I had errors in the IDE so I decided to bump it. This does not bring breaking behavior from what I've observed. I had all my docker-compose files to version 3.9 locally for months and haven't encountered any problems.
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.
Good to go
Could add an additional test with string "new men/jacket" to get "new-men/jacket"
@@ -13,5 +13,5 @@ const { slugify } = require("transliteration"); | |||
* @returns {String} slugified string | |||
*/ | |||
export default function getSlug(slugString) { | |||
return (typeof slugString === "string" && slugify(slugString)) || ""; | |||
return (typeof slugString === "string" && slugify(slugString, { allowedChars: "a-zA-Z0-9-/" })) || ""; |
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 coming back to this I am concerned about this change being a global one and not specific to tags and may result in some unexpected behavior. I wonder if we can add a second argument of allowedChars, so that the default behavior remains the same.
Signed-off-by: tedraykov tedraykov@gmail.com
Impact: minor
Type: bugfix
Issue
When we save a slug that contains a
/
, the API automatically converts it to-
.For example, the tag slug
men/jacket
turns intomen-jacket
Solution
Extend the slugify function to support
/
charecter.Breaking changes
None
Testing
/
/