🇺🇸United States @ndewhurst

Hi azinck, I definitely agree with the direction here. Labels in particular can be time consuming currently.
I'm working on performance improvements for the 6.x branch, which has a number of other changes, but I'm open to approving this for the 5.x to help users more immediately & broadly. Can you update the MR to make the cache lifespan configurable?

Hi Wesley - yes, the guest key was effectively required but not required on the config form. I just pushed an update making all three keys required and also restructuring the rest of the config form code to avoid that type of error if the BF API object is bad for whatever reason.
Also, I believe these issues have already been addressed on the 6.x branch, along with a move to delegated key management, so consider testing that and upgrading once we issue a supported release from it.

Hi Wesley, thanks for filing. That full-screen takeover was a crude, quick-fix workaround meant to avoid the issue whereby you scroll down through a list of assets, then select one, and then see only whitespace until you scroll back up. See this issue ✨ Entity Browser Selection Active . I just updated the 5.0.x branch with what should be a better fix for that issue.
I can also confirm that we will be releasing an update on the 6.x branch in the next month that includes a new approach to the asset browser and will help address various UX issues.

Thanks azinck. I'm happy to go with that approach. I've just committed your scroll changes and some of the CSS tweaks to the 5.0.x branch so anyone running 5.0 can benefit.
Thankfully, we will be introducing a new framework for the asset browser in the next month which will address some of the UX issues. That will be on the 6.x branch, which has other notable updates as well.

ndewhurst → created an issue.

I successfully set up an enhancer just now by referencing the other ones in code and reading this issue. I just wanted to second the observation in #4 that doTransform and doUndoTransform seem to be named the opposite of what they do. doUndoTransform is where you will want to modify the data for API output. I didn't dig around too much to figure out why, but I guess it has to do with the more general intent of Shaper\DataAdaptor\DataAdaptorTransformerTrait from e0ipso/shaper, where doTransform is meant to transform "incoming" data, and doUndoTransform is meant to perform the inverse transformation on "outgoing" data. Our use cases in this issue are all for outgoing data. At least that's my interpretation.

Thanks azinck. This is a natural feature request. The patch is a good start, and hopefully it's enabling you to achieve what you need with the config-based approach. I'd be fine rolling that code into dev. Do you want to go ahead and create a merge request?
Yes, there's no real need to differentiate "key-based criteria," and we can convert that to a more generic string mapping. This change will allow filetypes to be disallowed, which is fine.
Yes, we could eliminate a few lines of code duplication in label handling when it comes to formatting strings and bundling into query components. I might move that into getLabels.

Hi sassafrass. Is there a little "back" arrow (←) in the upper left that you can click? If so, does the select button become visible after doing so?

ndewhurst → created an issue.

Absolutely! Go ahead and store one high-resolution, uncropped image in Brandfolder. In Drupal, you can create three image styles, each with their own cropping/scaling. Your mobile image style could have a totally different aspect ratio than the others. You can use the Focal Point or Manual Crop modules to control the crop area. You can then use those image styles when rendering the image field on Brandfolder Image media entities. You can create responsive image styles via the core responsive image module (i.e. /admin/config/media/responsive-image-style) or achieve the same type of thing in other ways.
The images delivered via the Brandfolder CDN whenever each image style is used will be transformed via the URL params you mentioned.

Upon testing/review, we decided the safest/most feasible option was (2). BF Image media entities now have this option on the media edit form:

This is available and working with Drupal 10 in 5.0.x-dev.

Hi azinck, thanks for the suggestion. That module addresses the same type of issue but wouldn't help in our case. The symptom we're dealing with here manifests after Brandfolder has already processed a user-uploaded image file on their end, and the metadata that comes through from their API is inconsistent. The perceived orientation of the Brandfolder-hosted image is correct, but the width and height values provided by the API are interposed sometimes. I looked at the EXIF data exif_orientation reads, but didn't find a similar pattern with what comes over the wire from Brandfolder or exists within the image files themselves. In any case, while I could add support for the native PHP exif read on Brandfolder "files," supporting the image rotate() op as it's used by exif_orientation would be a bit outside the current scope/paradigm in terms of how BF images are transformed upon delivery / per image style.

Hi sassafrass, I just pushed up a quick CSS-only tweak to try to improve the scroll issue for the time being. No changes to selection logic or messaging around selection limits. Let me know if this change results in any side effects.

Thanks for documenting. The module provides a Brandfolder file scheme so that Drupal can handle Brandfolder entities as files in some contexts, but it should only be a one-way, read-only relationship at present. We do plan to provide a mechanism for uploading files within Drupal such that they are added to Brandfolder, but that is not yet available. I'll see what we can do in terms of avoiding unintended confusion in the meantime.

Thanks for documenting. The Brandfolder Browser plugin for the Entity Browser module is a newer addition, and needs to be expanded to support more of the Entity Browser configuration options and use cases.

Yes, that is a poor UX. We are working on a new browser framework and will be able to improve things like this in the new version.

Hi sassafrass - good question. The short answer is that we do not currently recommend creating new media entities directly. Instead, create a Brandfolder media type, and then hook it up to a context where the Media Library or Entity Browser is used for selecting media items. That will give you a Brandfolder image browser interface and then automatically create media entities as needed.

More info:
There is a one-to-one relationship between each Brandfolder-sourced media entity and a Brandfolder Attachment (Attachments can be thought of like individual files attached to Assets). That field (field_brandfolder_attachment_id) is the source field for the media type, and stores the ID of the Brandfolder attachment associated with the Drupal entity. (There should only ever be one Drupal media entity of a given type with a given attachment ID). The field is not really intended to be user-facing at all, but Drupal will show it on the standard "add media" form, as you can see. On a related note, the "Brandfolder Image" field is meant to be read-only and not used for uploading images in Drupal. If you copy and paste a unique attachment ID from Brandfolder into that field and save the form (leaving the Brandfolder Image field empty), it will work, but it lacks safeguards. The better approach right now is to enable your Brandfolder Image-based media type in a context where Media Library or Entity Browser is used to select media entities. The Brandfolder browser in those contexts will let you search for any allowed Brandfolder asset and select an attachment. It will create new media entities as needed.

Relevant action items:

1. Update documentation to discourage use of the Content > Media > Add Media workflow
2. Add documentation for Entity Browser support
3. Prevent new BF media entities from being created with duplicate attachment IDs
4. Prevent the use of the Brandfolder Image field for uploading images
5. Improve the Brandfolder browser interface
6. Integrate the Brandfolder browser with the Add Media form and start supporting that as a valid workflow
7. Provide a mechanism for uploading new files within Drupal and creating Brandfolder assets/attachments according to various rules

Drupal 10 support is provided as of the 5.0.0 release! Please feel free to communicate about specific issues using other existing issue threads or by filing new issues. Thanks to all who contributed.

Now available in 5.x-dev

This feature is now available in the 4.x and 5.x versions!

Label hierarchy is supported and handled as follows:

• If an allowed label has other labels nested beneath it, then assets associated with any of the descendant labels will also be allowed (if not disallowed).
• If a disallowed label has other labels nested beneath it, then assets associated with any of the descendant labels will also be disallowed.
• If you wish to allow a label but not [all of] its descendants, you can select the applicable descendants in the Disallowed > Labels field.

These features are now available in the 4.x and 5.x versions!
The preview/sample images shown on the module config page have also been updated so they take these config options into account and so you can specify their size, which allows you to easily experiment with settings like image quality.

This is included in the 4.x and 5.x versions!

This feature is now available in the 4.x and 5.x versions!

Great to hear!
For our info, are there other image types not currently supported that you would hope to use as part of the integration?
Also, you can test on Drupal 10 now using the 5.0.x-dev branch/release. I'd be curious to get your feedback there.

cbrand02 yes, sorry for the delay. I was able to get a small bit of funding which enables me to prioritize this. I've put together a compatibility grid for the various Drupal/PHP/SDK versions, creating multiple releases for this module and the PHP SDK in order to stabilize things. Liberally bumping major version numbers (but mostly necessarily so, to signal breaking changes between the various projects). We'll put out a D10-only version of this module in order to make subsequent feature development simpler. That'll be 5.x. I'll try to pull in everyone's updates from this issue. Talk soon!

Hi imran1217, thanks for using the issue queue. In keeping with what rwsimmo said, this bug was fixed in dev, and has now been incorporated into stable releases starting with 2.0.0.
Have a look at the currently available releases, and note that we are also preparing a D10 release.

Hi rwsimmo - thanks for filing the issue. Sorry about the confusion. The Brandfolder browser will only appear when you configure a media entity reference field to use a core Media Library widget (in the "Manage Form Display" settings form for the entity/bundle where you're using the field). The README apparently needs to be fixed.
I've also more recently added support for the Entity Browser module as an alternative to Media Library.
We're also stabilizing and reconciling a number of different module versions. What Drupal and PHP versions are you currently using (and/or planning to use)?

ndewhurst → created an issue.

@stijndmd yes, this is possible. Here's an example where a field within a paragraph IEF is displayed based on the value of a field from the parent form. Your specific form structure will vary, so have a look at the parents array and the name of the controlling field.

function mymodule_inline_entity_form_entity_form_alter(&$entity_form, &$form_state) {
  if ($entity_form['#entity_type'] === 'paragraph' && $entity_form['#bundle'] === 'my_paragraph_type') {
    if ($entity_form['#array_parents'][0] === 'field_my_parent_field' && is_numeric($entity_form['#array_parents'][2])) {
      $parent_field_delta = $entity_form['#array_parents'][2];
      $entity_form['my_conditional_field']['widget']['value']['#states'] = [
        'visible' => [
          ":input[name=\"field_my_parent_field[$parent_field_delta][subform][my_controlling_field][value]\"]" => ['checked' => TRUE]
        ],
      ];
    }
  }
}

ndewhurst → created an issue.

It seems that #40 applies to the latest release but causes an error with $items->getEntity() because $items does not exist in the lazyBuilder method.
Here is an updated patch that loads the entity based on the (newly?) provided parent_entity_* vars.

Note: I am not familiar with this module and I'm sure this is not the best solution. You probably don't need to pass the entity everywhere if the parent entity type and ID are available. I'm just trying to maintain compatibility in a project that has some dependencies declaring that they need this patch.

ndewhurst → created an issue.

Hi Wesley,

I haven't used those modules [with Brandfolder], but here are my initial thoughts:

Re: Easy Responsive Images

It looks like the main benefits of using that module over the core Responsive Image module are:

1. Auto-generation of image styles
2. Twig filter if you need/want to be working in Twig templates when it comes to image rendering
3. JS to choose images based on container rather than viewport width

At first glance it looks like this might work just fine with the Brandfolder module. You would create view modes for your Brandfolder-Image-Sourced media types as instructed, then, in the Twig template, just be sure to replace references to `field_media_image` with `bf_image` since that's the name of the image field on each BF media entity.

Re: Twig Tweak

If you can do this:

{# Render image using 'thumbnail' image style and "lazy" loading by attribute. #}
{{ drupal_image('public://ocean.jpg', 'thumbnail', {loading: 'lazy'}) }}

Then you should be able to do this:

{# Render image using 'thumbnail' image style and "lazy" loading by attribute. #}
{{ drupal_image('bf://ATEV5E6X/at/ccs81479tbnkr6gmfpbskwp/ocean.jpg', 'thumbnail', {loading: 'lazy'}) }}

(i.e. using the base URI for the Brandfolder file, and specifying any valid image style)

Let me know how you fare/fared.

-Nathanael

+++ b/core/modules/media/src/Entity/Media.php
@@ -433,7 +432,7 @@ public function prepareSave() {
-          if ($translation->hasField($entity_field_name) && ($translation->get($entity_field_name)->isEmpty() || $translation->hasSourceFieldChanged())) {
+          if ($translation->hasField($entity_field_name) && ($translation->get($entity_field_name)->isEmpty() && $translation->hasSourceFieldChanged())) {

@Ajeet Tiwari - this proposal is the same as in #2 🐛 Mapped media fields are overridden with metadata on translation save Needs review . I don't believe this is good, because mapped fields that are empty should be eligible for population regardless of whether the source field is changing.

ndewhurst → created an issue.

ndewhurst → created an issue.

Updating patch to work with new media entity creation, improve empty value handling, and revise comments.

ndewhurst → created an issue.

The patch in #62 prevents the specific problem outlined in the description, but it introduces a regression. Specifically, metadata will never be mapped to entity fields, even if those fields are empty, unless the source field changes. This does not appear to match the original intent here.
It might not be a noticeable issue for most people because most metadata won't change unless the media source changes - e.g. if you edit an Image-sourced media entity and replace the image file. However, it's perfectly valid for there to be all sorts of other metadata that might be updated somewhere without the media source changing - e.g. a transcript on an externally-hosted video, a caption for an image stored in an external DAM, etc.
I wonder if we could restate the problem by defining the expected behavior as:

Available metadata should always be used to populate mapped fields when media entities are saved/resaved and the target fields are empty. When changing a media source field, we should expect any mapped fields to be updated with metadata-derived values, unless we are simultaneously providing alternative values for some of those fields.

I know it doesn't avoid the "I previously customized the media name, and I was hoping my custom name would persist after replacing the source file" scenario...but it seems to balance the concerns in this thread with the original intent.
Here's a patch that tries to put the aforementioned behavior into practice. If someone is able to look at tests for it or otherwise weigh in, that would be cool.

cbrand02 P.S. feel free to contact me if you want to talk more about other functionality, use cases, or some of those custom work possibilities.

Great! Happy to hear it, and I expect you'll see a further drop with downscaling depending on what your presentation scenarios look like.

The webhook listener allows any module to subscribe to asset create/update/delete events. The Brandfolder module itself currently subscribes to asset update events in order to fetch relevant metadata that's mapped to media properties/fields, and populate data like alt text for image fields in Drupal if there's new data in Brandfolder for that.
We might add a built-in feature whereby you can configure proactive creation of Drupal media entities when BF assets are created, which would use the webhook listener.
You can subscribe to those webhook events in order to implement custom logic, e.g. find all Drupal nodes using a recently-deleted BF asset as their hero image and replace the image with a topically relevant alternative image, notify certain Drupal users, etc.

Hi Chase,

Probably the simplest improvement would be to:

1. Create an image style to constrain images - e.g. scale them down to the max possible output width
2. Update your code to get a URL for the corresponding style derivative (see below)

// ...
if ($fid = brandfolder_map_attachment_to_file($bf_id)) {
  $file = File::load($fid);
  $image_uri = $file->getFileUri();
  $style = ImageStyle::load('my_constraining_style');
  $url = $style->buildUrl($image_uri);
}
// ...

Your image style of choice could also use something like a "Focal Point Scale and Crop" effect, in which case you could set a focal point on the image field when editing the BF media entity, and that would be respected when generating the BF CDN URL in the above code.

Depending on your theming/styling scenario, you could also set up a responsive image style and use the associated picture tag/markup in your component to further optimize per screen size.

You can also append these params to the BF URL: quality=80&auto=webp, which will (a) compress lossy images at 80 percent and (b) deliver a webp version of the image if a given request indicates that the browser supports that.

Hopefully some combination of the above will help improve things quite a bit!

Hi JohnzelMT and sharayurajput, thanks for wanting to help! Did you happen to test the module functionality after applying those changes?
The recommended changes are obviously minimal, but I won't be applying them verbatim at this time because I need to review the MimeType functionality with respect to various image URIs with and without extensions.

Hi cbrand02, are you currently using the module to integrate Brandfolder images with Drupal, or are you using another means of placing Brandfolder images (with Brandfolder CDN URLs) on your site?

This module does a lot of work to avoid downloading images to the Drupal site's local filesystem so that all images are served from the Brandfolder CDN (for various reasons including governance) *but* also provide fully functional Drupal managed file entries, image fields, image toolkit, etc. so that images associated with Brandfolder-based media entities can be displayed using Drupal image styles and can do most other things that local images can do (except get served via your CDN of choice).

I'm optimistic that you'd see performance improve quite a bit by displaying Brandfolder images processed by Drupal image styles (including responsive image styles) to enforce basic resolution constraints. There are also a couple additional settings that can improve BF CDN performance depending on image type, and I'm planning to tie those into the Drupal module.

Maybe we can connect more to talk about your specific use case and needs.

Cheers,

Nathanael

Here is a patch that introduces the proposed changes and also updates the API file accordingly.
The second patch should apply against the latest non-dev Entity Embed release (8.x-1.3).

ndewhurst → created an issue.

Hi, I maintain the Brandfolder → module, which provides a media source plugin for images that are ultimately stored in that external DAM. Drupal media entities using that source do have an image field and a media thumbnail (which are effectively identical, such that the thumbnail alt & title attributes can be updated and translated). However, the "source field" for those media entities is not an image field, so the latest version of this module is not working with those media types. This is the same situation as for oembed and other media sources.
Here is a patch that flips the logic a bit and says "try to use the media entity's source field if this is a standard image-sourced media item; otherwise, use the thumbnail."

ndewhurst → created an issue.

ndewhurst → created an issue.

ndewhurst → created an issue.

ndewhurst → created an issue.

ndewhurst → created an issue.

This was fixed in this update to the PHP SDK. Anyone experiencing this issue should find it resolved after running composer update.