Drupal console appears to be abandoned and not installable on Drupal 9.5 and later and should not be recommended.
@solideogloria Thank you for all of your work on this module. It is very much appreciated.
I have not been able to reproduce this on the 2.0.x branch.
trackleft2 → changed the visibility of the branch 3450454-logicexception-when-logging to hidden.
trackleft2 → changed the visibility of the branch 3450454-2.0.x to active.
trackleft2 → changed the visibility of the branch 3450454-2.0.x to hidden.
trackleft2 → made their first commit to this issue’s fork.
Merged in 2.0.x
Merged in 2.0.x
Merged in 2.0.x
trackleft2 → changed the visibility of the branch 8.x-1.x to hidden.
trackleft2 → changed the visibility of the branch 3450457-fix-coding-standards to hidden.
trackleft2 → changed the visibility of the branch 2.0.x to hidden.
trackleft2 → changed the visibility of the branch project-update-bot-only to hidden.
trackleft2 → made their first commit to this issue’s fork.
trackleft2 → changed the visibility of the branch 3502082-update-gitlab-ci-to to hidden.
trackleft2 → changed the visibility of the branch 3502092-phpunit-test-failing to hidden.
trackleft2 → created an issue. See original summary → .
trackleft2 → created an issue.
Merged, thanks
Does this change resolve this issue? https://www.drupal.org/node/2609548/revisions/view/12484055/12558241 →
The state api is no longer being used for this: 🐛 drush migratation with --sync has suboptimal performance (v6) Active
trackleft2 → created an issue.
trackleft2 → made their first commit to this issue’s fork.
Change menu link title to sentence case.
Thank you both for this report and merge request, I like the simplicity of the array_filter approach.
I've gone ahead and added some PHPUnit tests to hopefully prevent this issue from coming back once it is fixed.
trackleft2 → made their first commit to this issue’s fork.
We've been using this patch on 500 sites for over a year. Seems to work.
I've added a PHPUnit test
trackleft2 → created an issue.
The patch from #10 works for me, I've create a merge request with the patch so we can continue work on this.
Changing to Needs work, because the maintainer said this needs tests.
trackleft2 → changed the visibility of the branch 3295470-convert-image-style-cannot to hidden.
trackleft2 → made their first commit to this issue’s fork.
Will review the other MR, thanks for reviewing this one.
FYI, when I attempted to move the functionality of this merge request into the masquerade module for
✨
Update log messages to reflect that a user was masquerading
Needs review
I wasn't able to make it work. This is also why the MR on that issue is so different from this one.
This leads me to believe that I set my test site up incorrectly when I made this merge request (using an older version of masquerade module) I do want to test this again ensuring the latest version of masquerade and the latest version of core it runs on.
Yes, thank you, I was looking for "Blocked" but it seems "Postponed" is what I should have been looking for.
Target branch currently set to 9.4.x
Target branch in MR needs to be updated to 11.x
trackleft2 → made their first commit to this issue’s fork.
Well, yes, because this merge request depends on being able to install Drupal 11 in the first place, which is resolved in other merge requests and not this one. This merge request resolves an issue with the PHPUnit test given the module is working and installable (I have my own working copy of this module with all my fixes merged that I test with).
Since 🐛 Masquerade Log module incompatible with masquerade version 8.x-2.0-rc4 and earlier Active effectively means masquerade_log no-longer works, this issue can likely replace that entire module.
In MR !19 I add a new setting disabled by default named log_masquerading_user
.
To update this setting, to true, you can use drush config:set masquerade.settings log_masquerading_user true
trackleft2 → made their first commit to this issue’s fork.
Updated title and description to match existing documentation style better.
trackleft2 → created an issue.
Duplicate of 📌 Fix coding standards Active
trackleft2 → created an issue.
trackleft2 → created an issue.
trackleft2 → created an issue.
I've added a proof of concept as Merge Request !82 for your consideration.
The merge request:
- Incorporates the patch from #2 but uses widget settings instead of field settings.
- Has an update function to move values from field config to field widget config
- Adds widget settings for both the select element and the autocomplete widget.
I mostly agree with #15 and believe that I have addressed the interface issues. I think we should hash out whether this functionality should be a global setting or a widget setting over in 🐛 Preselect doesn't work with autocomplete field. Needs review . I've added a comment over there with my thoughts 🐛 Preselect doesn't work with autocomplete field. Needs review . Also, feel free to ignore any of my suggestions.
When I attempted with the default form display (autocomplete) it does not change anything. Looking further this actually seems like the Views Reference field type as a whole is ignored for Autocomplete, but I think we need to consider that as a follow-up (ie, "Preselect View Options" is already ignored there) as it can have wider implications for sites where the 'Preselect View Options' has already been ignored in autocomplete.
I found the UX a bit confusing, as the 'Limit by Views tag(s)' is not actually limiting. I tagged Recent Content and Recent Comments core blocks with 'recent' then created a third View with Block display 'Other view' without tagging it. I ticked 'Other view' in 'Preselect View Options' then went to create a node with a Views Reference field with Select widget and saw all 3 views. So rather than 'Limit' its more like 'In addition to "Preselect View Options", automatically allow any Views with the following tags' (wording not sure of).