No problem! Thank you for the MR 😇
@mfrosch Please don't name an issue fork branch the same as the base branch in the future :-P it's a nightmare to work with when you want to rebase set base branch on the issue fork.
bramdriesen → made their first commit to this issue’s fork.
Will tag a new release because of the broken update hook.
No activity over 2 days, un-assigning. Feel free to pick this up again.
I would advise against this. Just imagine you're using this to store the database credentials, and somebody manages to do a screw up on production wiping the entire file. Meaning if this was done through the UI, Drupal would crash and you have to scramble to find someone to fix the file on the server. You might also not want everyone to be able to get access to those secrets, having the possibility as a site admin to just enable this via a module, seems a bit as a risk to me.
I guess this can also happen there, but at least a sysadmin shouldn't make such a mistake :-).
Can be re-rolled now
Just needs a rebase, there is another issue open also adding an update hook so let's wait for that one.
Tested, could reproduce and this MR fixed the issue.
Found the issue. MR created.
Code is also not OK, this is part of the entity already, no need to define a new basefield. No upgrade path provided either.
Possible duplicate of 🐛 Error saving polls after translation added when used in conjunction with conflict module Postponed
We could look into implementing this with a recent core feature. Not that much logic needed for this.
If you applied the patch from issue 🐛 Entity mismatched after 1.6.0 to 2.0.0-alpha3 upgrade Active which was not rebased, you're overriding the update hook. poll_update_8007 should be the install of the field. poll_update_8008 should belong to the issue you are referencing.
Please check what is in your install file after applying the patches.
Isn't this more a Drupalorg Infra ticket? If I'm not mistaken that queue is responsible for the GitLab CI pipelines.
bramdriesen → created an issue.
Setting to Needs work for the update hook mentioned in #15.
I tested MR !103 from @ericgsmith and this seem to cover our use case as well. Since it's more flexible as the first approach, I would assume this is the better way to go.
Patch looks good, no longer shows the generic login error when the user is created in a blocked state.
Thanks everyone!
I believe there are some other ways as well like ignoring some files.
To add something meaningful to this issue (beside my tests above :-) ), I updated the technical details code snippet.
Added one remark.
This is now implemented for anonymous users. Not sure if this is needed for none anonymous users.
Works as expected now, thanks! Merged :-)
This is a PHP deprecation, should not need any steps to reproduce :-)
Just visit: /admin/config/people/openid-connect
This introduced a warning
Deprecated function: str_ends_with(): Passing null to parameter #1 ($haystack) of type string is deprecated in Drupal\openid_connect_windows_aad\Plugin\OpenIDConnectClient\WindowsAad->__construct() (line 82 of modules/contrib/openid_connect_windows_aad/src/Plugin/OpenIDConnectClient/WindowsAad.php).
Created a follow up: 🐛 Deprecated function: str_ends_with(): Passing null to parameter #1 ($haystack) of type string is deprecated in Drupal\openid_connect_windows_aad\Plugin\OpenIDConnectClient\WindowsAad->__construct() (line 82 of modules/contrib/openid_connect_windows_aad/sr Active
bramdriesen → created an issue.
Feel free to re-open if still relevant. But I would assume this is indeed fixed.
Hi,
The easiest way for you to achieve this I think is to create a custom entity/node with an entity reference field to "Poll". That way you can link multiple polls to your entity and render them. That way you still have control over each poll separately.
I don't really see/understand the need to have this feature in the Poll module itself.
This can be taken up again since 📌 Anonymous users - Multiple voting from one IP Needs review landed.
I would go for the checkbox approach as mentioned in #6
bramdriesen → created an issue. See original summary → .
Number 2 is included in the "regular" poll. The others would be nice features although I'm not sure what the concordset exactly is.
Closing this one as a duplicate of ✨ Multiple Poll Types Active
Needs a re-roll after the anonymous vote restrictions got added. Probably removes some duplicate code from that issue as well (remark 1 of #10)
I added some questions. I'm not sure if this fixes the issue for @fgm. So would appreciate if he could test this.
Also needs a rebase.
This should be fixed by 📌 Anonymous users - Multiple voting from one IP Needs review . Please re-open when needed.
This can be taken up now.
Thanks everyone who participated on this issue for the past 8 years! Please create a new issue if you encounter any issues with this.
I guess that's not a problem. I haven't checked how other modules do it, but I guess you can show the "browse tokens" text conditionally when the token (contrib) module is installed.
As for replacing tokens in the notification message. I think the only thing we need to do is implement: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Utility%2...
During the rendering of the message.
1) "Anonymous vote restriction" field doesn't save (or doesn't load saved value) when save/edit poll
I could not replicate. That sounds more like the database schema was not installed/updated correctly?
The required field logic is fixed by using a state.
bramdriesen → created an issue.
bramdriesen → created an issue.
I think this is ready for review once more. Preferably also some manual testing as there was one issue the tests didn't catch which I'm still not sure why that test was nog failing (see last commit).
fixed a few things.
one comment was not fixed.
+1 For RTBC. Totally forgot about this issue.
Thanks for testing!
bramdriesen → created an issue.
Probably needs a rebase as well before re-attempting this as some modules are removed.
Looks like the failing tests were false positives.
We can't just change this with the current compatibility scheme. This will only work going up from 10.3 and will break everything below I think.
@ggh I noticed your effort on fixing those things for a lot of modules. Note that this falls under the credit abuse policy as this is an task that can be automated. https://www.drupal.org/drupalorg/docs/marketplace/abuse-of-the-contribut... →
bramdriesen → created an issue.
bramdriesen → created an issue.
I did go ahead and replace the mild grey for non-stable releases with the mildest grey. This should improve contrast, and reduce the highlighting of prereleases.
That looks a lot more easing on the eyes, and from a quick glance, looks a lot different to the blue so that's already a lot better.
Whenever we do small design changes, we’ll be incorporating the new branding elements. Hopefully things don’t look too mismatched as they gradually change, but it's a lot more doable than attempting to get everything right all at once.
Yes 100% agree, small incremental changes are easier to manage instead of a big bang. And let's not forget with designs, there is not a single design that works for everyone 😊.
Thanks for this small, but great change @drumm!
The blue on grey is a fail for WCAG AA small text.
I do think there should be clear a distinction between covered and not covered by the security advisory in the releases section. Besides the little shield, it should be very clear like it used to be.
Really not convinced blue and grey are the best colour choices. Also, with the goal to modernise, this feels like a step back with the rounded corers, it really doesn't seem to fit here. I can understand this for marketing content, but not here :-).
I don't like the colour change. I don't really have an issue with the blue one for stable & covered releases. But the grey is really not as clear that it's different for an none stable release or not covered project. Yellow/Orange pops more as "hey watch out". Grey is too neutral for me, and I think this will cause confusion. When landing on a project with no stable/covered release, it's really hard to tell without looking for the shield or the tagged version.
I guess this was done because the --drupal-yellow from the brandbook is too "hard". But I really feel we should pick a different collour as grey which is close to the blue.
Slack thread: https://drupal.slack.com/archives/C1BMUQ9U6/p1742889668136919
bramdriesen → created an issue.
Let's use official sources instead of Wikipedia et al (see IS).
Pronounced “droo-puhl,” the name derives from the English pronunciation of the Dutch word “druppel,” which means “drop.”
Check if possible to map entity type as string and the values (checkboxes) as boolean.
bramdriesen → created an issue.