Hello,
It would be very nice to have a slug field type that is a kind of formula link to a text and change it to a slug.
Thank you
1 Like
A slug? 
1 Like
@Peter I think that @ozzz means a different type of slug 
.
@ozzz Would a formula function to convert a text value be an option for you? So if you have a formula function like slugify(field("Name")). If the Name field then has the value “Test Name”, the slugify formula would then convert it to “test-name”.
1 Like
I was looking for this as well. Would it be possible to have access to regexp_replace() for this and similar string manipulation use cases?
It’s built into postgres (regexp_replace), and there is a PR to make this accessible in Django.
This indeed sounds like a useful idea to have a general function like regex, and as you say it is doable.
@mjadobson This function is already exposed in Baserow formulas:
Under the hood this is the regexp_replace postgres function with the g flag set.
2 Likes
Amazing, not sure how I missed this!
A user-created slugify function would look something like this then:
regex_replace(trim(regex_replace(lower(field('Name')), "\W", " ")), "\s+", "-")
1 Like
I can also do snails 
1 Like
It will not works on accent and other latin characters…
@ozzz can you give some examples and what it should be instead? Accents/unicode characters work for me:
Sorry I need to replace the accent by the same letter without accent
Tésla → tesla
same for ç or ’ and so on
You can use regex to replace the diacritics, although it will take many regex functions to cover them all.
eg:
regex_replace("tésla", "[èéêëēėę]", "e") // tesla
Postgres has the unaccent() module which would be preferable I think.
Hm, unaccent looks nice. However right now we haven’t figured out a nice way of enabling postgres extensions like unaccent easily/automatically for self hosted users:
Running CREATE EXTENSION unaccent in a migration will fail unless the user running the migration is a superuser on the postgres server (which the baserow user is almost certainly not.)
In the future we hope to offer easy to install plugins, perhaps then we could offer optional plugins which require a manual step (like running CREATE EXTENSION unaccent as superuser on your DB).
Alternatively for our docker and docker-compose users using the bundled postgres we can probably do this automatically as I believe we have access to the superuser user. Then I guess for other self-hosting users we could only enable the formula function using unaccent if we detect the extension. if we don’t detect it then I guess we could show a pop-up asking the admin to run the SQL to fix it?
unaccent() and similar modules definitely seems like something that should be a plugin for those who need it, rather than built-in. It would be nice to have a plugin store to easily install these things.
It also occurs to me that url slugs are a significant use case for unique field constraints:
Either by not allowing copies, or automatically appending “-2” to the end.
I suspect I will need to implement this with webhooks for now.
Also touches on this: