grndlvl → created an issue.
grndlvl → created an issue.
The modules enables on d11 as expected, however, I am experiencing the following issues:
Uncaught ReferenceError: jQuery is not defined
<anonymous> http://d11.lndo.site/sites/default/files/js/js_Xd1puIsME9fd99Odj3PMV7hoXuNVXiOvZUW91PdEmVA.js?scope=footer&delta=2&language=en&theme=olivero&include=eJzLz8ksSy3K10_PyU9KzNEtLqnMycxL1yktTi0qzkss0IcxdPKhCotTE4uSM3TLM1NSAdmDF7w:2
js_Xd1puIsME9fd99Odj3PMV7hoXuNVXiOvZUW91PdEmVA.js:2:2
<anonymous> http://d11.lndo.site/sites/default/files/js/js_Xd1puIsME9fd99Odj3PMV7hoXuNVXiOvZUW91PdEmVA.js?scope=footer&delta=2&language=en&theme=olivero&include=eJzLz8ksSy3K10_PyU9KzNEtLqnMycxL1yktTi0qzkss0IcxdPKhCotTE4uSM3TLM1NSAdmDF7w:2
and
Loading widget failed: evaluating `window.onUsersnapLoad` resulted in error TypeError: window[n] is not a function
<anonymous> http://widget.usersnap.com/global/load/cf8d05a6-6310-4c99-8a4a-f9c213e19e6e?onload=onUsersnapLoad:1
This is already handled by the "Access Usersnap" permission.
Fixed as part of 🐛 Drupal 10 support. Fixed .
Fixed as part of 🐛 Drupal 10 support. Fixed .
Fixed as part of 🐛 Drupal 10 support. Fixed .
grndlvl → created an issue.
I cannot recall what this was for off hand. Closing.
Neither do I... sorry :(
Back to me forgot to move $field_settings up
This is caused by a bug in core https://www.drupal.org/project/drupal/issues/3403999 🐛 Exposed filter values ignored when using batch Needs work update to Drupal 10.2.2
Oh I see now. Yes sadly, this is the default behavior of node_access controls in Drupal core. Typically node access modules do 1 or two things they either "ignore" (which means somebody else will be handling) OR access is "granted", but never revoked.
A user only needs 1 module to grant access to a node.
A user only needs 1 module to deny access to a module.
This is why it's generally discouraged to not use too many overlapping node_access control modules as it will give unexpected results. You'll need to integrate the two together you may check out https://www.drupal.org/project/acb → . I have never used this one myself, but it certainly sounds like the behavior you are after:
It should be noted however that you should be well aware about the settings of each of the enabled access control modules since access will only be granted if all modules controlling access to a specific node explicitly allow it.
E.g if a node is controlled by Content Access and Workflow and the node should only be visible for anonymous users at a specific workflow state, you should grant anonymous users view permission in Content Access as this is further modulated by Workflow!
Feel free to reach out if you need additional assistance.
Tagged and deployed! Sorry for the delay!
@justcaldwell Thanks for the nudge! Completely forgot. Sorry for the delay there has now been a d10 compatiable release. Let me know if you're still interested in co-maintainer. The current co-maintainers and myself took it over when it sat abandoned after a security vulnerability.
Could you provide steps for an example?
Sorry for the delay. I looked over the d10 compatibility work and it's simple enough and was already merged. I went ahead and created a release.
Thanks all -- will be included in the next release.
Issue with duplicate arguments in creation causing:
Message TypeError: Drupal\entity_reference_facet_link\Plugin\Field\FieldFormatter\EntityReferenceFacetFormatterBase::__construct(): Argument #10 ($module_handler) must be of type Drupal\Core\Extension\ModuleHandler, Drupal\facets\UrlProcessor\UrlProcessorPluginManager given, called in /.../modules/contrib/entity_reference_facet_link/src/Plugin/Field/FieldFormatter/EntityReferenceFacetFormatterBase.php on line 109 in Drupal\entity_reference_facet_link\Plugin\Field\FieldFormatter\EntityReferenceFacetFormatterBase->__construct() (line 85 of /app/docroot/modules/contrib/entity_reference_facet_link/src/Plugin/Field/FieldFormatter/EntityReferenceFacetFormatterBase.php)
Please ignore -- needed patch against beta7 until we update.
quietone → credited grndlvl → .