-
Notifications
You must be signed in to change notification settings - Fork 350
Description
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:
sulu/src/Sulu/Bundle/AdminBundle/Metadata/FormMetadata/StructureFormMetadataLoader.php
Lines 193 to 198 in f4ae26a
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)