Requesting review.
requesting review.
@japerry do we need to add the collection filter in the view? and update hook for existing customers/users?
The anchor mapping differs between Drupal and the DAM system. In Drupal, the key is used to map the attribute, while the value is presented in a dropdown(or other) field for better readability (e.g., "Top Left," "Top Right"). Conversely, the DAM expects the equivalent values in a different format (e.g., "nw," "ne," etc.). This is why we have the $anchor_mapping array in the DAM's EmbedCodeUrlBuilder class.
Hope this resolves your concern. Hence closing.
You can also try
/** @var \Drupal\acquia_dam\Plugin\media\Source\Asset $source */
$source = $media->getSource();
$embed_codes = $source->getMetadata($media, 'embeds');
$url = $embed_codes['original']['url'];
requesting review.
rajeshreeputra → created an issue.
rajeshreeputra → made their first commit to this issue’s fork.
Requesting an early review.
Note: These commands can be further improved.
rajeshreeputra → created an issue.
requesting review.
Requesting review.
rajeshreeputra → created an issue.
Looks good
Covered as part of 📌 Create service to interact with PKS. Active .
Patch for site studio install issue with Drupal 11.2 version.
rajeshreeputra → created an issue.
rajeshreeputra → made their first commit to this issue’s fork.
rajeshreeputra → created an issue.
rajeshreeputra → created an issue.
rajeshreeputra → created an issue.
@patrickfweston - can you try 1.1.x version with download and sync option enabled?
This issue was reported for 1.0.x(somewhere around 1.0.6 to 1.0.10). @roam2345 can your verify if this still occurs in the latest version (1.0.x or 1.1.x)? If the issue is resolved, we can close this.
Tested with 1.1.x - the integration link registration now completes successfully without throwing errors. When assets are deleted from Acquia DAM, the system now removes the corresponding queue entries instead of keeping it in queue and throwing the error.
rajeshreeputra → made their first commit to this issue’s fork.
Requesting review.
rajeshreeputra → made their first commit to this issue’s fork.
rajeshreeputra → made their first commit to this issue’s fork.
Requesting review.
The error occurs because the AssetFileEntityHelper
constructor requires a strict LoggerChannel type. Updated the type hint in AssetFileEntityHelper.php
to use the interface instead.
rajeshreeputra → made their first commit to this issue’s fork.
Try using getAsset($asset_id)
method.
$asset_data = \Drupal::service('acquia_dam.client.factory')->getSiteClient()->getAsset($asset_id);
if ($asset_data) {
$asset_url = $asset_data['embeds']['original'];
}
I've implemented the solution suggested by @baluertl in comment #3 ✨ Make expand parameters in getAsset configurable so users can select what information is requested Active . After reviewing the codebase, making the expand parameters configurable would provide minimal benefit since:
- The expand parameter is only used in
getAsset()
methods where the detailed data is actually needed. - Each API endpoint has its own dedicated method with optimized or no parameters.
- Making it configurable would add unnecessary complexity without significant value.
The changes in MR !181 include:
- Removed the @todo comment from the $expand property documentation, as keeping it hardcoded is the preferred approach.
- Removed unnecessary expand parameter from the getAssetVersions() method call, as version endpoints don't require the same expanded data as asset detail endpoints.
This keeps the expand parameters optimized for get asset data endpoint while cleaning up the outdated todo comments. The current implementation is already efficient and doesn't require user configuration.
rajeshreeputra → changed the visibility of the branch 3392969-asset-type-display to hidden.
Fixed.
Requesting review.
rajeshreeputra → made their first commit to this issue’s fork.
rajeshreeputra → made their first commit to this issue’s fork.
requesting review.
Requesting review.
rajeshreeputra → created an issue.
rajeshreeputra → made their first commit to this issue’s fork.
rajeshreeputra → made their first commit to this issue’s fork.
requesting review.
requesting review.
rajeshreeputra → made their first commit to this issue’s fork.
rajeshreeputra → made their first commit to this issue’s fork.
rajeshreeputra → made their first commit to this issue’s fork.
rajeshreeputra → changed the visibility of the branch 1.1.x to hidden.
rajeshreeputra → changed the visibility of the branch 3531765-handling-media-items to hidden.
Requesting review.
With information provided in #5, I have removed the latest commit. Requesting review.
Updated MR with todo information.
rajeshreeputra → made their first commit to this issue’s fork.
Added hook to alter media_library_mediaLibrary plugin and added media-library-widget-modal class.
This is an core issue as outlined in
🐛
[regression] Class is not added to MediaLibrary dialog
Active
and also has patch to fix the same.
patch -
https://www.drupal.org/files/issues/2024-12-17/3474018-regression-class-is.patch →
rajeshreeputra → made their first commit to this issue’s fork.
The default view mode in CKEditor is configured for Drupal local media but does not apply to Acquia DAM media. This distinction arises because Drupal media utilizes view displays, whereas Acquia DAM media relies on embed codes (similar to image styles used for image media types in Drupal).
I hope this clarifies the your concern.
Requesting review.
rajeshreeputra → created an issue.
Missed to remove queueAssets() method removal from processQueue(). Requesting review.
Requesting review.
The Acquia DAM asset rendering from local functions operates as expected. However, the challenge arises with the Site Studio templates. We will address this issue in Acquia DAM, particularly for the custom templates created by users.
rajeshreeputra → changed the visibility of the branch 1.1.x to hidden.
rajeshreeputra → changed the visibility of the branch 3476376-provide-local-file to hidden.
rajeshreeputra → made their first commit to this issue’s fork.
rajeshreeputra → created an issue.
Hello @ankitv18 - test coverage will be added once the discussion from #7 ✨ Support Drush Command for Bulk Import Feature Active gets resolved.
I would like to propose a discussion regarding the implementation of the commands acquiadam:queue-assets
and acquiadam:import-assets
. Specifically, we need to consider whether these should be implemented as two separate commands or combined into a single command that handles both queuing and processing of assets.
Additionally, I suggest we introduce an option to limit the asset import process. For instance, we could allow users to specify a limit on the number of assets imported from the queue. An example:
./vendor/bin/drush acquiadam:import-assets --batch-size=50 --item-limit=500
This command would process 10 batches to import a total of 500 assets and then stop, even if there are remaining items in the queue. I believe this feature would enhance the flexibility and usability of the asset import process, especially for users dealing with large datasets.
Looking forward to your thoughts on this!
Updated MR, requesting review.
rajeshreeputra → created an issue.
rajeshreeputra → created an issue.
Requesting review.
rajeshreeputra → changed the visibility of the branch 3415947-whats-the-difference to hidden.
rajeshreeputra → made their first commit to this issue’s fork.
Requesting review.
Updated MR with necessary changes, requesting review.
rajeshreeputra → made their first commit to this issue’s fork.
rajeshreeputra → made their first commit to this issue’s fork.
Requesting review.
rajeshreeputra → created an issue.
rajeshreeputra → created an issue.
rajeshreeputra → made their first commit to this issue’s fork.
rajeshreeputra → made their first commit to this issue’s fork.
rajeshreeputra → created an issue.
Hello @byrond,
You are correct — version_id
and external_id
are not required during the migration process. After migration, the cron in the
Acquia DAM →
module should handle updating version_id
and external_id
regularly and automatically.
Thank you for bringing this up!