Which line is failing?
When I'm using the issue fork directly in my composer file to load, it seems to work.
A d10 release would be great indeed. It's only a matter of changing the core_requirements and we're good to go.
This issue is introduced again with facets dev-3.0.x, using facets exposed filters, search_api 1.34.0 and views_bulk_operations 4.2.6 in Drupal 10.2.5
I've updated the patch for the combination of this versions.
I've fixed the failing test. It didn't include the hostnames.
kensae → created an issue.
kensae → changed the visibility of the branch 3241153-move-helper-functions to hidden.
This would be very useful to extend ckeditor: for example to implement the 'Balloon editor' in a custom module.
kensae → made their first commit to this issue’s fork.
kensae → created an issue.
Problem #2 is caused by the fact I'm rendering the view with twig_tweak's function drupal_view, which calls the views_embed_view function. Because currently the SearchApiDisplay is searching for arguments on the url or the from the arguments in the ajax request, the argument set directly in views_embed_view are being ignored.
I've managed to get the original contextual arguments from the 'old_view' array from the ViewExecutable object. It seems a little dirty to me, but for now, it does the trick.
Unfortunately my changes do not work, because set arguments are being overwritten again in ViewsBlock plugin
kensae → created an issue.
I've tested this patch with Facets 3.0.x-dev and better exposed filters 6.0.3 in an ajax enabled view, and it works for me.
I can confirm the patch in #9 🐛 CKEditor 5 balloons invisible when CKEditor 5 is used inside a modal Needs work works for me and typing is possible. This patch also solves the following issue for me: https://www.drupal.org/project/drupal/issues/3351603 🐛 CKEditor 5 link broken in Dialog if another CKEditor exists Needs work
The patch in #134 failed for Drupal 10.2 on the media.routing.yml file, so I've adapted the patch slightly.
I've tested the merge request in #2 and it works for our use case.
Instead of using the patching the 2.x-dev version, I've added the issue fork repository in my composer.json. Patching doesn't work because composer is checking the version requirements before the patch is applied.
I've added the check suggested in #66
I guess this issue can be closed because the changes are targeted in the 3.0.x-dev branch to avoid confusion?
I've accidentally opened an issue fork for this issue because I didn't care to look at the 3.0.x-dev branch myself.
I guess it would be better to keep both issues separated and remove the changes for the Mollie for Drupal Webform submodule in this patch?
I wonder If we should even include patches for Mollie for Ubercart and Mollie for Drupal - Customers API or move them to separate issues?
Would it be possible to move this changes into a new release?
I'm using Drupal 10.1.4
I think we should reopen this issue, because it generates the following error: Error: Class "Drupal\migrate_tools\Commands\MigrateToolsCommands" not found in include() (line 27 of /app/www/modules/contrib/path_redirect_import/src/Commands/PathRedirectImportCommands.php) #0 /app/vendor/composer/ClassLoader.php(571): include()
The solution to this is to change
use Drupal\migrate_tools\Commands\MigrateToolsCommands;
to
use Drupal\migrate_tools\Drush\MigrateToolsCommands;
in PathRedirectImportCommands
This configuration works for me:
$settings['cache']['default'] = 'cache.backend.file_system';
$settings['cache']['bins']['config'] = 'cache.backend.database';
$settings['cache']['bins']['discovery'] = 'cache.backend.database';
$settings['cache']['bins']['bootstrap'] = 'cache.backend.database';
$settings['cache']['bins']['data'] = 'cache.backend.database';
$settings['filecache']['directory']['default'] = '/app/private/filecache';I've created a patch from the issue fork. I had to remove the changes from the .info.yml file, because they caused the patch to fail because of the following issue: https://www.drupal.org/project/drupalorg/issues/3066468 📌 Packaging info from .info.yml often creates conflicts when patching (ddo) Active
This issue was cause by a custom form_alter we used in a specific project. So we can close this issue.
Can we merge this with the dev branch?
I agree, and I've changed the code.