committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
Is this still needed after https://git.drupalcode.org/project/cps/-/commit/85e6127a461682bd2265cee5... ?
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks!
committed, thanks.
This was committed 5 months ago, can you create a new release with it in it?
douggreen → created an issue.
And modern Drupal has the same problem, see DatabaseQueue.
My summary of what is happening. Let's say that you have 10,000 items in your queue, and the serialized data for each is 5MB (our actual use-case), two processes are trying to claim the queue item at the same time, each processes query takes multiple seconds (up to 30 seconds), to get the same item and data, but only one of them will then succeed to set the expire and lock the item, thus the second process just wasted 30 seconds trying to get a lock.
We should instead, just get the item, set the expire, and then get the data.
I came to the similar solution on my own, but I think you want to update the expire time before you grab the data.
douggreen → changed the visibility of the branch 3497225-plain-text-formatter to hidden.
https://git.drupalcode.org/project/address/-/merge_requests/65 does the same as the attached patch, and adds test data.
This is ready for review again, complete with a test :)
I agree with @azinck, I believe we can create a test.
douggreen → created an issue.
I've been looking into the suggestion by @catch in #71. Here's a patch (no MR because I'm not sure we want to go this direction).
I'm sorry I didn't see these requests when they were needed a year ago. The best way to get my attention is through the contact for or slack :( I've committed the change for D11. TBH I don't use this module anymore and I'm not even sure who I wrote it for.
sure, I've granted you full access. tbh, I'm not even sure what client I wrote this for.
douggreen → changed the visibility of the branch 3497225-plain-text-formatter to active.
douggreen → changed the visibility of the branch 3497225-plain-text-formatter to hidden.
douggreen → created an issue.
This fixed the problem for us as well. Can we get this merged and a new tag applied?
Reroll for 10.4.x
Attached is #23 rerolled for core 10.4.x
douggreen → created an issue.
I've also run into another use-case where it doesn't work, still using IEF complex.
The last commit fixes the validation warning.
When I use this to just upload media, I now get the error This value should not be null. after the upload succeeds, so there's something still wrong here.
I think this fixes it with IEF, but I haven't tested it outside IEF. Please test :)
douggreen → created an issue.
Oh wait, this will work, I just need to configure it differently. As for tests ... I apologize in advance, but I'll leave that for someone else.
@anybody this solution didn't actually solve our problem, so I'm going to suggest another solution. Our user's were still banned, but after a few tries now. I think we need config that just doesn't ban based on honeypot time.
Closing since this is included in ✨ Drupal 11 compatibility for Video Embed Field Needs review
I updated the project page with details from the README.
Closing, this was fixed some time ago.
merged, thanks
douggreen → made their first commit to this issue’s fork.
It does not. This is a very simple port of this one feature from the Drupal 7.x version of https://www.drupal.org/project/govdelivery → .
This appears to already be fixed (not sure when it was ever a problem TBH). The MR shows no changes.
Closing, D8 is no longer supported
This was done in June 2023, not sure why this issue still exists, closing
Committed, I wasn't initially a fan of this, but as an option it's certainly valuable.
sure, committed.
Thank you, this was merged.
This was committed directly. Thank you to the bot developers (having this issue and the bot tell me that nothing else needed to change, was empowering to make this simple change).
The MR adds configuration for honeypot. Do we also want to add a flag to just enable/disable honeypot banning?
I think it works with a Simple IEF form but not a Complex form.
There are also problems with IEF because the FormState built in the Event is missing critical state information.
We have also run into this. I think that the honeypot code needs to be more configurable. There should either be config to disable it, or config to control it's value separately from the default IP banning.
Closing, ... I ran into the same issue. We've decided to not pursue SRI for external JS provided by reliable 3rd parties such as yourself. While there is a security concern, it's impossible for us to keep up with 3rd party libraries which might change. This really is the responsibility of those 3rd party libraries, such as crazyegg, to provide SRI's.
I took a different approach than the existing work, and wrote a drush command that encrypts existing data. See ✨ Add drush command to encrypt existing data Needs work
douggreen → created an issue.
To answer my own question from above, see 📌 Create a Bulk Encryption/Decryption Service Class to facilitate encryption of pre-existing data Needs review and 📌 Create a UI for managing encryption of pre-existing data and changing encryption profiles. Active
The patch solves the error. I'm wondering if there's another solution to encrypt existing content that wasn't previously encrypted.
I've seen this warning in my logs but I'm having a hard time finding a test case, and I haven't seen it recently. I think that this patch is just hiding an underlying problem, which is that either that #max_delta is wrong, or that the element that #max_delta points to wasn't added. Can anyone reproduce this still? Is it possible that this was a problem in core that has since been fixed?
Patch attached
douggreen → created an issue.
LGTM
I still get a PHP warning in AttributeArray (line 79) because the original input array is statically cached in ViewExecutable::getExposedInput() on line 726, which happens before the data is validated. We need to validate the data before it is saved.
Since it's not version controlled, we can't rely on the SRI, and should remove it. The file has changed at least once since we implemented this.
I rebase and force pushed the branch. It needs review by someone who is familiar with what this does.
douggreen → made their first commit to this issue’s fork.
Do this do anything that ✨ Add option to show only start or end date in the DateTime Range custom formatter Needs review doesn't do? If it does, I think it needs to be re-worked now that the other issue has committed.
The above commit should fix this.
douggreen → created an issue.
douggreen → created an issue.
$ curl https://cdn.localizejs.com/localize.js | openssl dgst -sha384 -binary | openssl base64
7w/vCB9txvKaPgvRpSBQWnsULnvvH1VyQJXvjZujqTrsAvQI6B0H42gKqQUCG3y6
douggreen → created an issue.
I like the idea of removing the config option extlink_target_append_new_window_label which defines the label text and is new to this patch, always using the recommended text, and linking to the external resource (from above). This isn't removing an option in production. This is removing an option that someone in this thread thought helpful, and replacing it with a standardized (maybe industry standard) a11y text.
The current patch checks for "new window" in the existing label (not "opens in a new window") so I think that the existing patch is already backwards compatible with production systems.
If we agree, then what's left is to remove the config option extlink_target_append_new_window_label and make sure the tests work. If I understand correctly, we're pretty much at the place that you started with this ticket, it just took me a while to get there (sorry). What do you think?
This appears to have merged, so marking as fixed.