It's reasonable to want two different pages to have the same slug in different positions in a structure. I even just ran into it in our docs.
|-- Fieldtypes
|-- Extending
|-- Fieldtypes
Since the slug is coming from the filename of the entry, it needs to be unique.
But the URLs are intended to be different.
Technically they could have different slugs, then have a separate field that overrides the slugs. eg fieldtypes.md and extending-fieldtypes.md with a slug_override: fieldtypes. Then the route could be {{ parent_uri }}/{{ slug_override or slug }}.
Not very elegant though. Can do better.
Our plan is to have slug.abc.md where abc is an arbitrary or random string to allow us to have duplicate slugs.
It makes sense (especially in a structured collection) to allow non-unique slugs. The probably is just a filesystem-specific one - you can't have two files named exactly the same.
Hit this today and was about to create an issue. Glad to see it's on the roadmap!
As you've said @jasonvarga, the issue is that the filename can't conflict. Is it worth adding a config in the collections set up that allows users to define the filename structure? That way the slug could be kept the same, but you'd perhaps use the datetime and slug together to create a unique instance?
I.e. Let's say on an investors site, you have two instances of a 'notification of major holdings'. You can end up with duplicates of these on the same day where two major investors both change their holdings enough to trigger a legal notification.
If you take just the slug for the filename (which legally has to be 'Notification of major holdings'), then you'd end up with a duplicate slug. However, if in the collection config, you allow duplicate slugs, you could then use datetime stamps to define them.
I.e. notification-of-major-holdings.202005240846.md vs notification-of-major-holdings.202005240847.md (the latter being posted one minute later). You could even get down to seconds if they needed to both be posted at 9am.
I would be interested in letting slugs be unique per date only, or be allowed to override this to make it possible when urls have the date included.... for example {year}/{slug}
1981-01-21.foo.md => www.site.dev/1981/foo
1981-02-25.abc.md => www.site.dev/1981/abc
1982-01-25.foo.md => www.site.dev/1982/foo
It seems like my specific problem mentioned might not be that related to this issue... but the easiest way to overcome this is to bind my own repository with custom validation rules.
public function register()
{
$this->app->bind(
\Statamic\Stache\Repositories\EntryRepository::class,
\App\Acme\Repositories\EntryRepository::class,
);
}
class EntryRepository extends \Statamic\Stache\Repositories\EntryRepository
{
public function createRules($collection, $site)
{
if ($collection == 'my_collection_name') {
return [
'title' => 'required',
'slug' => 'required',
];
}
return parent::createRules($collection, $site);
}
public function updateRules($collection, $entry)
{
if ($collection == 'my_collection_name') {
return [
'title' => 'required',
'slug' => 'required',
];
}
return parent::updateRules($collection, $entry);
}
}
Are there any plans how to handle this issue in the future? It seems like a architectural problem that is pretty difficult to solve at this point.
Wondering if I should switch to a database so i don't have to deal with filenames.
The initial plan we discussed internally was to allow an arbitrary string to be added to the end of the filename.
Well, we have a structure that has multiple contact slugs on different levels. For now, we have to use something ugly like contact-2. Not good...
@jasonvarga When there is no quick way to solve this without refactoring everything, maybe add a rough workaround?
This issue has not had recent activity and has been marked as stale — by me, a robot. Simply reply to keep it open and send me away. If you do nothing, I will close it in a week. I have no feelings, so whatever you do is fine by me.
Still an issue.
Still an issue for me, too. Doh @ my #3101 being so duplicative of this existing issue, but +1 for adding this as a high-priority #enhancement! Thanks @jasonvarga!
I am curious however, if using folders rather than arbitrary garbage in the file name is a feasible option?
I'd like to be able to review the content repository files and understand the collection item hierarchy better, rather than have all files in a single folder.
@skylennard You'd still have the same issue with folders though and it could become messy real quick. I'd be happy with just changing the filename to slug-1, slug-2. Or using the entries ID as a suffix. How many duplicate slugs do you have?
As per @jasonvarga's suggestion a workaround for now which may not be suitable in every case is to keep the actual slug unique and add an additional slug field eg. named fake_slug_field which can then be used in the collection's route like this: {parent_url}/{fake_slug_field}
This seems to be a fairly common issue to encounter as a lot of sites are structured in a way where the end slug is the same. It was one of the first things I had troubles with. A solution for me was to make three different collections and then it was happy with no conflicts but that only gets you so far. Although what that really accomplished was storying the entries in different directories.
It would be nice to have them stored in directories logically following the slug route. Having a random hash at the end of the file also feels like a band aid fix as while it allows you to create duplicate slugs in the control panel navigating through the file structure you won't know whether to edit contact.abc.md or contact.acb.md from a glance
Having the same issue here, would love to see the proposed arbitrary string solution or similar 👍
Please give a thumbs up to the original issue instead of the +1 type of comments. We'll be able to sort by most reacted issues to see which are most important.
I hope that there'll be a good solution. I really struggle with this issue because of my current project's site structure...
If "Enable Publish Dates" is enabled for a collection then the publish date is added to the filename already, making the filename already relatively unique. So perhaps duplicate slugs could be allowed in cases where publish dates are enabled and only supported in cases where the date is part of the route.
Granted, it's still not ideal but perhaps this would be easier to implement and provide partial duplicate slug support while a more all-encompassing solution is planned.
Most helpful comment
Hit this today and was about to create an issue. Glad to see it's on the roadmap!