We were getting the following:
Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
Taxonomy term
The Publish state field needs to be installed.
The Unpublish state field needs to be installed.
We attempted to remediate by simply uninstalling and reinstalling the module and exporting the config, but we received the error from https://www.drupal.org/project/scheduler_content_moderation_integration/... →
For some reason, it became very clear that many of our sites were missing one or more of updates 9001, 9002, and 9003. I am not sure if this was due to a developer's error in not exporting the configuration and commiting the configuration to the codebase, or if it's an issue with Scheduler dropping off updates later in its version life. I'd suspect it's the former because the current scheduler still has these updates in the code.
We had to do the following:
drush php:eval "require_once 'modules/contrib/scheduler_content_moderation_integration/scheduler_content_moderation_integration.install';"
drush php:eval "require_once 'modules/contrib/scheduler_content_moderation_integration/scheduler_content_moderation_integration.install'; scheduler_content_moderation_integration_update_9001();"
drush php:eval "require_once 'modules/contrib/scheduler_content_moderation_integration/scheduler_content_moderation_integration.install'; scheduler_content_moderation_integration_update_9002();"
drush php:eval "require_once 'modules/contrib/scheduler_content_moderation_integration/scheduler_content_moderation_integration.install'; scheduler_content_moderation_integration_update_9003();"
drush cex -y
Then commit the new configuration.
We were getting the following:
Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
Taxonomy term
The Publish state field needs to be installed.
The Unpublish state field needs to be installed.
We attempted to remediate by simply uninstalling and reinstalling the module and exporting the config, but we received the error in the OP. Instead, we had to do the following:
drush php:eval "require_once 'modules/contrib/scheduler_content_moderation_integration/scheduler_content_moderation_integration.install';"
drush php:eval "require_once 'modules/contrib/scheduler_content_moderation_integration/scheduler_content_moderation_integration.install'; scheduler_content_moderation_integration_update_9001();"
drush php:eval "require_once 'modules/contrib/scheduler_content_moderation_integration/scheduler_content_moderation_integration.install'; scheduler_content_moderation_integration_update_9002();"
drush php:eval "require_once 'modules/contrib/scheduler_content_moderation_integration/scheduler_content_moderation_integration.install'; scheduler_content_moderation_integration_update_9003();"
drush cex -y
Then commit the new configuration.
Yeah, there is a workaround and that's nice, but we really shouldn't normalize this kind of thing as a reasonable way to do releases. Minor versions of a module should include all database updates necessary to upgrade from one minor version to another.
With Acquia moving over to mysql 8 soon, folks on that platform may want to petition Acquia to contribute to this module.
loopy1492 → created an issue.
I applied the patch and it works for me. Please review.
loopy1492 → created an issue.
Thank you kindly for the response, @longwave. We feel safe using the temp solution in #36 and #38 then.
But if we're allowing acquia/drupal-recommended-settings (or blt) to auto-generate the salt file, we don't have to worry about this? According to the OP?
I'm confused. Does this affect 10.x or not?
You guys. The command mentioned in this issue should really be on the main page of the project.
@longwave I'd love to help out but it's been a minute since I've referenced a gitlab branch in composer and google is failing me. If you can point me to a reference here on d.o where I can tell my site to use the gitlab branch, I can help out.
I will close the github PRs.
If anyone knows the maintainers, I've made pull requests for core-recommended.
I agree with @larryla. I think that's the best path forward. The sooner that's done, the fewer people will have this issue.
Pretty sure this has to do with lightning_scheduler.
Ah, lightning. The gift that keeps on giving.
loopy1492 → created an issue.
Onlu the active button was really affected for us. I applied the patch from #2 and it fixed the problem for us:
core: 10.3.1
environment_indicator: 4.0.19
CORE 10.3.1
PHP 8.2
Search API: 1.35.0
RuntimeException while trying to render item entity:node/98251:en with view mode full for search index Default Content: Failed to start the session because headers have already been sent by "/var/www/html/vendor/symfony/http-foundation/Response.php" at line 408. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 132 of /var/www/html/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).
download a patch file from the MR and include it as part of your project repo rather than posting it in an issue comment.
Ah, I see. So, drupal.org just wants us to stop linking to patch files on thier site?
I mis-spoke. It only works on the full_html text format because it allows for the changing of any HTML tag. I'm guessing since every other text format must abide by whatever tags are allowed by the different plugins, ul type and ol type cannot be added.
I genuinely have no idea what's going on with this module but we pinned to
"drupal/ckeditor_liststyle": "1.x-dev#a34d9baa310af13de950e6e1f46c38faa6ac7c07",
And another one of our team members simply created a ckeditor 5 patch for the info file
diff --git a/ckeditor_liststyle.info.yml b/ckeditor_liststyle.info.yml
index 0823a9d..691e029 100644
--- a/ckeditor_liststyle.info.yml
+++ b/ckeditor_liststyle.info.yml
@@ -3,5 +3,5 @@ type: module
description: This plugin adds numbered list and ordered list properties dialogs (available in context menu) in CKEditor.
package: CKEditor
dependencies:
- - drupal:ckeditor
+ - drupal:ckeditor5
core_version_requirement: ^8 || ^9 || ^10And the module works.
This makes literally no sense whatsoever but here we are. My guess is the most recent version of the library works fine and any addional Drupaly stuff isn't really necessary to make sure the plugin works in general.
Cloned comment from https://www.drupal.org/node/3283526 →
I added a ckeditor5.yml file:
ckeditor_liststyle_liststyle:
ckeditor5:
plugins:
- list.bulletedListStyle
- list.numberedListStyle
drupal:
label: ListStyle
library: ckeditor_liststyle/editor
class: Drupal\ckeditor_liststyle\Plugin\CKEditor5Plugin\ListStyle
elements:
- <ul>
- <ul type>
- <ol>
- <ol type>
conditions:
plugins:
- ckeditor5_list
And we are getting:
LogicException: The "ckeditor_liststyle_liststyle" CKEditor 5 plugin implements ::getElementsSubset() and did return a subset ("<ul type><ol type reversed start>") but the following tags can no longer be created: "<ul><ol>". in Drupal\ckeditor5\Plugin\CKEditor5PluginManager->getProvidedElements() (line 409 of /home/ide/project/docroot/core/modules/ckeditor5/src/Plugin/CKEditor5PluginManager.php).
And of course the eternal problem of this message on the text format.
With CKEditor 5 this is a read-only field. The allowed HTML tags and attributes are determined by the CKEditor 5 configuration. Manually removing tags would break enabled functionality, and any manually added tags would be removed by CKEditor 5 on render.
Even adding the ul and ol manually to the config yml file won't override the Allowed HTML tags on import.
So what are we supposed to do?
Yeah. I am trying to help contribute to the ckeditor liststyle module.
I added:
ckeditor_liststyle_liststyle:
ckeditor5:
plugins:
- list.bulletedListStyle
- list.numberedListStyle
drupal:
label: ListStyle
library: ckeditor_liststyle/editor
class: Drupal\ckeditor_liststyle\Plugin\CKEditor5Plugin\ListStyle
elements:
- <ul>
- <ul type>
- <ol>
- <ol type>
conditions:
plugins:
- ckeditor5_list
And we are getting:
LogicException: The "ckeditor_liststyle_liststyle" CKEditor 5 plugin implements ::getElementsSubset() and did return a subset ("
") but the following tags can no longer be created: "
". in Drupal\ckeditor5\Plugin\CKEditor5PluginManager->getProvidedElements() (line 409 of /home/ide/project/docroot/core/modules/ckeditor5/src/Plugin/CKEditor5PluginManager.php).
And of course the eternal problem of this message on the text format.
With CKEditor 5 this is a read-only field. The allowed HTML tags and attributes are determined by the CKEditor 5 configuration. Manually removing tags would break enabled functionality, and any manually added tags would be removed by CKEditor 5 on render.
Even adding the ul and ol manually to the config yml file won't override the Allowed HTML tags on import.
So what are we supposed to do?
I noticed there's no ckeditor5.yml file for this module. That's where the plugins would be defined. Isn't this file necessary for any ckeditor 5 module?
I'm sure many of us would be happy to contribute to these modules that are having a problem with these new checks, but I think it would be nice for a link to instructions on how to resolve it for them rather than having to reverse engineer the core code that was changed.
This has been noticed during https://www.drupal.org/project/ckeditor_liststyle/issues/3326957 🌱 Make ckeditor_liststyle compatible with ckeditor5 RTBC
And I'm getting these errors when editing two different text formats:
The list style buttons seem to work, but when the wysiwyg loads, I'm still getting this in the console:
CKEditorError: schema-cannot-extend-missing-item {"itemName":"$listItem"}
Read more: https://ckeditor.com/docs/ckeditor5/latest/support/error-codes.html#erro...
at li.extend (ckeditor5-dll.js?v=40.2.0:5:312284)
at On. (html-support.js?v=40.2.0:5:62810)
at On.fire (ckeditor5-dll.js?v=40.2.0:5:604093)
at On._fireRegisterEvent (html-support.js?v=40.2.0:5:45500)
at editor.data.on.priority (html-support.js?v=40.2.0:5:43517)
at Vi.fire (ckeditor5-dll.js?v=40.2.0:5:604093)
at [as init] (ckeditor5-dll.js?v=40.2.0:5:607777)
at editor-classic.js?v=40.2.0:4:9696
I put this in my theme and it works. It's kind of terrrible, but it works. It lags pretty badly when the editor page opens or when you expand a paragraph that has a wysiwyg in it.
(function (Drupal, once) {
Drupal.behaviors.lastUpdated = {
attach: function (context, settings) {
// temove any CSS rule containing list-style-type for ol or ul
function removeCSSRule(styleTag) {
if (styleTag) {
// Get the current CSS content
let cssContent = styleTag.innerHTML;
// Create a regular expression to match ol or ul rules with list-style-type
const regex = /[^{]+\s*(ol|ul)[^,{]*\{[^}]*list-style-type:\s*[^;]+;[^}]*\}/gi;
// Find all matches
let matches = cssContent.match(regex);
// Remove all matching rules and log them
if (matches) {
matches.forEach(match => {
cssContent = cssContent.replace(match, '');
});
}
// Set the updated CSS content back to the style tag
styleTag.innerHTML = cssContent.trim();
}
}
// Function to check and remove the rule from new style tags
function checkAndRemoveRule(node) {
if (node.nodeType === 1 && node.matches('style[data-cke="true"]')) {
removeCSSRule(node);
}
}
// Initial call to remove the rule from already present style tags
document.querySelectorAll('style[data-cke="true"]').forEach(function (styleTag) {
removeCSSRule(styleTag);
});
// Observer to detect when new style elements are added to the DOM
const observer = new MutationObserver(function (mutations) {
mutations.forEach(function (mutation) {
mutation.addedNodes.forEach(function (node) {
checkAndRemoveRule(node);
});
});
});
// Start observing the document for changes
observer.observe(document.body, {
childList: true,
subtree: true
});
}
};
})(Drupal, once);I think it might be better to either have our own list.js like https://www.drupal.org/project/ckeditor_liststyle/issues/3326957 🌱 Make ckeditor_liststyle compatible with ckeditor5 RTBC does or contribute to ckeditor 5 directly.
So, just to rule out an admin theme issue, I switched to Claro for my admin theme and this still seems to be happening.
The list.js is being injected making it impossible to re-style the list items because css is case-sensitive and ol[type="A"] is the same to css as ol[type="a"].
The only thing I can think to do at this point is write some asynchronous javascript to find the css when it appears and remove it from the page.
Same. This is a real bummer. We are using an old core base theme for our admin theme, so the core project @Tomefa linked isn't working for us. For some reason all of these base themes have set the list styles at a fundamental level. Never mind the fact that ckeditor injects it onto the page itself with /docroot/core/assets/vendor/ckeditor5/list/list.js
I spoke too soon. That worked when I refreshed the page, but then after clearing some caches, it seems that ckeditor injected more styles into the page. I believe they came from here:
I was able to get this patch to work alongside https://www.drupal.org/project/drupal/issues/3274635#comment-15665742 ✨ [upstream] Use CKEditor 5's native and UX Needs work in order to get list styles working on Core 10.2.7.
I think these are the salient parts of the code where the style resides. This might be an relatively easy fix but I am just swamped right now.
Yeah. This seems to be working for us better than https://www.drupal.org/project/ckeditor_liststyle/issues/3326957 🌱 Make ckeditor_liststyle compatible with ckeditor5 RTBC which is throwing major errors right now.
However, this plugin seems to be only displaying the default list style in the wysiwyg, but is displaying it after publishing. (see screenshots)
Also please note, out of an interest for security, we will not ever use the Merge Request for our patching on our sites unless absolutely necessary.
Hmm. It doesn't seem to be saving.
I was able to write this alter for a search API filter. Yes, you can nest Condition Groups within other Condition Groups with this, which is a real lifesaver. This function was added to a Service, but I suspect it could be added in a .module file instead. I think. I'm also pretty sure this method (or similar) can be used to alter a sql query.
I left the debug code in (commented out) so you could see what objects we're dealing with here.
use Drupal\views\ViewExecutable;
use Drupal\views\Plugin\views\query\QueryPluginBase;
use Symfony\Component\HttpFoundation\Request;
use Drupal\search_api\Plugin\views\query\SearchApiQuery;
use Drupal\search_api\Query\ConditionGroup;
use Drupal\taxonomy\Entity\Term;
/**
* Filter Frame View - query alter, custom updates to the view query.
*
* @param \Drupal\views\ViewExecutable $view
* Drupal view.
* @param \Drupal\views\Plugin\views\query\QueryPluginBase $query
* Query.
*/
public function myFilteredViewViewQueryAlter(ViewExecutable $view, QueryPluginBase $query) {
if ($view->id() == 'my_view_id') {
// Check if the query is an instance of SearchApiQuery
if ($query instanceof SearchApiQuery) {
// Get the Search API query object
$search_api_query = $query->getSearchApiQuery();
// Get the current request object
$request = \Drupal::request();
// Get the exposed filter values from the query string
$queryParams = $request->query->all();
// Debug variable
$term_values = "";
// Check if the field_my_filter_term_field_one or field_my_filter_term_field_two parameters exist and are arrays
if ((isset($queryParams['field_my_filter_term_field_one']) && is_array($queryParams['field_my_filter_term_field_one'])) ||
(isset($queryParams['field_my_filter_term_field_two']) && is_array($queryParams['field_my_filter_term_field_two']))
) {
// Taxonomy variables
$term_storage = \Drupal::entityTypeManager()->getStorage('taxonomy_term');
// Create a new condition group for the wrapper
$conditionGroup = new ConditionGroup('AND');
// ID tracker
$old_parent_tid = null;
// Helper function to process filter terms
$process_filter_terms = function ($field_name) use (&$term_values, $term_storage, &$conditionGroup, &$old_parent_tid, $queryParams) {
$innerConditionGroup = new ConditionGroup('OR');
foreach ($queryParams[$field_name] as $value) {
// Get the taxonomy term from the filter
$term = Term::load($value);
// Check if the term is loaded successfully.
if ($term) {
// Get information from the taxonomy term.
$term_name = $term->getName();
$term_id = $term->id();
$parent_tid = $term->get('parent')->target_id;
if (!empty($parent_tid)) {
// Load the parent term using the correct term storage.
$parent_term = $term_storage->load($parent_tid);
// Check if the parent term is loaded.
if ($parent_term) {
if ($old_parent_tid != $parent_tid) {
// If this parent term is different from the previous one
if ($old_parent_tid != null) {
// Assign the inner condition group to the outer condition group
$conditionGroup->addConditionGroup($innerConditionGroup);
// Re-cast the inner condition group
$innerConditionGroup = new ConditionGroup('OR');
}
// set the ID tracker
$old_parent_tid = $parent_tid;
}
}
}
// Add the condition to the current condition group
$innerConditionGroup->addCondition($field_name, $term_id, '=');
// Concatenate values for debugging.
// $term_values .= $parent_tid . ' : ' . $term_name . " : " . $term_id . ", ";
}
}
// Add the last inner condition group to the outer condition group if it's not empty
if (!empty($innerConditionGroup->getConditions())) {
$conditionGroup->addConditionGroup($innerConditionGroup);
}
};
// Process both field_my_filter_term_field_one and field_my_filter_term_field_two using our helper function
if (isset($queryParams['field_my_filter_term_field_one']) && is_array($queryParams['field_my_filter_term_field_one'])) {
$process_filter_terms('field_my_filter_term_field_one');
}
if (isset($queryParams['field_my_filter_term_field_two']) && is_array($queryParams['field_my_filter_term_field_two'])) {
$process_filter_terms('field_my_filter_term_field_two');
}
// Set the condition group to the search API query
$search_api_query->addConditionGroup($conditionGroup);
// debugging
// if (isset($queryParams['field_my_filter_term_field_one'])) dpm($queryParams['field_my_filter_term_field_one'], 'Exposed Filter Values');
// if (isset($queryParams['field_my_filter_term_field_two'])) dpm($queryParams['field_my_filter_term_field_two'], 'Exposed MT Filter Values');
// dpm($term_values);
}
// Debug the modified conditions in the Search API query
// dpm($search_api_query->getConditionGroup(), 'Condition Groups in Search API Query');
// Debug the modified search API query object
// dpm($search_api_query);
}
}
Yeah, nested filter groups is definitely something we need.
This has worked for us. Thank you.
Still busted.
To be honest, the work could be combined with https://www.drupal.org/project/views_json_source/issues/3352255 🐛 Exposed filters causes Deprecated function: stripos(): Passing null to parameter #1 ($haystack) of type string is deprecated Needs review
loopy1492 → created an issue.
Rolled a static patch for security reasons. This is also a problem in 2.x, FYI
Thank you @teknocat. I could not figure out for the life of me why lightning_scheduler 3.19 was being reported when we were installing dev-3297525-automated-drupal-10
When I disable the module and cex, all the config disappears as you might expect. Re-enabling the module has produced only one configuration file as you indicated. 3.x does not seem to have the same issue as 2.x.
Thanks for the reply.
I set drupal/security_review to ^3.0 which upgraded as follows: 2.0.2 => 3.0.0-rc2.
drush updb didn't seem to indicate any updates that needed to be run.
I ran drush cr and then drush cex did not indicate any new configuration changes.
The security_review.checks.yml file is still just
{ }
loopy1492 → created an issue.
Ah, nuts. This looks like it's already been suggested but it was in that special place between "open ticket" and "not yet in a full release".
Womp womp.
https://www.drupal.org/project/search404/issues/3320104 🐛 Allow all valid URL characters for custom search path RTBC
loopy1492 → created an issue.
I was having a ton of issues with this on a site and I think I finally tracked down the problem: it was using twig/twig: ^3.
Here is code for a twig FUNCTION that works with twig/twig 2
my_module/src/TwigExtension/MyModuleInputTwigExtension.php:
namespace Drupal\my_module\TwigExtension;
/**
* Custom Twig extension to format my field.
*/
class MyModuleInputTwigExtension extends \Twig_Extension {
/**
* {@inheritdoc}
*/
public function getFunctions() {
return [
new \Twig_SimpleFunction('format_hours_msg', [$this, 'formatMsg'], ['is_safe' => ['html']]),
];
}
/**
* Formats a string for proper output.
*
* @param string $string
* The input string.
*
* @return string
* The formatted string.
*/
public function formatMsg($string) {
// string formatting code for $string
return $string;
}
}
my_module.services.yml:
services:
my_module.function:
class: Drupal\my_module\TwigExtension\MyModuleInputTwigExtension
tags:
- { name: twig.extension }But when I tried to use a similar method with /Twig_SimpleFilter or even /Twig_SimpleFunction and whatnot on the other site, it threw:
Uncaught Error: Class "Twig_Extension" not found in /var/www/docroot/modules/custom/my_module/src/TwigExtension/MyModuleInputTwigExtension
When I removed the /TwigExtension/ from the routing file, it threw:
Service 'my_module.twig_extension' for consumer 'twig' does not implement Twig\Extension\ExtensionInterface.
Here is code for a twig FILTER that works with twig/twig 3:
my_module/src/TwigExtension/MyModuleInputTwigExtension.php:
namespace Drupal\my_module\TwigExtension;
use Twig\Extension\AbstractExtension;
use Twig\TwigFilter;
use Twig\TwigFunction;
class MyModuleTwigExtension extends AbstractExtension {
public function getFilters() {
return [
new TwigFilter('to_https', [$this, 'toHttpsFilter']),
];
}
public function toHttpsFilter($url) {
// Check if the URL starts with 'http:' or 'https:' and replace it with 'https:'
$url = preg_replace('/^(http:|https:)?/', 'https:', $url);
return $url;
}
}
I've also see the return line for getFilters() look like this:
'to_https' => new TwigFilter('to_https', [$this, 'toHttpsFilter']),
my_module.services.yml:
services:
my_module.twig_extension:
class: Drupal\my_module\TwigExtension\MyModuleTwigExtension
tags:
- { name: twig.extension }
Just got it on another site. Need to copy the db to a different environment upstream, and wipe the redirect_404 table before I can download it and use it locally.
We finally got to the bottom of this and it was a weird situation.
We are filling a select2 field on the fly with
$nodeStorage = $this->entityTypeManager->getStorage('node');
$nodeQuery = $nodeStorage->getQuery();
Then it's supposed to filter based on node type...
$custom_node_type_ids = $nodeQuery
->condition('type', 'custom_node_type')
->condition('status', 1)
->sort('created', 'DESC')
->accessCheck()
->execute();
But for some reason, when I debug the output from this function, it returns not only the custom_node_type nodes, but also the node of the current page. The current page is of the "page" content type, but that doesn't seem to matter to the nodeQuery.
I had to add the following:
$my_nodes_ids = $nodeQuery
->condition('type', 'my_nodes')
->condition('status', 1)
->sort('created', 'DESC')
->condition('nid', '4856', '!=')
->accessCheck()
->execute();
After that, my function that was filling the select2 field no longer had null values for the fields it was trying to reference.
I suspect this has always been a problem and Drupal just passed over the null value before, but now it's less forgiving of sloppy code.
At any rate, this is not a priblem with select2 at all.
Thanks! Seems to be working for our site during pipelines ci run. I am adding a patch file from the MR diff for those who would rather use a flat patch file in composer.
I've created a Merge Request for the maintainers to merge and for us to use in our composer.json file.
loopy1492 → made their first commit to this issue’s fork.
I believe this patch should sort out the 3.x branch for Drupal 10.
loopy1492 → made their first commit to this issue’s fork.
So it appears this module has changed significantly between 3.x and 5.x. We have a custom module which uses a file upload field to get csv data and display it using a field preprocess function and a corresponding template.
It appears that the new version has this conversion built in. You just upload the file to the field and it generates your data points for you. This is really cool, but we already have hundreds of nodes and there's no way I can go through and re-upload everything.
I was hoping to use the charts view display and simpy embed the view on the nodes. However, the chart view mode will not accept a file field as a source of data.
Do the maintainers have any suggestions for migrating between 3.x and 5x with so many nodes or are we stuck re-uploading all the csv files?
And that's it. Looking at the charts_api_example in charts 5.x, it seems like that entire process has changed significantly. That means that this module and my custom module will absolutely not work without adjusting the preprocess function to match the new example.
As it turns out, charts 4.x and 5.x do not have this service listed in charts.services.yml. I can't imagine why local is working without it, but I'll have to figure out which service to invoke to make this work.
Yeah, I'm getting this now too. It happened after upgrading from charts 3.x to 5.x, realizing that wasn't going to work, then downgrading to 4.x again. Charts work fine locally, but for some reason, pushing to remote and running updb/cim this wsod occurs.
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "plugin.manager.charts_override". Did you mean one of these: "plugin.manager.charts", "plugin.manager.charts_type", "plugin.manager.archiver"? in Drupal\Component\DependencyInjection\Container->get() (line 157 of /var/www/html/docroot/core/lib/Drupal/Component/DependencyInjection/Container.php).
Gonna try a new cex locally, then push it up and see if that helps.
We have noticed that, if you have multiple video embeds in a WYSIWYG, it does not render the videos; it just displays the CK5 markdown instead.
One video:
Two videos:
I was hoping this issue would solve the problem, but I applied the patch and it does not: https://www.drupal.org/project/video_embed_field/issues/3371353 🐛 VideoEmbedWysiwyg::getValidMatches() does not detect two videos next to each other Needs review
Although I've pushed what I believe are decent changes to the other thread, there are still some diffs between the two. I did this branch from scratch, I've tested it, and it seems to be working for me, so I'm going with this one. Attached please find a new static patch file.
This is a duplicate of https://www.drupal.org/project/webform_scheduled_tasks/issues/3371376 📌 Drupal 10 compatibility Closed: duplicate but I've been using the branch here to figure out what was wrong with that one.
loopy1492 → made their first commit to this issue’s fork.
So, when I downgrade to 4.x, Charts runs the following:
> charts 8302 hook_update_n 8302 - Update existing views to use the new chart settings.
but when I run cex, I'm not seeing any changes to my views config.
loopy1492 → created an issue.
I keep getting this error no matter what I do:
TypeError: Drupal\webform_scheduled_tasks\Plugin\WebformScheduledTasks\Task\EmailedExport::__construct(): Argument #9 ($fileUrlGenerator) must be of type Drupal\webform_scheduled_tasks\Plugin\WebformScheduledTasks\Task\FileUrlGenerator, Drupal\Core\File\FileUrlGenerator given, called in /var/www/docroot/modules/contrib/webform_scheduled_tasks/src/Plugin/WebformScheduledTasks/Task/EmailedExport.php on line 114 in Drupal\webform_scheduled_tasks\Plugin\WebformScheduledTasks\Task\EmailedExport->__construct() (line 91 of /var/www/docroot/modules/contrib/webform_scheduled_tasks/src/Plugin/WebformScheduledTasks/Task/EmailedExport.php).
Someone who actually understands this module is probably going to have to fix this.
I am not entirely sure this is correct, but it seems to have resolved the error:
https://git.drupalcode.org/project/webform_scheduled_tasks/-/merge_reque...
New static patch uploaded.
It looks like a line was accidentally left in on EmailedExportFileDownloadAccessTest. I have removed it.
loopy1492 → made their first commit to this issue’s fork.
Yep. Had the same issue. Had to downgrade to 2.x-dev for our d10 prep story, then switch to 3.0 when we did the actual d10 upgrade.
Well, in the mean-time, thanks for keeping the patches updated @Wouter Waeytens .
loopy1492 → created an issue.
Right on. I've merged my branch into yours. Posting a new patch now for people to use, though they will still need to pin the 3206676-start-a-3.0.x branch in order to disable the ckedior 4 module.
My latest commit removes the composer requirement for ckeditor and adds ckeditor5 as a dependency on the wysiwyg module.
Do note that if you are using blt drupal:sync:default:db during your remote ci run, you will actually need to keep drupal/ckeditor required in the codebase until the next release. I recommend just doing one release with the dependency, then a quck bugfix release with the dependency removed after that is deployed. Ref: https://github.com/acquia/blt/issues/4687