Support more asset_search_key values for Asset plugin

Created on 28 May 2025, 2 months ago

Problem/Motivation

In ✨ Allow for extending supported asset types Active new Asset plugins were added to allow a more extensible and customizable integration with the DAM.

The two important plugin propeties are:

  /**
   * The search key passed to DAM.
   *
   * @var string
   */
  public $asset_search_key;

  /**
   * The search value passed to DAM.
   *
   * @var string
   */
  public $asset_search_value;

This looks promising, but at the moment there really are only two values of asset_search_key that are supported. They are ft and ff. The acquia_dam_asset_type Views argument and the acquia_dam_asset_import queue appear to support any asset search key that is valid with Widen search. However, the MediaTypeResolver has ff and ft hardcoded in a mapping that can't be altered in any way.

$mapping = [
      'ft' => 'format_type',
      'ff' => 'format',
 ];

So that's where the trouble comes in.

Steps to reproduce

Use an alter hook to add a new plugin definition that uses some other search key. In this case, we use a metadata property with the key assetType.

/**
* Implements hook_acquia_dam_media_source_info_alter().
*/
function my_module_acquia_dam_media_source_alter(&$definitions) {
if (isset($definitions['image'])) {
$definitions['icon'] = $definitions['image'];
$definitions['icon']['id'] = 'icon';
$definitions['icon']['label'] = 'Icon';
$definitions['icon']['asset_search_key'] = 'assetType';
$definitions['icon']['asset_search_value'] = 'Icon';
}
}

Thus the icon Asset plugin is just like the image plugin but it searches using the assetType metadata instead of the format_type file property.

Proposed resolution

I would like the MediaTypeResolver to try its best to use search keys that are not in the hard coded mapping. The resolver would look for the key in both the asset's file_properties and its metadata.

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Active

Version

1.1

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States danflanagan8 St. Louis, US

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @danflanagan8
  • πŸ‡ΊπŸ‡ΈUnited States danflanagan8 St. Louis, US
  • πŸ‡ΊπŸ‡ΈUnited States danflanagan8 St. Louis, US

    I put in an MR. Setting to NR.

  • Pipeline finished with Failed
    2 months ago
    Total: 2278s
    #508773
  • First commit to issue fork.
  • Pipeline finished with Success
    about 2 months ago
    #522406
  • πŸ‡ΊπŸ‡ΈUnited States patrickfweston Columbus, Ohio

    This is going to be really necessary for a client I'm working with. They have asset types that support both Word/Excel documents and PDFs. I'm having trouble at the moment given they have different AssetMediaSource instances, using both the Documents and Pdf types.

  • Pipeline finished with Success
    15 days ago
    Total: 2609s
    #552170
  • πŸ‡ΊπŸ‡ΈUnited States japerry KVUO

    I think this is on the right path, would like some tests though. Probably should look at how we're hard coding the mappings as well, so you don't need to use a hook_alter.

  • Pipeline finished with Success
    13 days ago
    #553874
  • πŸ‡ΊπŸ‡ΈUnited States danflanagan8 St. Louis, US

    Hi, @japerry

    Probably should look at how we're hard coding the mappings as well, so you don't need to use a hook_alter.

    The hook_alter is required in my case because all the asset plugin classes are final, not so much because the mappings are hardcoded. If the image plugin weren't final I probably would have extended it to create my new icon plugin, but I think the hook is fine here.

    I think this is on the right path

    Yeah, I think for supporting a single asset_search_key and a single asset_search_value, the MR is pretty effective. One problem that still comes up for my image/icon example is that any asset that Drupal resolves as an icon must all resolve as an image. So it's vital that the MediaTypeResolver tries to resolve icons before it tries to resolve images. I'm pretty sure the resolver iterates through the media types in alphabetical order (by media type machine name). Luckily for us, our icon media (which uses our icon asset type) comes before our image media (using the image asset type). That's pretty darn lucky though!

    TL;DR; It would be nice to be able to set the weight of a media type as returned by MediaTypeResolver:: getMediaTypes.

  • Pipeline finished with Failed
    13 days ago
    #554055
  • Pipeline finished with Failed
    13 days ago
    #554054
  • Pipeline finished with Running
    13 days ago
    #554101
  • πŸ‡ΊπŸ‡ΈUnited States danflanagan8 St. Louis, US

    Tests added.

Production build 0.71.5 2024