Best way to have a predefined set of specific but re-orderable elements.

[thupsi]

Sometimes I have a situation where I would like the author to have some elements that are predefined, but can be re-ordered.

Example:
A gallery page with 3 sections that are filled automaticaly (no need for the author to choose photos for each section)

• Rooms
• Garden
• Nearby points of interest

How would I make it so that the author is presented with just the option to choose an order for the above sections?

The closest I can get is with a table that has some default rows with row headers only, and the same min-rows and max-rows values:

The problem here is the disabled Add a row button, so that's not a huge deal. I wonder though if this button has a reason to be there in this situation, since you can't add OR remove rows?

Furthermore, what if I wanted the re-orderable elements to not be simple text strings, but specific entries, or assets?

Example:
A "Game" entry page that has specific players and the entry author must choose the order in which the players will play.

In this example the players could be represented by a "player" entry each, or even by a user element. The easy answer here is to have an entries field, but that adds a step (initial selection) and also there is no way for the author to be forced to select ALL the players.

Anyway, don't want to branch in different directions here, so maybe more complex situations belong in a FR.

Thoughts and suggestions appreciated!

[brandonkelly]

Interesting question. It seems like building this on relation fields is probably the most flexible, though it will require you to create new sections/entries even for the simpler use cases like your gallery page sections.

I’ve just added allowAdd and allowRemove settings to element select inputs (which relation fields use internally) for Craft 5.4: 0bf41d9

With that, you could register a custom field type that extends craft\fields\Entries, and sets those two settings to false, while also populating the selected entries with any missing entries, to ensure all possible entries are always selected when viewing the field.

namespace modules\foo\fields;

use craft\base\ElementInterface;
use craft\elements\db\ElementQueryInterface;
use craft\elements\Entry;
use craft\fields\Entries;
use craft\helpers\Cp;

class StaticEntries extends Entries
{
    public static function displayName(): string
    {
        return 'Static Entries';
    }

    protected function inputTemplateVariables(array|ElementQueryInterface $value = null, ?ElementInterface $element = null): array
    {
        $variables = array_merge(parent::inputTemplateVariables($value, $element), [
            'allowAdd' => false,
            'allowRemove' => false,
        ]);

        // make sure all the expected entries are selected
        $ids = array_map(fn(Entry $entry) => $entry->getCanonicalId(), $variables['elements']);
        $missingEntries = Entry::find()
            ->section('services')
            ->id(['not', ...$ids])
            ->site(Cp::requestedSite())
            ->all();
        array_push($variables['elements'], ...$missingEntries);

        return $variables;
    }
}

use craft\events\RegisterComponentTypesEvent;
use craft\services\Fields;
use modules\foo\fields\StaticEntries;
use yii\base\Event;

Event::on(Fields::class, Fields::EVENT_REGISTER_FIELD_TYPES, function(RegisterComponentTypesEvent $event) {
    $event->types[] = StaticEntries::class;
});

You could either create a new field type like that for each individual use case, or put some work into making it a bit more customizable, e.g. based on the configured source settings.

[thupsi]

That's fantastic! Thanks!

[brandonkelly]

Craft 5.4.0 is out with those changes.