The initial question in the issue title has been answered in Comment #4 ✨ searching assets based on file format Active , therefore I think we can close this one.
As discussed with @japerry → recently, all these changes goes onto the MR of 🌱 Roadmap to the next release of the `acquia_dam` module Active for the sake of simpler overview.
baluertl → changed the visibility of the branch stable-release-related-fixes to active.
baluertl → created an issue.
Also linking ✨ Dynamic filter for collections Active here as well for visibility.
It was probably a momentary lapse in judgment that led me to think, 'Not all Drupal users are Widen users too.' Of course, they must have a registered user account; otherwise, they wouldn’t be able to authenticate themselves on the Drupal side either. As a result, I’ve downgraded the significance of this potential disadvantage to being a minor UX flaw instead."
Adding a possible disadvantage.
baluertl → created an issue.
baluertl → changed the visibility of the branch stable-release-related-fixes to hidden.
While working other things I just stumbled upon the same on the latest 1.1.x-dev version as well:
Memo: whoever will work on this, please make sure that all other non-URL-friendly characters are also tested for, not only the forward slash. Thanks!
On Acquia's internal channels, we have received reports of very similar errors to happen. Based on the formatting of error messages I see on Watchdog screenshots, I can tell that the Customer was using a version of this module before the MR !84 was merged.
Although handling of HTTP 4xx errors from asset-related API requests has been improved in the 1.1.x branch, but it is uncertain whether it covers integration link-related requests too or not. Independently from HTTP 4xx errors, I do agree with @capysara → 's suspicion about if the CRUD operations of integration links are not in full sync with the DAM assets during their entire lifecycle. As the auto-hiding logic instantly sets media items unpublished at any time when the Widen API returns a response with negative meaning (aka. asset unavailable or deleted), these are not permanent changes on Widen's side (asset can be available later on and even can be restored from trashbin by admin). Therefore we don't delete media items automatically, so – up to my current understanding – we should not delete integration links either.
For the sake of transparency (and because we have referenced this ticket earlier from various sources) I restored its original issue description which was clearly about solving the link deletion problems. Also, bumping branch up to 1.1.x because it could be easier due to the aforementioned feature already implemented there.
At the moment I have no access to any Widen instance hosted on *.acquiadam.com sub-domain (only those that run from the old *.widencollective.com), therefore I would kindly ask anyone who has access to test our proposed bugfix on MR !97.
The expected behavior is: when browsing the media library modal window, all (except Audio & Generic –
another issue
📌
Generalize embed codes of audio and generic asset types
Active
) kind of DAM assets should properly display a thumbnail image. The same applies to the Views list on the /admin/content/dam-media page too. Right-click on any thumbnail image, checking its URI in most (all?) cases should point to a CDN-related hostname.
baluertl → made their first commit to this issue’s fork.
The solution provided here has been merged into both development branches, therefore I think we can close this ticket as Fixed.
Thanks @paladyn → for reporting this. I just got informed about this 'acquiadam.com' domain name recently from Widen's docs → . Although I cannot promise for sure, but I do agree that it would be extremely helpful if we could roll out the upcoming 1.1.0 stable release with properly prepared to handle this new domain name pattern too.
baluertl → changed the visibility of the branch 3478118-rc1-release-related-fixes to hidden.
- Port changes from MR !51 to branch
1.1.xas MR !95 - Remove the unnecessary Form title override, use the Page title from the routing itself instead
- Delete the unnecessary fieldset form element
- Replace instructions with a much more informative description about the purpose of this page
- Invoke the parent form logic to allow alteration by anyone else
- Use the action button inherited from the parent form controller
- Do not render the form if there is no metadata from the Widen API
Current implementation:
baluertl → changed the visibility of the branch 3444915-allow-enabling-all to hidden.
baluertl → changed the visibility of the branch 1.1.x to hidden.
In general terms, I like the idea, thanks for bringing it up and creating an MR. Some objectives from me:
- The naming of the new option should fit into the semantical pattern of already existing ones, which mostly (all?) describe what the editor will receive when choosing that option (eg. “inline_view”, “link_thumbnail_download”, and “link_thumbnail”). Oppositely, the suggested name “background_video” represents a possible purpose for how this option can be used.
After some testing, I found the proposed setup very similar to the already existing “video_stream” option. Therefore I suggest we could help the content editors understand better the difference between these two. - The autoplay feature activates within the WYSIWYG editor as well. I did not started to investigate any possibilities to its specific disablement, so we can handle it as a known issue until hearing back end-user complaints.
The current implementation:
We are still keeping this ticket open until the final goal (1.1.0 stable got released) is achieved.
Resolved in 1.1.x-dev branch:
Disclaimer: I am not a member of the Product Team that makes decisions about the direction of forthcoming development but I can hardly imagine such a data communication would be implemented in the near future. The entire ecosystem is built upon the concept that Widen is the central SSoT and one or more client websites connect it to fetch data from. Allowing backward would require a major overhaul of the entire current architecture. Sorry, this is a strong -1 from me.
baluertl → changed the visibility of the branch 1.0.x to hidden.
baluertl → changed the visibility of the branch 3443055-handle-unavailable-widen-assets-11x to hidden.
baluertl → created an issue.
After the merge request has been merged, I cannot see any major difference between how the dropdown list works for an embedded image (not counting the last option with ling name which was added in a separate MR):
@jura.khrapunov → / @ok4p1 → / @vadim.hirbu → could any of you please update the issue description with a proper list of steps for reproduction? Otherwise, it's hard to tell the issue status until it's unclear what the exact expectations were. Thanks in advance!
After the merge request has been merged, I cannot see any major difference between how the dropdown list works for an embedded image:
@jura.khrapunov → / @ok4p1 → / @vadim.hirbu → could any of you please update the issue description with a proper list of steps for reproduction? Otherwise, it's hard to tell the issue status until it's unclear what the exact expectations were. Thanks in advance!
Now tested: when upgrading from 1.0.14 stable to 1.1.x dev version, after running $ drush updb no any error messages appear on the /admin/content/media page.
The screenshot inserted into my comment on GitLab does not appear here on D․org, so pasting here its link: https://git.drupalcode.org/project/acquia_dam/-/merge_requests/90#note_4...
Added 🐛 Php warnings after update to 1.1.0-beta5 Active to the list.
Root cause found which is quite a lame coding mistake, actually: our 2 field definitions with different types (File / Image) both received the same field storage definition (source code):
Tomorrow morning I will open a merge request including the fix together with some minor improvements as well.
Crediting others for their contribution made on 📌 The cron job is repeatedly logging error messages. Active which proposal has been implemented on this ticket.
Step 4. of the reproduction process says:
“Delete the attached media from site as well as from DAM”
At this point, this issue relates to 📌 Handling media items when their asset gets unavailable in Widen Postponed , where I am working on covering such situations (aka. the asset has been gone in Widen, but Drupal still tries fetching its data.)
So during my testing, I found that not only removeIntegrationLink(), but 3 other methods of our AcquiaDamClient are also affected by some unhandled 4xx errors (this MR checks for “400”, but in my case, it's “404”). These methods are:
getAsset()getAssetVersions()registerIntegrationLink()
Basically, whenever the API request contains the UUID of a given asset (or an integration link), then we need to take care of handling those 4xx errors. Methods of non-specific, generic requests seem to be unaffected.
To avoid code duplication 4 times in total, I created an internal method responsible for logging the exception message. For those, who are interested, I can link my commit dee3b744 in its current state (no MR is opened yet to link to).
Leaving this ticket open until aforementioned 📌 Handling media items when their asset gets unavailable in Widen Postponed lands, then we can return back here to try out the scenario described again and if it seems to be solved, then extend the test coverage under a new MR of this ticket.
@bhagyalakshmi → Currently, no customization options have been implemented to achieve such results.
MRs of minor code improvements and bugfixes should target the 1.0.x branch.
MRs of bugfixes should target the 1.0.x branch.
MRs of bugfixes should target the 1.0.x branch.
MR's of new features should target the 1.1.x branch.
@capysara → thanks for sharing such a creative idea of putting together a solution.
Recently (just a couple of hours ago) I've gained some fundamental understanding: almost all search query strings you can put together on the Advanced Search page of Widen GUI should show more-or-less the same results in Drupal's media library modal window too (Click to open in bigger size):
Of course, if you need only one file format to filter to, then use the query like this:
ff:({TIFF}).
Currently, there is no option implemented yet for filtering assets by their file formats. As a workaround, you can always search for their filename extensions:
However, it might be worth noting that this does not guarantee 100% precision for the following reasons:
- DAM assets in Widen are not required to have a valid extension at the end of their file names. Therefore it can happen, that an asset will not fall into the scope of your search, although it is the same file format.
- When asset versioning is enabled on your Widen software, then new versions with various file formats are allowed to upload to the exact same asset item. Doing so an asset originally uploaded as a video file might have a PDF document as its second version, but still keep its initial file name together with the file extension (eg. “.mov”). When Drupal synchronizes such a mixed asset, your search results might falsely include this asset.
@attilatilman → Thanks for reporting the issue. Hopefully, we will be close enough to release the first RC version of 1.1.x branch within weeks. After that, our key focus will be ironing out all these and similar issues of the upgrade path from 1.0.x versions. Therefore leaving this issue in Active status until then.
@ananya.k → thanks for beeing active in the Drupal community. As a general thumb of rule: please do not set issue statuses into “Postponed (maintainer needs more info)” state on contrib modules where you are not maintainer. If you feel the issue description is not quite clear enough, then request clarification by simply writing a comment about that, but you don't need to set the issue status for this.
@attilatilman →
Thanks for reporting, I was also bothered by these empty set of radio buttons indeed. The merge request for the epic of refactoring thumbnail handling fixes this by setting the newly introduced remotely_referenced_thumbnail_image render mode the default. (The reasoning behind this is the only single embed mode that is universally applicable among all the media types.) Although does not make the radio button field required. Therefore leaving this issue in Active status until the epic gets merged and a new version is being released with a stability level of RC at least.
Thanks for reporting the issue. Your list of steps does not mention it, therefore I'd suggest you ensure the "Download and Sync" checkbox is marked on the config page of the given media type eg. /admin/structure/media/manage/acquia_dam_image_asset. This option is available only in 1.1.x versions but not on the 1.0.x branch.
Once on-site storing of the asset files is enabled, their local copies should exist in the file system so that they can be used for cropping as well.
Some bug reports in the most progressed status have been added to the list. Please keep in mind that this list is a preliminary plan considered purely from a technical perspective. Acquia's Product Management has the final say regarding the timing and functionality scoping that might change at any time.
As being a bugfix, it supposed to target the 1.0.x branch. Sorry for confusion earlier.