You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the current implementation of implicit route model binding, it is only possible to query for slugs within the same locale. This becomes a problem when a link with a localized slug is shared to a person with a different locale configured. Even though the model exists, the user will get a 404.
Before creating a PR to address this issue, I'd like to hear a few opinions from you and @freekmurze on my thoughts so far.
I basically have two approaches, which are explained here.
I'd of course make this optional to avoid a BC.
Option 1
Search for the slug with REGEXP
This is by far the easiest approach, but noticeably worse performance wise for larger datasets.
Option 2
Create a separate table for the translated slugs which morphs to the model instead of storing them as JSON. This would be much better than executing a regex search on every page request. The slugs would then need to be unique for [sluggable_type, name].
The user experience would be similar IMO. It would only be required to publish the migration if the feature is wanted.
The only downside I could imagine is that it is slightly more complicated for the user to manually override a slug, as some admin panels already provide great support for laravel-translateable fields.
slugs
id - integer
sluggable_type - string
sluggable_id - integer
locale - string
name - string
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Why?
With the current implementation of implicit route model binding, it is only possible to query for slugs within the same locale. This becomes a problem when a link with a localized slug is shared to a person with a different locale configured. Even though the model exists, the user will get a 404.
Before creating a PR to address this issue, I'd like to hear a few opinions from you and @freekmurze on my thoughts so far.
I basically have two approaches, which are explained here.
I'd of course make this optional to avoid a BC.
Option 1
Search for the slug with REGEXP
This is by far the easiest approach, but noticeably worse performance wise for larger datasets.
Option 2
Create a separate table for the translated slugs which morphs to the model instead of storing them as JSON. This would be much better than executing a regex search on every page request. The slugs would then need to be unique for
[sluggable_type, name]
.The user experience would be similar IMO. It would only be required to publish the migration if the feature is wanted.
The only downside I could imagine is that it is slightly more complicated for the user to manually override a slug, as some admin panels already provide great support for laravel-translateable fields.
Beta Was this translation helpful? Give feedback.
All reactions