chandu7929 → created an issue.
chandu7929 → created an issue.
chandu7929 → created an issue.
Fixed all failing tests, hence requesting review.
chandu7929 → changed the visibility of the branch 3460115-contribpath to active.
chandu7929 → changed the visibility of the branch 3460115-composerrewrite to hidden.
Hence RTBC.
Reviwed and verify MR 165 and it looks good to me.
@capysara
I'm not actually sure what I expect to happen if it's linked but doesn't download. How should the 2 format options be different
The only difference with download option is that you will get option in you document viewer to download it.
Without download
chandu7929 → made their first commit to this issue’s fork.
chandu7929 → made their first commit to this issue’s fork.
chandu7929 → changed the visibility of the branch 3519247-acquia-dam-all-media to hidden.
chandu7929 → made their first commit to this issue’s fork.
I have fixed the issue, hence moving in review.
chandu7929 → made their first commit to this issue’s fork.
chandu7929 → made their first commit to this issue’s fork.
There's separate issue for comment #3 →
Passing a blank string serves as a workaround to bypass the error. Ideally, we should update the method signature to accept null as an optional parameter. However, it's unclear what the implications of passing null might be, although all tests are currently passing with this change.
Hello @Japerry,
The optional parameter should be set to null rather than an empty string—unless there's a specific reason to use an empty string in the method. Using an empty string can cause an error when the function is called without the second parameter, as it expects a value of type string. This results in the following error:
"Argument #2 ($version_id) must be of type string",
which is inaccurate in this context.
Please refer to the error trace from the getAsset() call in media_acquiadam where version_id is not passed.
[error] Client error: `GET https://api.widencollective.com/v2/assets/0c772875-c010-47af-bf7e-2a2080587d50/versions?expand=asset_properties,embeds,file_properties,metadata,metadata_info,metadata_vocabulary,security,thumbnails` resulted in a `404 Not Found` response:
> {
> "error": true,
> "response_code": 404,
> "error_message": "Asset with UUID 0c772875-c010-47af-bf7e-2a2080587d50 not (truncated...)
> [error] TypeError: Drupal\acquia_dam\Client\AcquiaDamClient::getAsset(): Argument #2 ($version_id) must be of type string, null given, called in /var/www/html/web/modules/contrib/acquia_dam/src/Plugin/media/Source/Asset.php on line 234 in Drupal\acquia_dam\Client\AcquiaDamClient->getAsset() (line 170 of /var/www/html/web/modules/contrib/acquia_dam/src/Client/AcquiaDamClient.php) #0 /var/www/html/web/modules/contrib/acquia_dam/src/Plugin/media/Source/Asset.php(234): Drupal\acquia_dam\Client\AcquiaDamClient->getAsset()
Overall, the changes in MR!47 look good to me. I validated the behavior using both private://myfile.key and public://myfile.key paths, and was able to retrieve the key value when using this patch. However, without the patch, the value returns null. Therefore, marking this as RTBC.
chandu7929 → created an issue.
chandu7929 → created an issue.
Updated variable name as requested, hence moving in NR.
chandu7929 → made their first commit to this issue’s fork.
Incorporated requested changes, hence requesting review.
@japerry - Thank you for highlighting first point; we will take it into consideration for inclusion. However, regarding your second point,
Also, the media type labels are greyed out. The ones that come with Acquia DAM should be editable alongside the old Media: Acquia DAM types so you can get a full picture of the all the media types and their names.
What is the reasoning behind permitting updates to the media labels of the new media type provided by the Acquia DAM module, despite the apparent logic in offering label modification options for the older media types?
Since all requested changes are done, hence requesting review.
Updated MR with required changes, hence requesting review.
chandu7929 → made their first commit to this issue’s fork.
chandu7929 → made their first commit to this issue’s fork.
chandu7929 → changed the visibility of the branch 1.0.x to hidden.
chandu7929 → created an issue.
chandu7929 → made their first commit to this issue’s fork.
chandu7929 → changed the visibility of the branch 3501895-bulk-import to hidden.
chandu7929 → made their first commit to this issue’s fork.
Thanks for the feedback, @vishal! I've refactored the code and improved the logic based on your suggestions.
The requested changes have been incorporated. Hence NR
Updated MR with required changes hence requesting review.
chandu7929 → changed the visibility of the branch 3500484-media-view-display to hidden.
chandu7929 → changed the visibility of the branch 3500484-media-view-display to active.
Pulling back in NW since its not working as expected.
Verified this chagnes with Migration issue 🐛 Media view display handling not honored during migration Active , this completly make sence to update external_id in this queue working this is the most appropriate place, rather creating new process and make a whole seprate API call again to get assest and update it.
RTBC.
Verified the migration with latest changes, and I can confirm that its working as expected. Also I like the idead of using existing queue worker to update asset with external_id becuase we already making api call to get asset details.
Hence RTBC
"Warning: Attempt to read property "asset_id" on null in acquia_dam_media_delete() (line 696 of /var/www/html/upstreams/acquia_dam/acquia_dam.module).
acquia_dam_media_delete(Object)"
Not able to replicate this issue.
chandu7929 → made their first commit to this issue’s fork.
Created MR with required changes, hence requesting review.
chandu7929 → created an issue.
rajeshreeputra → credited chandu7929 → .
We are not going to take these block in recipe:
- block.block.views_block__article_cards_recent_articles_block.yml
- block.block.views_block__event_cards_past_events_block.yml
- block.block.views_block__event_cards_upcoming_events_block.yml
Hence closing MR!44
Requesting review for MR 47 →
chandu7929 → made their first commit to this issue’s fork.
chandu7929 → made their first commit to this issue’s fork.
ankitv18 → credited chandu7929 → .
chandu7929 → made their first commit to this issue’s fork.
rajeshreeputra → credited chandu7929 → .
ankitv18 → credited chandu7929 → .
ankitv18 → credited chandu7929 → .
chandu7929 → made their first commit to this issue’s fork.
rajeshreeputra → credited chandu7929 → .
rajeshreeputra → credited chandu7929 → .
rajeshreeputra → credited chandu7929 → .
chandu7929 → made their first commit to this issue’s fork.
ankitv18 → credited chandu7929 → .
ankitv18 → credited chandu7929 → .
rajeshreeputra → credited chandu7929 → .
rajeshreeputra → credited chandu7929 → .
rajeshreeputra → credited chandu7929 → .
deepakkm → credited chandu7929 → .
baluertl → credited chandu7929 → .
chandu7929 → made their first commit to this issue’s fork.
damienmckenna → credited chandu7929 → .
I have fixed most of the failing tests only 2 similar test are failing.
- Drupal\Tests\quickedit\FunctionalJavascript\LayoutBuilderIntegrationTest::testArticleNode - This caused by empty body field value
- Drupal\Tests\quickedit\FunctionalJavascript\CKEditor5IntegrationTest::testArticleNode - Not sure why saving state isn't available for body field
rajeshreeputra → credited chandu7929 → .
The remaining tests are failing because the library quickedit.inPlaceEditor.formattedText is not attached during testing. I will investigate further to determine the root cause.
chandu7929 → made their first commit to this issue’s fork.
@damienmckenna → Thank you for your insights. I’ll mark this issue as closed (won't fix).
Need to fix the failing test.
chandu7929 → created an issue.
Add all commits from 📌 GitLab CI testing Needs review to make sure all test are passing for this issue as well.
chandu7929 → changed the visibility of the branch 3381934-hide-embed-code to hidden.
chandu7929 → changed the visibility of the branch 3381934-align-acquia-dam to hidden.
chandu7929 → made their first commit to this issue’s fork.
@capysara - The fix was designed to log warnings for assets that have already been deleted from the DAM, particularly when the queue process attempts to delete assets that no longer exist.
I found that it just generated new batches of warnings/errors on every cron afterwards. It was never the same messages in the logs. That make me think that this isn't the complete solution.
Could you please confirm if you're seeing multiple warnings for the same assets that were processed in the previous cron run, particularly for the integration delete?
About the new batches of warnings and errors: These fixes enable the queue to process items without terminating the process. Therefore, whenever the queue is processed, any issues with the asset references will generate warnings and errors in the logs once.
Verified recent changes and it looks good to me. I would request another sets of eyes.
@Rajeshreeputra - Requested some changes, please take a look.
rajeshreeputra → credited chandu7929 → .
rajeshreeputra → credited chandu7929 → .