I can confirm that I am seeing the same error for a filter format that doesn't have markdown enabled.
Effects 10.3.0 onwards following the addition of the Constraint Validator in Drupal 10.3.
Using Markdown 3.0.1.
I've updated this to fix the drush error, there's a new release 3.1.3 with these changes.
I've created a new release, so that it's clearer that the drush version of 12.5.2 is required for the autowiring to work. Hopefully this fixes the above issue.
Thanks for reporting the issue, i'm having trouble replicating the issue, as I'm not seeing the issue on a new install using Drupal 10.2.6 with Drush 12.5.2 installed. So please give a little more information, about which versions of Drupal and Drush are causing this conflict.
I wonder if drush, or a dependency needs updating following updating core or modules.
You could try running the following to see if this fixes the issue:
composer update drush/drush -W
If the above does, then I possibly need to update the project composer files, to ensure the correct version of drush is available to allow the autowiring.
A partial upgrade path is now available in the 3.1.x branch.
There is a listing page (/admin/config/development/http-client-error-status) of all the blocks using this modules plugin for block visibility, allowing for manual configuration to swap from this module to core.
There are also Drush commands that provide a list and to update existing blocks to use core block visibility for request status code.
Please note that only 403, 404 and 200 status codes are catered for.
For those of you experiencing this issue when using lando with the pantheon plugin, there has been an issue raised regarding this:
https://github.com/lando/pantheon/issues/156
Please provide any further information on that issue, which might help to figure out the issue is.
Patch supplied.
jefflogan → created an issue.
Drupal 10.2 now allows for setting Block visibility for the status codes 200, 403, and 404. So for most users they should be able to move to using core. However, this module can safely run along side core's implementation.
The only exception is that the status code 401 isn't provided for, but that probably isn't being used by most people.
Once you configured all your blocks to use Drupal core, instead of this module, it is safe to uninstall this module.
I have added a block listing of all blocks that are using the Block condition provided by this module. This can be found under Configuration > Development > HTTP Client Error Status Block Listing (or /admin/config/development/http-client-error-status ).
Thanks for the patch, this fixed my issue with the broken pager on ajax views.
+1 RTBC
Yes, I've tested this properly now. Drupal 10 does not require the accessCheck on these types of entities. Apologies for adding the unnecessary commits.
However, I can confirm the original commits to remove the core key and update the core_version_requirements key is enough to get this working in Drupal 10. So it's a +1 from me.
I've updated this to include an access check on the entity queries, as I believe Drupal 10 now requires this, having been deprecated in D9.2. This came up in as flagged. I originally thought the accessCheck only applied to content, such as nodes.
jefflogan → made their first commit to this issue’s fork.
I had the same issue with the latest version (currently 8.x-3.4) not checking if the method exists.
Error: Call to undefined method Drupal\views_contextual_filters_or\Plugin\views\query\ExtendedSearchApiQuery::getTableQueue() in civicrm_entity_views_query_alter() (line 509 of /web/modules/contrib/civicrm_entity/civicrm_entity.module)
I've done a re-roll of the patch based on the current dev branch 8.x-3.x.
Github pull request:
https://github.com/eileenmcnaughton/civicrm_entity/pull/410