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 → .
rajeshreeputra → credited chandu7929 → .
rajeshreeputra → credited chandu7929 → .
rajeshreeputra → credited chandu7929 → .
rajeshreeputra → credited chandu7929 → .
rajeshreeputra → credited chandu7929 → .
chandu7929 → created an issue.
Changes looks good to me, hence RTBC.
I have verified the attached patch which fixes the issue. Needs review.
"patches": {
"drupal/acquia_search": {
"Acquia Search can lock threads excessively leading to denial of service on cache clear": "https://www.drupal.org/files/issues/2024-09-10/acquia_serach-3466306.patch"
}
}
chandu7929 → made their first commit to this issue’s fork.
Added test and CI is green, hence requesting review.
Requested changes are done, hence NR.
Hello Yuvania → lets make changes related to D11 compatibility fixes only. We should create separate issue for phpcs, eslint etc.
CI is green now, hence requesting review.
Due to dependency conflict between core-recommended 9.5 and league/uri-interfaces 7.0.0 composer is not able to download any 7.x version of league/uri-interfaces. In beta version the class League\Uri\UriString doesn't exists which causes test failure, hence dropping support for D9.
Only previous major is failing with following errorException: Error: Class "League\Uri\UriString" not found and I think its due to the version of league/oauth2-server (8.5.4)that requires league/uri: ^6.7 || ^7.0
Its working as expected hence closing this issue.
Created MR!67 with required changes, hence moving ahead and requesting review.
With my further analysis, it looks like the generated auth_token is invalid, because using postman I am able to make request successful. I will try to investigate further if I can narrow down issue.
chandu7929 → created an issue.
We also need to include this change for D9 from js/moderation_sidebar.js
// information is already available.
$('.toolbar-icon-moderation-sidebar').on('click', function (e, data) {
if ($('.moderation-sidebar-container').length && (!data || !data.reload)) {
$('#drupal-off-canvas-wrapper, #drupal-off-canvas').dialog('close');
e.stopImmediatePropagation();
e.preventDefault();
}
Hello @ japerry → , Can you please confirm if we have to keep support for D9 with respect to the comment 📌 Automated Drupal 11 compatibility fixes Needs review otherwise we are good.
What is preventing these changes from being released?.
Today I updated my blog site with Drupal 10.3 which uses like_and_dislike → module that depends on this votingapi module, and when I visited one of my page, I can see WSOD
I had to use this MR's changes to patch the module, which fixes the issue.
"patches": {
"drupal/votingapi": {
"3341513 - Voting Storages does not check access on entity query": "https://git.drupalcode.org/project/votingapi/-/merge_requests/5.diff"
}
}
PR !36 changes looks good to me, though D11 ci is failing hence its can't be consider for review. Hence needs work.
Considering there's no issue in this MR, hence moving back to RTBC
chandu7929 → made their first commit to this issue’s fork.