I don't think this is that. The patch from that issue did not resolve.
OK, got this thing working locally. Might need a little help with that failure but looking into it right now:
1) Drupal\Tests\footnotes\FunctionalJavascript\FootnotesCkeditorPluginTest::testBasicFootnoteCreation
Behat\Mink\Exception\ElementNotFoundException: Element matching css ".ck .footnotes-preview" not found.
/builds/issue/footnotes-3515650/vendor/behat/mink/src/WebAssert.php:465
/builds/issue/footnotes-3515650/vendor/behat/mink/src/WebAssert.php:509
/builds/issue/footnotes-3515650/tests/src/FunctionalJavascript/FootnotesCkeditorPluginTest.php:97
Also, I'd need to add my own tests to it, but honestly not even sure how to do that in this context where the module to integrate with may not exist, needs its own setup, etc.
Indeed, looks like the solution is over here: 🐛 Provide upgrade path for "node_type" condition RTBC .
LOL, I really didn't get very far with this - going to need some help from folks who understand this stuff far better than I and it's also not clear it actually belongs in this model rather than context itself:
/**
* Update node type conditions from node_type to entity_bundle.
*/
function context_active_trail_update_8001(): void {
foreach (Drupal::service('context.manager')->getContexts() as $context) {
foreach ($context->getConditions() as $condition) {
if ($condition['id'] === 'node_type') {
$condition['id'] = 'entity_bundle:node';
}
}
}
drupal_flush_all_caches();
}
seanr → created an issue.
I'm happy to assist for the same reason. ;)
FWIW, I was able to simply save the config page and re-export the config. Following that, deploys work fine without causing the warning.
I got curious as to the underlying reason for this limit and of course found it in the API docs - seems to be a file system limit:
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Config%21...
Most file systems limit a file name's length to 255 characters, so ConfigBase::MAX_NAME_LENGTH restricts the full configuration object name to 250 characters (leaving 5 for the file extension). The config prefix is limited by ConfigEntityType::PREFIX_LENGTH to 83 characters, so this leaves 166 remaining characters for the configuration entity ID, with 1 additional character needed for the joining dot.
Not going to change the issue status myself, but perhaps this should be won't fix?
I'll second this - it should fail much more gracefully than it does. When I have time, I'll see if I can work up a patch for that.
We're having the exact same issue astutonet just mentioned, except for us it's only happening on production (not staging or local using ddev). It is intermittent. We've ruled out anything on the Drupal side. Both that comment and mine aren't really related to this issue other than the fact that I at least agree that the error is too verbose when it's obviously just Anonymous trying to access something it doesn't have access to.
Does a generic 403 really need to capture such verbose data? My suggestion for this ticket is to make it configurable and off by default. If you really need it for dev/debug purposes, you would go to /admin/config/development/logging and enable it.
seanr → created an issue.
Thank you, sorry for the noise. We muted our errors based on evidence that they were bot hits.
@dench0, that does not look at all to me like the same issue, at least per my read of it. Am I missing something? Our CAPTCHAs work fine when we submit, we're just getting errors kicked into Sentry from obvious bots.
Might be useful to some folks - reducing the log level here to avoid spamming us with Sentry notifications.
Technically, it's freemium open source, I guess you could say - as in you can use it out of the box like we do with JSON API or the core Rest stuff, but you wouldn't get some additional features. In our case it works perfectly fine without paying for it. I appears that the extras are a service provided by them, not simply unlocking features. That's not a violation of open source any more than any other module that integrates with a paid service and in this case it is quite useful without the service unlike some others.
Confirmed I'm getting the overrides correct (we should be sending via smtp), but I'm still getting this:
An attempt to send an e-mail message failed, and the following error message was returned : Error creating transports: Unsupported sendmail command flags "/opt/mailhog/mhsendmail"; must be one of "-bs" or "-t" but can include additional flags.
drush @tcf.stage cget --include-overridden symfony_mailer_lite.settings
_core:
default_config_hash: EyOEXkLJD4vYGpK5wicdBSwBorOJgslf_tyscMgeN0Q
default_transport: smtpdrush @tcf.stage cget --include-overridden symfony_mailer_lite.symfony_mailer_lite_transport.smtp
uuid: e313ee9e-2ca1-42ea-ac39-a27bf2f56326
langcode: en
status: true
dependencies: { }
id: smtp
label: SMTP
plugin: smtp
configuration:
user: ''
pass: ''
host: 127.0.0.1
port: '1025'
query:
verify_peer: false
local_domain: ''
restart_threshold: null
restart_threshold_sleep: null
ping_threshold: nullWith swiftmailer on our staging server, it was 127.0.0.1, not localhost. Could that make a difference?
This is still extant in 2.0.2
Ah, got it. I ended up migrating my sites to CK5, so it's kinda moot, but it's a PITA since the config isn't 1-to-1. :(
I just tested this and it doesn't seem to be working for me. Oddly, the same site in ddev on my local doesn't show the error, but on staging it does (same PHP versions, etc). Cleared caches, etc, but it works with or without the patch locally, and doesn't either way on staging. Any ideas?
Per that same CVE report:
The fix will be available in version 4.24.0-lts
Would it not be possible to pull that release into this module? I've got a situation where upgrading to Ckeditor5 causes breakage. I'd obviously like to get it upgraded and that issue resolved, but finding the time...
I can confirm patch in #8 only partially fixes it. It's a damned good thing I watch those config diffs like a hawk. 🤣 FWIW, I'm now using https://www.drupal.org/project/config_ignore → and I recommend that anyway as it's targeted to specific configs rather than the whole module.
For anyone who finds this: https://www.drupal.org/project/config_ignore → may be a better solution.
This actually looks like a duplicate of this one: #3010626 - marking as such.
I'm seeing this as well. In our case, we've got fairly complex nodes with paragraphs attached and the like, so I'd certainly expect to see performance issues. The batch suggestion is an interesting one, but like webdrips, I don't get that far. The problem appears to me to be handling of nested entities. One a node that I can clone, this is what I end up getting in the UI:
That is obviously quite unmanageable, even just from a UX perspective. Unfortunately, I don't have any good suggestions for how to deal with this.
I had to manually massage the patch in 21 to get it to work - it needs a re-roll (still against 3.1.0), but it also needs a trailing line break. I've attached my locally modified patch which should apply, but it really needs a proper re-roll (at least until we get a new release).
Hadn't thought of that (still more used to the old-school patches that were static once uploaded). Thank you.
More detail:
'git' -C '/var/www/html/web/core' apply --check --verbose -p1 '/mnt/ddev-global-cache/composer/patches/a3bd64da48f2f91a9432010435e27ddba600cadf60f985ff08e5cfc3b25b35c6.patch'
Checking patch core/lib/Drupal/Core/Render/Element/Date.php...
error: core/lib/Drupal/Core/Render/Element/Date.php: No such file or directory
Checking patch core/modules/datetime/config/schema/datetime.schema.yml...
error: core/modules/datetime/config/schema/datetime.schema.yml: No such file or directory
Checking patch core/modules/datetime/src/Plugin/Field/FieldWidget/DateTimeDefaultWidget.php...
error: core/modules/datetime/src/Plugin/Field/FieldWidget/DateTimeDefaultWidget.php: No such file or directory
Checking patch core/modules/datetime_range/config/schema/datetime_range.schema.yml...
error: core/modules/datetime_range/config/schema/datetime_range.schema.yml: No such file or directory
Checking patch core/modules/datetime_range/src/Plugin/Field/FieldWidget/DateRangeDefaultWidget.php...
error: core/modules/datetime_range/src/Plugin/Field/FieldWidget/DateRangeDefaultWidget.php: No such file or directory
Checking patch core/modules/field/tests/src/Kernel/Migrate/d6/MigrateFieldWidgetSettingsTest.php...
error: core/modules/field/tests/src/Kernel/Migrate/d6/MigrateFieldWidgetSettingsTest.php: No such file or directory
How can I get composer to do that? Here's what I just tried with no luck:
{
"patches": {
"drupal/core": [
{
"description": "#2699895: Date increment fix",
"url": "https://git.drupalcode.org/project/drupal/-/merge_requests/7239.diff",
"depth": 1
}
],
...
Error from composer:
No available patcher was able to apply patch https://git.drupalcode.org/project/drupal/-/merge_requests/7239.diff to drupal/core
Figured it out - has to be the same style in all three places (so not automatic up above). We need another issue status: "Closed (user error)" 🤣🤣🤣
Do we have a working patch for D10, or can a backport be made? I just got a client request that needs this and obviously the D10 diff didn't apply. 😂
That works now with the following:
$ composer require chx/drupal-issue-fork
$ composer drupal-issue-fork https://git.drupalcode.org/issue/beautytips-3391609/-/tree/3391609-drupal-10-compatibility
$ composer require 'drupal/beautytips'
Still doesn't work because you're missing a composer.json.
OK, thanks. Looks like we are going to split it out into our own widget though we're using the patch for now for the sake of expediency (launch imminent!). I plan, perhaps over the weekend to break this out into its own project and release it.
@dpi, I respectfully ask you to reconsider. I've created a working MR. The multicardinality option is insufficient - already tried that, but it doesn't set the right values (it actually creates separate calendar items which is incompatible with situations where one or more dates in a sequence is different, i.e. to avoid a holiday). This actually came out of a client request as the functionality actually existed on their old D7 site. This patch/MR should follow the spec and accomplish the goals:
https://git.drupalcode.org/project/date_recur_modular/-/merge_requests/9...
seanr → changed the visibility of the branch 3424198-can-add-exclusions to hidden.
Patch doesn't seem to work. Try to add an exclusion date and end up with the following.
Still seeing in 2.0.2.
Still seeing this in 8.2? D10.
I'm a little confused by this thread (it's quite long and convoluted), but is there a patch/MR that works against D10? I've got a client yelping about this. :D
Could you add the commit in which this was fixed? I'm hitting the same error in my own module and getting jack shit from Google. 😡
I literally had to manually extricate this crap with DB queries. Unreal. Maybe it's better now, but I'm avoiding it for a bit. It just ended up all kinds of broken and it was like pulling a crocodile's teeth to get it out. 😡
I'm running into this with Lando (Pantheon recipe) running PHP 8.1.18.
laura.gates → credited seanr → .
I'm just gonna say, can we get a "like" button for issue comments? And maybe "love" too? ❤️
I'm stuck with a completely unusable composer - I can't even run `dump-autoload`. Is there a way to do that manually?
OMG, I am so sad to hear this, but I'll refrain from marking it "needs work". 😢 I hope you know how much I love you Angie - you are an inspiration, not just for your Drupal-specific work but also for your work with the community as a whole as well (I was at the Drupal Queer BOF in SFO and the first D&I BOF as well). ❤️😭
Not sure what I should be looking for in that file. I created the worform from a standing start and had errors off the bat - wasn't anything I imported, this is a brand new start. Anyway, adjusted patch here.
Yahtzee! No more errors. :D I could use some help just to make sure this patch doesn't introduce any issues I'm not seeing...
Better one and catch some more...