🇺🇸United States @robpowell

For whatever it is worth, I could not simply add the conflict step in #2 and it just work. Composer gave me the following error

Problem 1
- my/project is present at version dev-main and cannot be modified by Composer
- my/project dev-main conflicts with symfony/event-dispatcher v6.4.8.
- symfony/event-dispatcher is locked to version v6.4.8 and an update of this package was not requested.

To get around this I did the following

1. composer require "symfony/yaml":"6.4.8" "symfony/validator":"6.4.7" "symfony/string":"6.4.7" "symfony/serializer":"6.4.7" "symfony/psr-http-message-bridge":"6.4.7" "symfony/process":"6.4.7" "symfony/mime":"6.4.7" "symfony/mailer":"6.4.7" "symfony/intl":"6.4.7" "symfony/http-kernel":"6.4.7" "symfony/http-foundation":"6.4.7" "symfony/error-handler":"6.4.7" "symfony/dependency-injection":"6.4.7" "symfony/console":"6.4.7" "symfony/config":"6.4.7" "symfony/cache":"6.4.7" "symfony/var-exporter":"6.4.7" "symfony/var-dumper":"6.4.7" "symfony/routing":"6.4.7" "symfony/framework-bundle":"6.4.7" "symfony/finder":"6.4.7" "symfony/filesystem":"6.4.7" "symfony/event-dispatcher":"6.4.7"
2. added conflicts to composer.json in #2
3. run composer update --lock
4. remove newly defined symfony dependencies from composer.json
5. rerun composer update --lock

Regarding the upstream PR, it looks like it was merged in and is on the 6.4 branch. Based off a comment in the duplicate GH issue, releases are approximately monthly and should be coming out soon.

This is happening to me on deployments in Acquia. After a full cache rebuild, via drush and the Acquia UI, the issue is resolved.

fixed, thanks!

I ran this in d10 and using mailhog to test and it worked. Keep in mind, if you select the "disable the site email address" you will not have a to value and all emails will go out as bcc.

robpowell → created an issue.

robpowell → created an issue.

robpowell → created an issue.

Just echoing some of the concerns raised here, having a CR would have been helpful to know about this change quicker. Having this off by default and configurable in the UI would be beneficial incase there are clashes with custom code or contrib like multiple_fields_remove_button.

#6 does the following

When results are empty (they can be with a date range facet), this throws a fatal error. This should be preceded by a check to make sure $results is not empty.

Rather than get the url parameters from the facet which can return no results, I changed the logic to use the current request. This allows us to show facet summary regardless if there are no results or not.

I changed the logic on string replace to match the new format.

  $pattern = '/min:\d+/';
                  $replacement = 'min:';
                  $clear_set_min_date = preg_replace($pattern, $replacement, $filter);

Added a label to the facet summary "pills"

 $min_label = $facet_instance->getWidget()['config']['min_label'];
                  $value = Markup::create('<strong>' . $this->t($min_label) . '</strong>: ' . gmdate($this->getConfiguration()['date_format'], $min));
                  $item = [
                    '#theme' => 'facets_result_item__summary',
                    '#value' => $value,

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

I wasn't able to get the patch to apply but I did add it as a custom facet processor manually. One item to note, this is a post_query processor and because of that it may not play nice with other build processors. For example, on my site we have hierarchical facets and after adding always show active to the hierarchical facet renders the active item outside of their expected hierarchy.

Expected Result for active item grandchild

• Facet one
  • Parent
    • child
      • [X] grandchild

Actual Result

• Facet one
  • [x] grandchild
  • Parent
    • child

Is there a way for the active item to be in its expected hierarchy?

I found myself in this exact situation due to rendering the summary via a block. The block was added via a attach render entity in the view's header. Once I changed this to the view's facet summary, the facet summary populated even if the selection rendered a no result.

robpowell → created an issue.

I'll add that I agree with the OP and this is how I expected it to work. Ignoring config should do just that, ignore them fully. In terms of a patch approach to provide this functionality, we could have a config option that a user could opt in to fully ignore the config.

This is also an issue with the form tool tip

robpowell → created an issue.

robpowell → created an issue.

@wolf_22 try this approach https://www.drupal.org/docs/develop/using-composer/using-drupals-lenient... →

A duplicate was flagged but not linked to. I've searched the queue and don't see an active ticket for co maintainer access. It has been 7 years since a d8 version of this module was created but there is still no d8 support on the project page. We now have d9 EOL and still need d10 support to keep this module going fwd.

robpowell → created an issue.

robpowell → created an issue.

Hopefully this is a dup and there's a patch already in the works but if not I can roll one. I just need to know where to inject the token service.

robpowell → created an issue.

robpowell → created an issue.

my summary is on this ticket https://www.drupal.org/project/migration_tools/issues/3374732 📌 Why doesn't this module have a dependency to QueryPath? Active

TLDR;

because gravityPDF's version of the library has in its composer.json a replace for the library that is out of date, all we have to do is require this library in our project:

drush require gravitypdf/querypath -w

Without 8.1 support arthurkushman/querypath fails on exceptions because they have required exception args that are no longer required in php 8. This will make debugging any QP errors impossible and we should think about updating to a maintained library.

I ran into this while working in the migration_tools custom migration. It turned out that the HTML I was parsing had two elements with the same id. Because the library doesn't support php 8 I wasn't able to get this information without hacking the exception as it is wrapped/consumed by the subsequent ArgumentCountError exception:

ArgumentCountError: Too few arguments to function QueryPath\ParseException::initializeFromError(), 4 passed and exactly 5 expected in QueryPath\ParseException::initializeFromError() (line 45 of /var/www/html/vendor/arthurkushman/query-path/src/ParseException.php) #0 [internal function]: QueryPath\ParseException::initializeFromError(2, 'DOMDocument::lo...', '/var/www/html/v...', 209)
#1 /var/www/html/vendor/arthurkushman/query-path/src/DOM.php(209): DOMDocument->loadHTML('\xEF\xBB\xBF #2 /var/www/html/vendor/arthurkushman/query-path/src/DOM.php(140): QueryPath\DOM->parseXMLString('\xEF\xBB\xBF #3 /var/www/html/vendor/arthurkushman/query-path/src/QueryPath.php(191): QueryPath\DOM->__construct('\xEF\xBB\xBF #4 /var/www/html/vendor/arthurkushman/query-path/src/qp_functions.php(157): QueryPath\QueryPath::with('\xEF\xBB\xBF

• PHP.net error context
• QP Fix

@slucero and spoke in slack and he pointed out that because gravityPDF's version of the library has in its composer.json a replace for the library that is out of date, all we have to do is require this library in our project:

drush require gravitypdf/querypath -w

robpowell → created an issue.

robpowell → created an issue.

robpowell → created an issue.

I tested this as a view,

robpowell → created an issue.

I updated media_library_edit-3316163 with latest 3.x changes, gin fixes in #14 and a typo in render array 'attached' vs '#attached'.

To test I did the following:

1. translated a node
2. on the edit page for that node I went to the media field. For each media that didn't have a translation, there was a button to translate
3. clicking the "translate" button shows a modal and allows for editing the translation.
4. saving the node and inspecting the image shows the translated translation
5. reviewing the entity at /admin/content/media confirms that there is a translation

Note: On Gin theme the dropdown button active state looks a bit off:

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

Here is the UI change:

The debugging steps in this issue where really helpful, thanks. I identified that I had this problem on both widgets and after a bit of debugging realized that in the fields settings you have to set the allowed display modes. I've opened a new issue https://www.drupal.org/project/viewsreference/issues/3357451 ✨ There is no display available. Please select another view or change the field settings. Needs review

robpowell → created an issue.

Looks like this issue is related to realname/src/Controller/RealnameAutocompleteController.php

 /** @var \Drupal\user\Entity\User $account */
    foreach ($accounts as $account) {
      $matches[] = [
        'value' => $this->t('@realname (@id)',
                [
                  '@realname' => $account->getDisplayName(),
                  '@id' => $account->id(),
                ]),
        'label' => $this->t('@realname (@username)',
                 [
                   '@realname' => $account->getDisplayName(),
                   '@username' => $account->getAccountName(),
                 ]),
      ];
    }

t() will escape special characters. It looks like we could leverage some of the code from the controller this overrides core/lib/Drupal/Core/Entity/EntityAutocompleteMatcher.php

// Loop through the entities and convert them into autocomplete output.
      foreach ($entity_labels as $values) {
        foreach ($values as $entity_id => $label) {
          $key = "$label ($entity_id)";
          // Strip things like starting/trailing white spaces, line breaks and
          // tags.
          $key = preg_replace('/\s\s+/', ' ', str_replace("\n", '', trim(Html::decodeEntities(strip_tags($key)))));
          // Names containing commas or quotes must be wrapped in quotes.
          $key = Tags::encode($key);
          $matches[] = ['value' => $key, 'label' => $label];
        }
      }

robpowell → created an issue.

How about we go with matching anything between the prefix and suffix? This change in essence makes the pattern (?:\[~)([^\]]+)\].

This will match periods, hyphens and spaces.

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

I've gone ahead and created a submodule, environment_indicator_block. If the maintainers rather this as a separate module please let me know.

One outstanding question, I am managing my indicator values through hardcoding them in the settings file:

# Site environment
$config['environment_indicator.indicator']['name'] = 'LOCAL';
$config['environment_indicator.indicator']['bg_color'] = '#8A1350';
$config['environment_indicator.indicator']['fg_color'] = '#FFFFFF';

For my setup, it doesn't seem like I need to add any cacheable metadata to the block because it will require a cache rebuild to get the overrides, right? What would be a good way to future proof it a bit?

Here are some screenshots of the block in action

robpowell → created an issue.

robpowell → created an issue.

robpowell → created an issue. See original summary → .