🇺🇸United States @earthday47

earthday47 → changed the visibility of the branch 3.x to hidden.

earthday47 → created an issue. See original summary → .

You got it! I just pushed up another small fix after more testing. Hopefully that will do it.

During testing I found that the import fails if the value is empty/blank. So I added a check for non-null to the plugin.

earthday47 → made their first commit to this issue’s fork.

earthday47 → created an issue.

Thanks for all the work on this! On a site with MR 3 applied I am getting an error from CertificateMappingsInlineEntityForm for the createInstance declaration. The injected services don't match up.

Instead of adding all of EntityInlineForm's injected services, I switched to the webform style of calling parent::createInstance to prevent having to modify this later. Pushed a commit.

earthday47 → made their first commit to this issue’s fork.

earthday47 → created an issue.

@aaron.feris Thanks for the patch! I'll incorporate in the next release.

wjackson → credited earthday47 → .

I'm happy to help and supply a patch! I added MR 6 which converts State into configuration. I've also attached a patchfile to this project.

Note that in this patch I've saved all the domain-specific configuration into the same domain_login_restrict.settings configuration object. Ideally, these config would be saved as 3rd party settings on the domain entities, but that's something that could be tackled in a future update.

I checked and the block is placed using the default block layout. But the patch will work for in the short term.
If I have more information I'll definitely update! Thanks for your quick responses!

Here's my patch attempt.

Here's some more details I can provide -

• The error was triggered on entity of type "block_content"
• It is a custom block type with only a body field. There were no customizations made to any other view modes so this would be trying to use the 'default' view mode.
• This site, and this block content, was upgraded from Drupal 8->9->10.

So it's possible this is a migration issue?

earthday47 → created an issue.

Hello, after working to customize the way quiz questions and results are templated and styled, I would strongly suggest using theme functions to render the final output of the quiz elements. Especially the results pages are hard to theme.

For example, I have overridden the QuizResultAnswerViewBuilder alterBuild() method and, along with some custom logic, returned this at the very end:

    $build['quiz_result_answer'] = [
      '#theme' => 'MYMODULE_quiz_result_answer',
      '#question' => $question_render,
      '#rows' => $rows,
      '#result_meta' => $result_meta,
    ];

    return $build;
  }

Even simpler, some of the controller methods I just wrapped the output in a theme function:

namespace Drupal\MYMODULE_quiz_customizations\Controller;

use Drupal\quiz\Controller\QuizQuestionController as OriginalQuizQuestionController;
use Drupal\quiz\Entity\Quiz;

class QuizQuestionController extends OriginalQuizQuestionController {

  /**
   * {@inheritdoc}
   */
  function feedback(Quiz $quiz, $question_number) {
    $page = parent::feedback($quiz, $question_number);
    return [
      '#theme' => 'MYMODULE_quiz_question_feedback',
      '#content' => $page['body'],
    ];
  }

  /**
   * {@inheritdoc}
   */
  function take(Quiz $quiz, $question_number) {
    $content = parent::take($quiz, $question_number);
    return [
       '#theme' => 'MYMODULE_quiz_question_take',
       '#content' => $content,
    ];
  }

}

This let me add wrappers around the actual question component in a template file.

I can upload a patch if you would like to see more specifically what I'm proposing.

Here's a patch that removes it from queries.

earthday47 → created an issue.

@fromme thanks for the merge! Yeah select all is a better experience, my form in the patch is overwhelming (site I'm using this on has 20+ roles)

In a perfect world, there would be tests for this!

earthday47 → created an issue. See original summary → .

@rkoller I recreated the Edge + high contrast mode testing environment, however I found that when I combined "Enable automatic dark mode" + forced-colors the borders and spinner become a gray tone... but without "automatic dark mode" it doesn't happen. And any attempt at overriding with CSS was unsuccessful. This will need a closer look.

We've got the dark mode task, but also opened a new issue for high contrast. https://www.drupal.org/project/project_browser/issues/3368315 📌 Make work with dark mode, high-contrast, forced-colors Active

MR is rebased, so with that new task I'm hoping we can get this task reviewed and approved.

Re 3 -
> for RTL the spinner is still centered with the pre patch styling. the changes in the MR are only available for LTR.

I wasn't able to reproduce this one... test again using the newly rebased branch?

earthday47 → created an issue.

I created a fork/merge request which includes the patch in #3 (core_version_requirement) and the automated fixes in #4.

earthday47 → made their first commit to this issue’s fork.

I've rerolled the patch for the 1.2 version because I need it for Drupal 10!

I needed to reroll the patch in #20 for 1.0-rc7. I made a couple of code formatting tweaks but left the logic alone - there are some things in there that are a little unusual, goto and while(1==1) , that make it a little hard to follow. It probably needs a little more work.

Patch version of the merge request at this point (as this feature may change a bit in the future).

Will have to work on tests later - any help in that department is appreciated!

Refactored the way we return messages from package manager to return errors and non-errors (warnings). If there are any errors, prevent installs and show the heading "Unable to download modules via the UI". If there are any warnings, we print them without a header.

I've added some screenshots of the various scenarios we could get if there are multiple messages. Chris informed me that we're unlikely to get both because of the way Package Manager works, regardless, the styles are in there just in case this happens.

We want to print warnings

Fix in place.
Does this need a test?
Also - do we want to print warnings still? At the moment this is suppressing them.

Hi all! Catching up on this issue's history, I do see that we wanted to have the top region clickable for accessibility reasons. I didn't want our work from yesterday to invalidate all of this useful work, so I rebased the 2nd-to-last MR/branch.

So we have a couple options... the a wrapping the Image element, which would create two anchors to tab through, or the original approach creating a click event/action on the wrapping div.

earthday47 → made their first commit to this issue’s fork.

@kroller thanks so much for testing!

1. I agree that having it left aligned to the max width of the button area would be better, but would also introduce extra white space that may look off.
Left aligning the throbber is how I've seen it used in other places for Ajax links so I think that would be consisten with other experiences.
One option is to move it above the text, right-aligned. (Breaks convention?)
Another option is to animate the width of the text so it more smoothly resizes. Might be the lowest friction option

2. I will make some style updates for high contrast mode (possibly related indirectly to work in #3364776)

Happy to report that I have a merge request in place to address this. The throbber was already in the right container, it just needed to have some classes and styles adjusted.

Attached is how it's looking. I don't have package manager working all 100% yet but the GIF shows it stepping through most of the states.

earthday47 → created an issue.

I determined that this is an issue with how the previous links are checked. In menuPagerGetNavigation() and menuPagerFlattenTree() it's returning the full menu tree, which means checking previous will only check the previous item in the flattened tree. Which in my scenario would be "Grandchild 3".

So here's a patch! It pulls the menu restricting by the parent as the root and max depth = 1, meaning the flattened tree will only contain siblings. Works good on my local environment/scenario.

earthday47 → created an issue. See original summary → .

^ with core_version_requirement.

Same changes but with core_version_requirement bump.

earthday47 → created an issue.

Created fork with the automated fixes, added core_version_requirement.

earthday47 → made their first commit to this issue’s fork.

I'm working on upgrading a website to D10 with Value installed. D10 has upgraded to Twig 3 which includes a number of deprecations:
https://twig.symfony.com/doc/2.x/deprecated.html

This patch file makes the changes for Twig_Extension, Twig_SimpleFilter, and Twig_SimpleFunction.

I still have an issue, but it's the other way around - now views_contextual_filters_or is applying the OR to the parent condition, and overriding all other conditions.

For example, if I have Location as a single select, and Type as a multi-select, once I select a value for Type it will ignore Location and show results for all Locations.

Happy to elaborate with examples to help resolve.

Committed last patch to 3.0.x.
The previous patches are still available if you were using that method.

Looks good

This is a duplicate of https://www.drupal.org/project/flickity/issues/3203820 🐛 No link template "canonical" found for flickity_group entity type Fixed

MR merged, this will go out in the next release :)

Updated approach to add a `file_default` setting. All Files might want to be grouped in "Documents", for example.

Here's a patch for a feature change that allows customizing the File datasource (file entity) MIME type. These will be grouped with nodes with the same label. And put in "Other".

This solves for a specific use case (File entities) but long-term would like a more general solution.

(I need this too)
Until a new release gets cut, you can add the MR as a diff in composer patches: https://git.drupalcode.org/project/search_api_tracking/-/merge_requests/...

Or, GitLab always has the dev branches available, so you can either download it from the repository or target 1.0.x in composer.json by using: `"drupal/search_api_tracking": "dev-1.0.x"

earthday47 → created an issue.

https://docs.google.com/document/d/1V-FOmgVswAC6JgRwTFgoXYrhwmIkuXZMJlvL...

earthday47 → created an issue.

earthday47 → created an issue. See original summary → .

earthday47 → created an issue.

@DamienMcKenna here's an updated patch that includes unit tests for explode().
Based on my understanding, that covers it, but let me know if I should include any more!

@DamienMcKenna hello! I can work on some tests. I've done exactly 1 core test so be patient :)