🇨🇦Canada @ydahi

ydahi → created an issue.

Patch works as expected on: Drupal 10.4.4, AI 1.0.5.

It will re-generate on node save - even if no field values are changed.

This, in my use case, is better than no-regeneration at all. As pointed out by others, a full solution will include some sort of check of changed fields before re-gen/no-re-gen.

Side note: I've altered my prompt to attempt to preseve any existing generated content if it's still relevant - this seems to be helping reduce the unexpected behaviour of the entire content changing on edit/save.

ydahi → created an issue.

The new field introduced in the newer h5p editor version is called "Assistive Technologies label". It's in the metadata modal. Screenshot attached.

Here's an inital patch.

ydahi → created an issue.

The merge request adds to the provided patch by also increasing the version requirement of h5/h5p-core in composer.json in order to automatically retrieve a version of \H5PFrameworkInterface that is compatible with the updated H5PDrupal class.

MR26: h5p/h5p-core 1.24.4 is still installing even with bumping the requirement to 1.27 as in this MR. I think this is because the compose.lock is set to 1.24.4.

To circumvent:

cd web/module/contrib/h5p
composer update

This installs h5p-core 1.27 and h5p-editor 1.25

Still a lot more to be done.

One current hang-up is the new metadata field introduce in h5p-core:1.27: a11y_title

Updating to core:1.27 means that existing h5p cannot be saved/updated.

ydahi → created an issue.

I should have been specific.

Let's say I have a field called field_css on a node. The user is meant to input css into this field. 

In the theme, we do something like this:

$custom_css = $node->get('field_css')->getValue();

$variables['#attached']['html_head'][] = [
  [
    '#tag' => 'style',
    '#value' => $custom_css,
    '#weight' => 200,
  ]
];

What's the best way to audit something like so I can rest assured that $custom_css is parsed in a manner that is secure, especially the drupal-way it's implemented here. Or to find out that I should sanatize $custom_css myself in some other way before implementing it in $variables or elsewhere.

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.

ydahi → created an issue.

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?

ydahi → created an issue.

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...

ydahi → created an issue.

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.

ydahi → created an issue.

ydahi → created an issue.

ydahi → created an issue.

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 →

ydahi → created an issue.

split tables

Added initial table

ydahi → created an issue.