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
I got this error recently during an upgrade. I think it happened after BLT 13.7.0 to 13.7.1. I suspect this might have been something that was packaged for a short time along with a composer/blt boilerplate and is now defunct. Removed the reference in composer.json and the file itself.
@jacqui1811 you can use this version for video_embed_field in composer.json:
"drupal/video_embed_field": "dev-3311063-add-support-for",
But you need to do this in your repositories section:
"repositories": {
"drupal": {
"type": "composer",
"url": "https://packages.drupal.org/8",
"exclude": [
"drupal/video_embed_field"
]
},
"drupal/video_embed_field": {
"type": "git",
"url": "https://git.drupalcode.org/issue/video_embed_field-3311063.git"
}
},
Just know that there are some inherent security risks when using WIP dev branches.
Correct @ThomWilhelm. The only way is to use the issue fork which is a bit of a security risk.
https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →
Hmm. This appears to be a thing that happens with all of the embedded elements, not just the video. Very well. This seems to be working within that particular constraint of the editor in general.
There is a checkbox under "Enabled filters" called "Video Embed WYSIWYG". The Video Embed button appears in the "Available Buttons" list even if you don't have this checked. Is this on purpose?
I created a new branch in gitlab which removes all references and dependencies for fakeobjects. The js code is still really full of references to "ck-fake-anchor" and "FakeVisualSelection" and whatnot. I am dubious about pulling at the strings of this myself at the moment. However, the anchor link widget DOES work on Chrome right now using this branch, and it doesn't try pulling in old ckeditor or fakeobjects.
Yeah. The recommended action from CK is to switch to "Custom Widgets" which just SOUNDS like a lot of work. I wonder how necessary the fake links are to this project. I'm worried it's not just a visual thing, but something that's transforming them so they are/aren't clickable in the editor or something. I only have speculation at this pont.
I managed to get this running by using the old method of setting gitlab as a repository in composer and referencing my branch.
So, I noticed that this project still has the old ckeditor 4 module as a dependency and I wondered where that was coming from. It looks like this is still a dependency:
https://www.drupal.org/project/ckeditor_libraries_group →
https://github.com/drupal-ckeditor-libraries-group/div
Who knows if this would still work or if it will ever be updated or even if it is needed anymore.
I really want to help out here, but I need a 2.1.x-dev branch I can point to on drupal.org. All the patches fail against 2.1.0 because there's stuff in 2.1.x which we have to compare to in the MR.
I am not sure why none of the 2.1.0 patches are working. I just downgraded to 2.0 and added this module to drupal-lenient for now.
This needs to be rebased with 2.1 for Drupal 10 compatibility.
Unfortunately, it also looks like fakeobjects isn't even started with their CKEditor 5 conversion. Is this module actually necessary?
https://www.drupal.org/project/fakeobjects/issues/3262037 📌 Plan what's needed for ckeditor 5 in Drupal 9.3+ / Drupal 10 Active
Yup. Just came across this myself when starting a brand new project for the purposes of working on contributing to some modules for the CKEditor 5 upgrade. I needed a totally empty, fresh Drupal site for this work and got this error. Good to know the workaround.
loopy1492 → created an issue.
I'm wondering what one should do if this was done ages ago and you need to stop the error after-the-fact. The process for doing it with modules is well-documented, but not for profiles.
In my .module file in the view preprocess, I did
$view = $variables['view'];
$variables['title'] = $view->getTitle();
And was able to use {{ title }} in my template.
Thanks for this. It seems to be working for me. Would it be possible to roll a new minor version with this patch? I prefer not to pin to dev versions if I can help it. Thanks!
Yeah, the field in the admin page doesn't display for us either. We've recently upgraded from simple_gmap 3.0.1 to dev-3.1.x if that matters.
I actually have noticed that the map does not display when there are no results and you have "Display map when no locations are found" checked. I am running on Drupal 9.5.9, php 8.1.16, and geolocation 3.12. This only just started happening recently; we were on 3.10 so I doubt that had anything to do with it. We did recently upgrade simple_gmap from 3.0.1 to dev-3.1.x but that module isn't a dependency of this one, so that seems weird.
It actually looks like 1.x-dev has already been updated. This is probably a duplicate issue.
After updating a site to Drupal 10, additional issues were revealed that hadn't been reported by rector.
I believe this cropped up becase, at some point, someone on our team ran the update without exporting the configuration. I'm trying to fix it now, but it looks like the version we are running (5.x) no longer has update 8001 in it so I can't run that update with either php-eval "module_load_install('lightning_media_audio'); lightning_media_audio_update_8001;" on d9.5.x or php-eval "\Drupal::moduleHandler()->loadInclude('lightning_media_audio', 'install'); lightning_media_audio_update_8001;" on d10.0.x.
Too bad.
I WAS able to uninstall and reinstall the module to get the correct fields and delete the config for the old ones. But we are lucky that we do not have any media.audio_file content on the site because I suspect if I did this, that content would explode or at the very least the content for the old "audio_file" field would have disappeared and a blank "audio" field would have taken its place.
Yeah. Apparently removing the drupal/captcha line entirely does install whichever version recaptcha actually works with. In my case it was 1.9.0. Hopefully it doesn't introduce whatever errors @donaldp is talking about.
Although the dev version of this module HAS been updated with some of the d10 rector patches, it has set the webform requirement too low. Additionally, there was a minor d10 regression in one of the tests. I have created a MR and a patch for this.
loopy1492 → made their first commit to this issue’s fork.
Either I'm taking crazy pills or downloading 3.x-dev shows as still 8 & 9 compatible. I will have to add this to drupal-lenient for our d10 upgrade.
How is this supposed to get merged if issues are not enabled for this module?
I was going through my list of cdn-served libraries and adding them manually to my composer.json. I figured that the library should be called "ractoon/jquery-text-counter" based on the name of the library in the repo. The library couldn't be found so I hunted down the code including it and here we see that the library needs to be called "ractoon/jquery.textcounter".
"ractoon/jquery.textcounter": "0.9.0",
"jquery.textcounter": {
"type": "package",
"package": {
"name": "ractoon/jquery.textcounter",
"version": "0.9.0",
"type": "drupal-library",
"dist": {
"url": "https://github.com/ractoon/jQuery-Text-Counter/archive/refs/tags/0.9.0.zip",
"type": "zip"
}
}
},
it looks like this is being fixed as a part of https://www.drupal.org/project/view_mode_page/issues/3300706 🐛 Context exception when trying to create url (Drupal 10 is broken!) RTBC
For some reason I keep uploading patches that start with a space in the file name.