ryanrobinson_wlu → created an issue.
"Web Interface Settings" is a good label, in my opinion. I had gone with the simpler "Interface Settings" but adding "Web" is a bit better, since it might differentiate from possible conflicts like browser interface settings.
Thanks @danrod!
I am using whatever is provided by the module, not doing any extra compiling.
Drupal core for my development branch is now up to 10.4.2. Production is on 10.3.10. I'd be aligning an update to fluidui with the development branch for the next release, not rushing it through to production before then, so there's no concern from my end about it working with anything older than 10.4.x.
I believe that worked, thank you! Do you want to leave this open as a reminder to update the README, or go ahead and close it?
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
Thanks. I thought I had cleared caches already after trying the update, a couple of times. But when I just tried the update again, no problems, so most likely I was forgetting to clear the caches.
I don't think this is as simple as the 2.0.1 update. After going back to 2.0.0, it was working for a while. Then it started throwing the error again.
I've determined that we don't really need this module so I am removing it. You can keep this issue open if it is likely to be a problem anybody else, or go ahead and close it.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
Thank you for helping make that happen! I've made a note that I can phase out my custom module and use your new token in our next release, assuming the webform update is stable by then.
ryanrobinson_wlu → created an issue.
I am putting it in the cc field, which does accept tokens as well as multiple values. It works with the custom token I had previously made where the token is provided as a comma-separated string as opposed to an array that then needs joined. Yours also works as a token when I use join but without specifying a separator, but that means the emails are crammed together which would not work to send to them. If I try to add the comma separator, I am getting the behaviour you've described, with it claiming that it isn't valid. I'm guessing the presence of the , is what is causing it to "parse the token as-is as an email address". That would essentially mean that your token in general works, just doesn't solve my particular problem because I can't join by , in there.
I've attempted it and had two problems so far:
1. I tried to install it with a patch in composer as I normally do. Composer keeps coming back with "Could not apply patch". I don't know why. I eventually manually updated the file so I could test further, but I would ultimately need to solve that to be able to deploy it to other environments. This one can be mostly ignored because if it gets into a stable release, it won't matter in the long run.
2. I can't figure out an allowed format for the token. In the context of the webform submission email, I can do [webform_submission:node:co_authors_email:join] which works but the elements are crammed together with no separation instead of with commas in between. I tried other varieties like [webform_submission:node:co_authors_email:join:,] and [webform_submission:node:co_authors_email:join:","] which are implied to be an option by the ? in the token browser but will not save, saying it is an invalid token value.
Patch solved the issue for me.
Thank you. I'm not quite ready to go for Drupal 11, but I used this to fix some errors stopping me from running other unit tests.
Here's a patch, if there's anybody else like me who can't run any unit tests even on our own custom modules while this fatal error is still in place.
Patch works for me against 3.0.0-beta1
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
Ah, good news, it looks like this is already in progress and it just hasn't made it into a release yet! https://git.drupalcode.org/project/search_api_block/-/blob/1.0.x/config/...
I did the git clone to start to prepare an MR and found a file already there. It is named simply schema.yml instead of search_api_block.schema.yml, the latter of which seems to be the standard practice. Otherwise, please put this into a release once you're confident it's ready.
I attempted to make a patch to use until that release, but could not seem to get it to work, so I'll have to put up with the errors until the release.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
Update: I managed a minimal test - not everywhere that it was before, but enough I think - to feel fairly confident in the theory from the previous post. I did not get the error at all on about 20 page loads I tried and filled out the AJAX webform with a recaptcha on it a couple of times, submitting successfully.
@Anybody I did report to miniorange. Their first response was "Based on my initial observation, it seems that the event subscribers of both modules are conflicting with each other."
But @grevil's comment gave me another idea. This error happened around the same time that we were doing some work on shifting to containerized deploys, starting with dev and staging. At one point in there we changed the name of the web Docker service being deployed, but the older ones were still there. There were a couple other minor things we fixed in between those early deployment tests with the old name and the newer tests with the new name, and sometimes we would see the issue in place again and sometimes not. I'm pretty sure what was happening is sometimes I was being served the old one instead of the new one, from before the bugs were fixed.
So I think there's a pretty good chance that what happened is that the earlier version of recaptcha without RecaptchaSettingsConfigSubscriber was deployed with the old Docker service name. Then the updated version of recaptcha came out and was deployed with the updated name. Sometimes when I was loading the site it served the old one, without RecaptchaSettingsConfigSubscriber but with the database expecting it to exist, creating a fatal error. That would explain why the problem, like the other reappearing bugs, were not entirely consistent, sometimes present and sometimes not. It would also explain why I could only replicate this problem on dev and staging servers, not on my local development environment.
I'll try to verify that theory and check back in - which might not be immediate since the new deploy process is not quite reliably done yet - but the timeline makes sense and the behaviour mostly makes sense. The only part that doesn't make sense is why uninstalling miniorange seemed to fix it, but maybe that was simply confusing luck that when I tried that I happened to always load the new Docker service without the error.
I would support the use of em instead of px as the default for this. In the context of a CKE block, that will usually make more sense and be adaptable for tools like our accessibility toolbar that allows changing font sizes or spacing.
I haven't tried the new release yet. We're about to do a new production release so we're frozen on new non-essential changes. But I will definitely try to switch out the existing indentblock module for this after that.
ryanrobinson_wlu → created an issue.
Thank you!
Will this be in a stable release within the next few days?
We're close to deploying an update to production, and the patch doesn't work against the stable release anymore, so I think I need to put the dev release into production if there isn't stable soon, which I am generally not eager to do.
@hyperlinked
Sorry, poor wording on my part. I meant that I had those cache bins as null on local/dev, not on staging or production.
Your explanation makes sense for why I was seeing the constant alert on staging (still has the default cache bin) but not on local/dev (null cache bin site-wide).
I have now followed the lead of #72, which if I'm understanding correctly means no caching of alert messages, but maintains the caching everywhere else.
+1 for the workaround in #72.
On my dev site that had these in the settings:
$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';
Everything seemed fine with just #17. When it went through to the staging site, I saw the "All caches cleared" message on every page. So I added the line in #72 which seems to work so far on local even when I commented out those lines in the settings file, but I'll update this if it turns out to not fix it on the real staging.
Here's a patch for the h5p-editor file's deprecation I was getting.
This one was a bit weird. I found the git repo for h5p-editor here: https://github.com/h5p/h5p-editor-php-library. In that master branch, the fix was already in place.
But the Drupal module is locked to an older version. I tried the patch in https://www.drupal.org/project/h5p/issues/3411479 📌 Allow update to H5P editor/core 1.25 Fixed to allow a higher version of h5p-editor. The patch applied, but it did not seem to do anything to update my h5p-editor version.
So then I went ahead with cloning from 1.24.4 and creating a patch based on that.
I've updated the patch to also cover a couple of the deprecations I see when I create a new node with an H5P object. It's the same idea as the previous patch, just a couple more of them.
These are just the ones that are in the h5p-core. I'm still trying to figure out how to write a patch for h5p-editor which is still giving me another deprecation warning when I create a new object.
The proposed change fixes the problem for me.
The proposed change fixes the problem for me.
ryanrobinson_wlu → created an issue.
I've made a custom module that adds a new token like below. You're welcome to use/improve this if you think it would be helpful to others. If you decide to incorporate something like this into the main module, I'd be happy to phase out mine.
From the coauthor_tokens.module file:
<?php
/**
* @file
* Token functions extending node_co_author.
*/
use Drupal\Core\Render\BubbleableMetadata;
use Drupal\user\Entity\User;
/**
* Implements hook_token_info().
*
* Defines tokens.
*/
function coauthor_tokens_token_info() {
$info = [];
$info['tokens']['node']['coauthors_email'] = [
'name' => t("Coauthors' emails."),
'description' => t("The coauthors' email addresses, separated by commas."),
];
return $info;
}
/**
* Implements hook_tokens().
*
* Defines values for tokens.
*/
function coauthor_tokens_tokens($type, $tokens, array $data, array $options, BubbleableMetadata $bubbleable_metadata) {
$replacements = [];
foreach ($tokens as $name => $original) {
if ($type == "node") {
switch ($name) {
case 'coauthors_email':
$node = $data['node'];
if ($node) {
$coauthor_emails = [];
$coauthors = $node->get('co_authors')->getValue();
foreach ($coauthors as $coauthor) {
$coauthor_emails[] = User::load($coauthor['target_id'])->getEmail();
}
$replacements[$original] = implode(',', $coauthor_emails);
}
break;
}
}
}
return $replacements;
}
ryanrobinson_wlu → created an issue.
I have the same error since updating to Drupal 10.3. Through trial and error of uninstalling one ckeditor-adjacent module at a time, I found I needed to uninstall both ckeditor_indentblock and ckeditor_codemirror to get the error to go away, so I logged the same issue there: https://www.drupal.org/project/ckeditor_codemirror/issues/3457347 🐛 Drupal 10.3: LangcodeRequiredIfTranslatableValues constraint can only operate on the root object being validated Active .
ryanrobinson_wlu → created an issue.
Thank you. I think that's good again. I tested with the patch option (not overriding existing) still on, removing the patch option, and removing having the filter entirely. No errors from any of them.
After updating to Drupal 10.3, with this patch installed and its functionality in use on two existing text formats, I'm getting this error when I try to save a new text format:
'keep_existing_ids' is not a supported key.
It does not matter if the new format has the "Automatically apply identifiers (anchors) to headings in content" filter is enabled or not. The error occurs either way.
Removing the patch does fix it, which makes sense since that key identified is pretty clearly tied to this patch.
I'm not sure what the fix is - is there something else that needs to be done to declare that key as supported?
ryanrobinson_wlu → created an issue.
This works for me. I've just started testing the module with this patch, and everything is good so far.
I don't really see a status option for "it's done but not in a stable release yet" so I went with the closest I saw, keeping it open so anybody else looking for the same will find it easily.
I tried this patch as I was looking for the same thing. The general idea works, but I have a couple suggestions.
One is the upgrade path if this is added when you already have a button. I had an existing button that was set to only allow the Teaser display mode and was showing the caption and alignment options. After adding the patch, all of those options went to blank, meaning all the display modes showed up as options and caption/alignment did not. I think this should maintain existing settings as the default: whatever I previously had in display mode, and caption/alignment on. Imagining this coming through as a release, some would be surprised to have the behaviour changed.
The second is that now the second page is unnecessary. The first page I select the entity I want to embed. The second page only shows me that same entity name again. Can that second page be skipped entirely if there are no options on it?
The changes work in my tests, no more deprecation warnings in the logs.
One issue I've now encountered with the patch in #273 is that it adds a new functional test, but the setUp function there does not have the void return declaration, which results in throwing an error if I try to run any functional tests. See https://www.drupal.org/project/recaptcha/issues/3446000 🐛 Functional Tests: Declaration of Declaration of Drupal\Tests\recaptcha\Functional\RecaptchaJavascriptTest::setUp() Closed: duplicate . I added that to an updated patch here.
My editor (VS Code with a Drupal formatter) is pointing out other issues with that file, but those ones don't stop me from running other tests, so I'll leave that to those who are working on that test.
Ah, thanks for catching that the one other patch I'm using for this module is what is adding that bad test. I missed your edit on your first comment before I made my response. I was getting very confused why there was no alignment between the composer version and the repo version. In that case, I should be able to edit that patch file to add that void declaration.
Thank you! The bit I looked into #[AllowDynamicProperties] I got the same impression: maybe there are some situations where it is necessary, but the proper solution usually is to declare the properties.
You're right, I don't see it in 8.x-3.x-dev either. Is there any hint that will be in a stable release soon?
I'm attempting to put together a patch for 3.2, so that tests of my custom modules could run in composer-built CI, but I can't find a way to clone that specific release in order to build a patch of it (using instructions here: https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... → ). Do I need to switch to the non-stable dev branch or just not have any functional tests until the next release, or am I missing some other way to tell composer I want stable but with this one fix?
ryanrobinson_wlu → created an issue.
Works and makes sense for me.
ryanrobinson_wlu → created an issue.
Ah, great news! Hopefully we'll see it get through to stable before we put production up to 8.2, but at worst I can either write my own patch or ignore the deprecation warnings for a bit longer.
Update: I got three more of them after creating a new H5P node (a Multiple Choice quiz, but I don't know if that matters).
Deprecated function: Creation of dynamic property H5PValidator::$h5pCV is deprecated in H5PValidator->__construct() (line 743 of /opt/drupal/vendor/h5p/h5p-core/h5p.classes.php).
Deprecated function: Creation of dynamic property H5peditor::$content is deprecated in H5peditor->processParameters() (line 158 of /opt/drupal/vendor/h5p/h5p-editor/h5peditor.class.php).
Deprecated function: Creation of dynamic property H5PContentValidator::$allowedStyles is deprecated in H5PContentValidator->filter_xss() (line 4198 of /opt/drupal/vendor/h5p/h5p-core/h5p.classes.php).
Patch also worked for me.
Minor note on the issue description: this started with PHP 8.2, not just 8.3. I found it when I tried updating from 8.1 to 8.2.
ryanrobinson_wlu → created an issue.
Same issue. I enabled term_merge on my local development containers and the error is now gone - I have not yet tested our automated deployment to other servers - but I agree that there needs to be a smoother upgrade path in place.
ryanrobinson_wlu → created an issue.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I think you're right. I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I think you're right. I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even when I specify which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even though I specified which group of tests to run.
I'll close this. I'm still getting the error about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including this one). So it's probably another module's problem that is showing up in this module's report even though I specified which group of tests to run.
Looks good to me so far! Thank you.
I'm still getting the other one about EntityReferenceTestTrait, but I'm getting that for every single module I test, even though if I grep for that it only shows as being in a few of them (not including linkit). So it's probably another module's problem that is showing up in this module's report even though I specified which group of tests to run.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.
ryanrobinson_wlu → created an issue.