This ensures that references to quantities created with the
create_quantity process plugin are maintained, so those
quantities can be deleted normally when the log is deleted.
This is necessary because Drush runs migrations as anonymous
user, which does not have access to 'use text format default'
permission, so any terms that need that format fail validation.
Derivatives can either define a bundle_parameter to look for
(eg: 'arg_0' in the case of Views), OR explicitly define the
bundle.
This will allow FarmAddLogPrepopulate to be merged into the
Menu/LocalAction/AddEntity class, and FarmAssetAddLogAction
to be merged into the Derivative\FarmActions class.
This error occurs if ?asset=X is used instead of ?asset[]=X.
We can take a more defensive approach by automatically
wrapping the input in an array if it isn't already one.
**Why?** Allow JS in contrib modules to take advantage of
now decoupled map instantiation code to create canonically
extensible/styled maps where the life-cycle of those maps
is controlled by the contrib module JS code.
For example, a contrib module's controller can return;
```php
return [
'map-prototype' => [
'#type' => 'farm_map',
'#attributes' => [
'id' => 'example-tool-map-prototype',
'data-map-instantiator' => 'example-tool',
],
],
];
```
Then create map instances from custom JS like this;
```js
const mapPrototypeElement = document.getElementById('example-tool-map-prototype');
const mapElement = mapPrototypeElement.cloneNode();
mapElement.removeAttribute('id');
myParentContainer.appendChild(mapElement);
const mapInstance = Drupal.behaviors.farm_map.createMapInstance(mapElement, mapElement, 'example-tool-map-prototype', {});
```
**Why?** There were a bunch of places where farmOS implicitly depends
on the id of the map element to look up settings and access the map
element after the map is instantiated.
This change makes it so there is only one place in the JS that depends
on the map id to dereference the drupalSettings and assign them under
`instance.farmMapSettings` so behaviors can access them.
**Why?** It should be possible to leverage the farm_map
module's extension mechanism and default styling without
necessarily giving it full control over when the map
instance gets created.
Currently, the FarmMap render element uses the 'farm-map'
CSS class to inform the JS code in `farm_map.js` that it should
instantiate the map. This is problematic since that CSS class
is also used for styling and there's a bunch of code in the
FarmMap render element and in `farm_map.js` which should
be common to pretty much all farmOS maps.
To fix that, this change introduces a new [data attribute] which
is used instead of the CSS class to signal the JS code in `farm_map.js`
that it should actually instantiate the map.
[data attribute]: https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes
