Increment slugs when accessed indirectly in URI formats

[yoannisj]

Currently, Craft-CMS adds an incrementing index to slugs when validating elements with a URI, in order to avoid duplicate element routing URLs. However, it only does so if the element's uriFormat contains the {slug} token explicitly.

Sometimes, the logic to generate the element's URI is more complex, and using a function in the uriFormat (e.g. {{ craft.myModule.elementUri(element) }}) is more convenient and easier to debug than a complex Twig expression which lives directly in the project config. When such a method accesses the slug internally, Craft does not detect it and adds a validation error to the element's uri attribute instead of trying to modify the slug.

Craft-CMS could observe the slug attribute on the element model (using a property getter/setter?), in order to detect it being used in the dynamic URI and apply its slug incrementation logic even if the {slug} token is not present in the element uriFormat.

[yoannisj]

Alternatively to observing access to the slug property, the \craft\helpers\ElementHelper class could expose the logic it uses to increment an element's slug (currently implemented in the \craft\helpers\ElementHelper::setUniqueUri(), which skips this logic when the {slug} token is not present in the uriFormat).

This way, a module or plugin could try and rectify the shot using the \craft\base\Element::EVENT_AFTER_VALIDATE event:

use yii\base\Event;
use yii\base\ModelEvent;
use craft\base\Element;

Event::on(
    Element::class,
    Element::EVENT_AFTER_VALIDATE,
    function(ModelEvent $event)
    {
        $element = $event->sender;

        if (
            $element->hasErrors('uri')
            && !ElementHelper::doesUriFormatHaveSlugTag($element->uriFormat)
            && strpos($element->uri, $element->slug) !== false // maybe checking for the presence of 'craft.myModule.elementUri(' in the uriFormat instead?
        ) {
           try {
              ElementHelper::incrementSlugForUniqueUri($element); // logic from `ElementHelper::setUniqueUri()` but without checking for the '{slug}' token
              $element->clearErrors('uri');
           } catch (OperationAbortedException) {} // leave the error on the model's 'uri' attribute
        }
    }
);

However, this approach puts the responsibility of "fixing" Craft's expected behaviour on the project developers. It also requires more computation, and potentially complex/unreliable if statements to detect whether the slug is used to render the element's URI.

---

Update: I just realised that this approach would actually break validation if Craft or a plugin adds other validation rules to the element's uri property...

[brandonkelly]

Craft-CMS could observe the slug attribute on the element model (using a property getter/setter?), in order to detect it being used in the dynamic URI and apply its slug incrementation logic even if the {slug} token is not present in the element uriFormat.

We used to do something like that, but changed it due to errors like #2995.

I’ve added a new EVENT_SET_ELEMENT_URI event to the Elements service for Craft 4.6, which can be used to completely override how the URI gets defined (5d5c79c).

[brandonkelly]

Craft 4.6.0 is out now with that new event.