Skip to content

Add Block IDs for later reference #7846

@alexander-schranz

Description

@alexander-schranz

Problem description

Inside content management we want reference block via a id.

Requirement is:

  • they need to be unique for the current page
  • we can use them as reference for anchor navigation
  • we can use them as reference for future planned shadow structure feature

Proposed solution

Maybe a short hash algorithm can be used if it not require general uniquness:

php -r 'echo hash("xxh32", time());'

outputs:

a561af03

A PHP endpoint can also be used to generate such ids:

We can discus it but for me using someones JS library for create hashes or uuids which we don't know well I would avoid. As such libraries are preferred target of supply chain attacks.

Technically id generator need be enabled via a new property like we do for block settings also:

<param name="block_id_generator" value="true" /> 

We can also go with value="xxh32" later if we want support uuid based generators which are longer and really unique over all.

For pages, articles, snippet that param is automatically set like we do for the settings param, reference:

if (!\array_key_exists('settings_form_key', $itemMetadata->getOptions())) {
$optionMetadata = new OptionMetadata();
$optionMetadata->setName('settings_form_key');
$optionMetadata->setValue('page_block_settings');
$itemMetadata->addOption($optionMetadata);
}

The submitted block should look like this:

[
     {
           "_id": "<generator_value>",
           "title": "Other field"
     },
     {
           "_id": "<generator_value>",
           "title": "Other field"
     },
]

We can NOT! set the id as key JSON Specification don't forces keeping of the order of object and databases return object keys different order as they where given to it. And blocks are kind of list / array and so the array need to stay and is a less bc break.

Even we should "migrate" and generate the key in the migration from 2.6 to 3.0: https://github.com/sulu/SuluPHPCRMigrationBundle the frontend should still generate a new id if no id is give.

Complications

  • The new _id need to be excluded from all copy and paste functionality

Open Questions

  • A. Is uniqueness on object level enough (shorter id could be used)?
  • B. Is a PHP side generation of the id a accept solution (avoid JS dependencies)

Metadata

Metadata

Assignees

Labels

FeatureNew functionality not yet included in Sulu

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions