Thanks @chOP, I followed your formula and was able to find the correct views config to remove.
Patch in #20 applied to 10.2.6 and helped me get out of this mess.
Bumping.
Same goals as outlined by others: I'd like to place the Fivestar field within a "Global: Custom text" field so that I can better control the layout/look-and-feel of my view.
However, the fivestar field gets parsed by `filter_xss_admin`, so the fivestar widget gets stripped of most of its functionality and just text remains:
`Give it 1/5Give it 2/5Give it 3/5Give it 4/5Give it 5/5`
I'm currently getting around this by using Views Unrestricted Custom Field module → , but I would like to see this issue patched on the Fivestar module itself.
I was able to get this work, solution shared below.
My Groups have a field called Style (term ref) and Subject (term ref). When a Group is created, these fields are selected. I add these fields as CSS classes (or data attributes) in page.html.twig, allowing me to write custom styles per "Style" or "Subject" selected.
The following hook_preprocess_page implementation adds those classes to the Group and Group nodes.
function yourtheme_preprocess_page(&$variables) {
if (($group = \Drupal::routeMatch()->getParameter('group'))) {
$variables['group']['id'] = $group->id();
$variables['group']['type'] = $group->getGroupType()->id();
$styles = $group->get('field_style')->referencedEntities();
foreach ($styles as $style) {
$name = $style->getName();
$variables['group']['style'] = $name;
}
$subjects = $group->get('field_subject')->referencedEntities();
foreach ($subjects as $subject) {
$name = $subject->getName();
$variables['group']['subject'] = $name;
}
// Print entire Group object for testing
//$variables['group']['object'] = $group;
}
if (($node = \Drupal::routeMatch()->getParameter('node'))) {
if ($variables['node']->getType() === 'page') {
$node_id = $variables['node']->id();
$storage = \Drupal::entityTypeManager()->getStorage('group_relationship');
assert($storage instanceof GroupRelationshipStorageInterface);
$group_relationship = $storage->loadByEntity($node);
assert($group_relationship instanceof GroupRelationshipInterface);
foreach ($storage->loadByEntity($variables['node']) as $group_content) {
//$variables['group']['group'] = $group_content->getGroup();
$variables['group']['id'] = $group_content->getGroup()->id();
$variables['group']['type'] = $group_content->getGroupType()->id();
$styles = $group_content->getGroup()->get('field_style')->referencedEntities();
foreach ($styles as $style) {
$name = $style->getName();
$variables['group']['style'] = $name;
}
$subjects = $group_content->getGroup()->get('field_subject')->referencedEntities();
foreach ($subjects as $subject) {
$name = $subject->getName();
$variables['group']['subject'] = $name;
}
}
//dump($variables);
}
}
}
This is how I'm pursuing adding the same sort of attributes to nodes within the group context:
if (($node = \Drupal::routeMatch()->getParameter('node'))) {
if ($variables['node']->getType() === 'page') {
dump($node);
$node_id = $variables['node']->id();
$storage = \Drupal::entityTypeManager()->getStorage('group_relationship');
$group = $storage->loadByEntity($node);
}
}
But, I need to figure out how to load the group entity from the group_relationship now. Or maybe there is another way.
I was able to get Group ID (and other data) into my template like so:
In theme.theme:
function theme_preprocess_page(&$variables) {
if (($group = \Drupal::routeMatch()->getParameter('group'))) {
$variables['group']['id'] = $group->id();
$variables['group']['type'] = $group->getGroupType()->id();
$styles = $group->get('field_style')->referencedEntities();
foreach ($styles as $style) {
$name = $style->getName();
$variables['group']['style'] = $name;
}
$subjects = $group->get('field_subject')->referencedEntities();
foreach ($subjects as $subject) {
$name = $subject->getName();
$variables['group']['subject'] = $name;
}
// Print entire Group object for testing
//$variables['group']['object'] = $group;
}
In page--group.html.twig:
{% if group.id %}
{% set data_id = group.id %}
{% set data_type = group.type %}
{% set data_style = "#{ group.style |lower }" %}
{% endif %}
<div
data-courseid="{{ data_id }}"
data-coursetype="{{ data_type }}"
data-coursestyle="{{ data_style }}"
{{ page_attributes.addClass(page_classes)
}}>
However, now I am wondering the best approach to getting the same data attributes (or classes) in a node that is part of a group.
The following does not work:
if (($group_relationship = \Drupal::routeMatch()->getParameter('group_relationship'))) {
dump($group_relationship);
}
Any suggestions?
New patch makes it possible to create views filter using checkbox or select (e.g. instead of textfield).
+1 for patch in #25
Drupal 9.5.11 upgrade path using Update Status.
This patch adds an option to the field widget that lets them specify the url arguments using a token that will be based to the view to populate the contextual filter.
For example: tested with Group module to pass Group ID to view to contextually filter for group nodes.
Patch incoming...
I can confirm that this fork works on Group 3.x. +RTBC and would appreciate this being part of the next release.
Tested with:
- Group 3.2.1
- Drupal 10.1.6
Test passed:
- Clone a Group
- Clone a Group and it's nodes
Needs testing:
- Clone a clone of a group
- Clone a group with group media enabled
- Clone without batch
Thank you, this seems like the most sane approach in Drupal 10.
Hi msnassar,
Thanks for responding and for the clarifications.
An ideal solution has these two features:
1. I can only select media shared in the group when using Gutenberg editor.
2. When I upload media using the Gutenberg editor, it is added to the Group that the node belongs to.
Also, users can be associated with multiple groups.
If you think this is feasible, I'll reach out via contact form to try and schedule some time with you to discuss funding a separate contrib module for this feature.
I'll add another case study for this setup here. I'll also acknowledge that we may be talking edge cases and possibly out of scope for the core passwordless module. However, this module is one of the very few ways to achieve a more simplified login process.
Problem: I have two roles within the site that both require varying levels of privacy, technical ability, and stake in the process. The "authors" on the site need to use the site frequently and perform high-level administrative work. While the "readers" simply need a session to track their reading progress and private information and do not login often enough to warrent a full account.
Examples:
1. Medical Staff (authors) and Patients (readers)
2. Teachers (authors) and Students (readers)
3. Hiring Managers (authors) and Potential Employees (readers)
Especially in case #2: it makes a lot of sense to make the Students login process simple (passwordless), while making the Teachers login/register process more involved (password + 2FA)
Opportunity: Let this module operate in a mixed mode which includes:
* two (or more?) separate login/register routes
* a default role per route
Possible modules that can be involved in this process:
*
Webform User Register →
*
Registration Type →
*
Social Auth →