Handle same slugs at different positions in a structure

[jasonvarga]

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.

[jasonvarga]

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.

[aryehraber]

Hit this today and was about to create an issue. Glad to see it's on the roadmap!

[benfurfie]

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.

[tao]

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

[tao]

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);
    }
}

[Lampone]

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.

[jasonvarga]

The initial plan we discussed internally was to allow an arbitrary string to be added to the end of the filename.

[felixstoessel]

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...

[felixstoessel]

@jasonvarga When there is no quick way to solve this without refactoring everything, maybe add a rough workaround?

[github-actions]

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.