Changed the title, Please review.
Please change the target branch of the MR and resolve Merge Conflicts if any after changing the target branch.
Working on it.
Yes @lendude, I agree with you because in this issue also we are trying to achieve the same thing, to allow to set the exposed filter to required without having to select a default value.
So should we wait for that issue to be fixed or continue working on it?
@lavanyatalwar,
There were issues solving Merge conflicts in MR!72, so created a new branch,
please review MR!73.
divyansh.gupta ā changed the visibility of the branch 3511606-matomobasictesttestmatomopagevisibility-fails-in to hidden.
Sorry but will not be able to work on it.
Working on it.
Working on it.
Made the changes, Please review.
Since there is no response for such a long time closing this issue.
I attempted to reproduce the issue by creating multiple menus, and in all cases, the menu is functioning correctly across all levels. If there are any specific configurations or settings that might be contributing to the issue, please let me know so I can investigate further.
Working on it.
I've implemented a configuration option to enable or disable the distance field in the exposed filter.
Please review and Let me know if any changes are needed!
I tried replicating this issue on Drupal 10 with module version 2.x, following the steps in the issue summary, but couldnāt reproduce it. If anyone else is experiencing this, please share detailed steps to reproduce, including configuration settings, specific inputs causing the issue, and any error messages or logs. This will help in identifying whether itās environment-specific or a broader issue.
I reviewed this issue and the changes looks good to me as there are no errors after applying MR-8.
Thus moving to RTBC!!
I have reviewed the issue and the changes looks good to me because now the code allowds $response to be NULL.
Thus moving this to RTBC.
I reviewed this issue and was able to reproduce this issue and MR-13 solved the problem successfully for me,
Thus moving it to RTBC.
Before:
\
After:
I have reviewed the changes and since file_valid_extensions is deprecated these changes will solve the issue.
Thus moving this to RTBC!
Working on it.
Yes i agree with the solution that $key is set before entity load in Selective::getOids, since patches are deprecated created an MR.
Please review.
Working on it.
Made changes suggested in #14,
Please review.
Working on it.
I was able to reproduce this issue and solved the issue by adding an access check before adding links to help page.
Please review.
I was able to reproduce the issue successfully and after changing the route now the exception of invalid key is successfully printed on the node page without throwing any error in dblogs.
Please review.
Working on it.
Woking on it.
Raised MR against 11.x (MR !11535),
Please review.
divyansh.gupta ā changed the visibility of the branch 3513601-improve-password-field to hidden.
I have made the changes such that the order is:
- Current Password
- New Password
- Confirm New Password
by adjusting the weight property of new password field.
Please review.
Working on it.
Made changes as requested by @Niklan, and it is working fine after the changes,
Please review.
Working on it.
Hello,
I tried the steps you asked to reproduce in Drupal core version: 11.1.4, Navigation + version: 2.0.2, Admin theme: Claro 11.1.4 (administration theme), Front theme: Olivero 11.1.4 (default theme), but for me it is coming as expected.
I have added the file in config/install,
Please review.
Working on it.
@jsutta,
I am unable to see the sticky action buttons menu even after enabling the setting in theme's setting form, so can you help me how to make the menu visible.
Working on it.
Working on it.
Looks good to me also, since patches are deprecated providing with and MR.
Working on it.
I have made changes in the tests and the pipeline is also working green after the changes,
Please review.
Working on it.
Hello @shashank5563,
tried on the versions you mentioned but still I am unable to reproduce this issue,
Rebased and resolved a PHPStan error,
Please review.
Ok @shashank5563, working on it.
Rebasing it.
I tried to reproduce this issue but:
- The issue should be raised against 2.0.x because the route given in issue summary does not exist in 8.x-1.x
- I could not find any issue on /admin/config/development/performance/purge. So if you could provide steps to reproduce this issue and this patch does not make any changes.
Hello @aren33k,
I am unable to reproduce this issue can you please provide some detailed steps to reproduce this issue.
Working on it.
Working on it.
I have made changes to resolve the nullable error according to PHP:8.4,
Please review MR-15.
divyansh.gupta ā changed the visibility of the branch 3510945-php-8.4-implicitly to hidden.
Working on it
I tried to reproduce this issue but was unable to reproduce it after following the steps you mentioned, but if you are facing this issue I can add a type check before using implode() ensuring that only array is entered.
I tried to reproduce this issue but was unable to reproduce it after following the steps you mentioned, but if you are facing this issue I can add a type check before using implode() ensuring that only array is entered.
Working on it.
Hello @liam morland,
I tried rebasing it on branch 3.0.x but i dont have the access to change the target branch from 8.0.x to 3.0.x, so if anyone with access would change it so that i can rebase it towards 3.0.x.
Changed the state by mistake.
@meghasharma
Previous two days were weekends so I was not active over here. Also i was working on it today and did not see new messages in this issue lately, but now that you have solved this issue its fine.
Working on it.
I was able to reproduce this issue and the patch applied successfully and fixed the issue for me.
Please review.
Working on it.
Working on it.
I tried to reproduce this error but was unable to reproduce this, so if this issue still persists for anyone i would make a MR for it, else I think we can close this issue.
I have reviewed and tested the latest patch in !11.
ā
The #submit callback is no longer being unset, allowing other submit handlers (such as from Media Entity File Replace) to function correctly.
ā
The function name update issue has been resolved, and $form['actions']['submit']['#ajax']['callback'] now correctly references the updated function.
ā
The form submission process works as expected, and the modal closes properly after submission.
Everything looks good, and I don't see any regressions or issues. Moving this to RTBC.
Working on it.
Since there is a unresolved thread moving it to Needs Work, Please resolve the thread.
The change to allow string|int for the $hook argument in coi_module_implements_alter() is correct. This prevents a TypeError when Drupal incorrectly registers update hook numbers (e.g., 8001) as hook names, as described in issue #3508292. The fix ensures compatibility while keeping the existing logic intact.
Thus the changes looks good to me moving this to RTBC+!
I have reviewed the issue and the MR-13 successfully applied for me and now it is working as expected, also the changes looks good to me thus moving it to RTBC+!
Found that pipelines were failing because forked branch was some commits behind the main branch, so rebased my forked branch and ran the pipeline again and now all the pipelines are passing without errors/warnings.
Please review.
I reviewed this issue and the MR applied successfully for me, and the changes fixed the issue for me as seen in the attached video.
The changes looks good to me thus moving it to RTBC+!
I am also able to reproduce this error:
Also i found that translateContent function being used in Controller of auto_translate is being modified in this
issue
š
Discuss: Unify translate operations over ai
Active
, so i think we should modify the controller in auto_translate to comply with the changes made in ai_translate module.
I was able to reproduce this issue while using Add block button.
So i updated the function such that it is also backward compatible.
Please review.
Working on it.
I have reviewed MR-11 and found that now it provides proper options to format email body as seen in attached screenshot.
The changes looks good to me thus moving this to RTBC.
I have reproduced this issue and MR-15 successfully applied for me and fixed the problem.
And now it is printing Unrecognised username which i think is better than the username is not activated message.
The changes looks good to me thus moving it to RTBC+!.
Since the referenced issue is fixed and the changes looks good to me and working as expected, also the module is working fine after this fix.
thus moving it to RTBC
I reviewed the MR-18 and it is working fine for me as expected and mail is being sent with tokens accessibility.
The changes looks good to me thus moving it to RTBC+!
I have reproduced this issue and MR-5 successfully applied for me and fixed the issue for me.
Before:
No warning after this patch, the code looks good to me thus moving this to RTBC+!.
I used these Drupal 10.4, Php 8.3 as mentioned and applied MR-2 successfully and the changes looks good to me,
also it is not throwing any errors.
Thus moving it to RTBC+!.
I have reproduced this issue and the MR applied successfully for me and fixed the issue.
Before:
After:
Thus moving it to RTBC+!.
I have reproduced this issue and MR-14 applied successfully for me and fixed the issue for me.
Before:
After
The changes looks good to me thus moving it to RTBC+!
The fix addresses the issue where $workflow could be false, leading to an error when calling $workflow->findTransition(). By ensuring $workflow is an instance of WorkflowInterface before using it, the code now handles cases where the workflow is invalid. This solution should resolve the issue.Thus Moving this to RTBC.
Hello @manish-31,
I reproduced this issue and MR-47 applied successfully for me and fixed this issue.
Before:
After:
The changes looks good to me thus moving it to RTBC+!.
I have reproduced this issue and MR applies successfully for me and solved the errors.
Before:
After:
The changes looks good to me thus moving it to RTBC+!
I reproduced this issue and this MR fixes this issue
After:
The changes looks good to me thus moving it to RTBC+!.
Hello @adpo,
Sorry for the delayed response. I have tried multiple approaches to resolve this issue, but it seems that the condition to check for the path is only being evaluated once and not returning as expected, allowing further checks to continue. I also attempted different implementations using JavaScript, but none were successful.
Thus unassigning it from myself.
Working on it.
Working on it.
I attempted to reproduce the error but couldn't locate the file where the patch is supposed to be applied. However, I discovered that the mentioned file exists within the Google analytics reports ā module. Specifically, it is found in this file.
Given this, I recommend raising this issue under the Google Analytics Reports module instead.
Let me know if this works or needs further adjustments!