This is mainly for consistency with the other vocabs, in
case there are future modules that want to vocab without
the asset type (like we needed with Material Type). By
putting all vocabs in modules/taxonomy we make it easy to
quickly see all the vocabularies that farmOS provides in
both the file system and module list.
The one remaining exception is Crop Family, which is
included in the farm_plant_type module.
See https://www.drupal.org/project/farm/issues/3191115
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
Michael Stenta
paul121
paul121
Symbioquine