🇩🇪Germany @captain hindsight

Hey, thanks for this improvement. I needed a redirect from one query parameter to another, i.e from \?foo=(?P<foo>[0-9a-z]+) to ?bar=<foo>.

With the MR the redirect happens, but the named value is not replaced. I guess this is because $redirect->getRedirectUrl()->toUriString() in RegexRedirectRepository::replaceRegexWithActualUrl delivers encoded url parameters. Using $redirect_regex_url = preg_replace($pattern, $value, urldecode($redirect_regex_url)); solves my problem but maybe there is a better solution.

Hm OK, I see I was talking about the physical_measurement element. For this my approach works. Unfortunately I don't use the physical_dimensions element, but yes it might not work for that if you add it to attributes.

Claro supports on the other hand content_attributes for its wrapper, I think you could achieve the same if you add `form-items-inline` to content_attributes for web/core/themes/claro/templates/fieldset.html.twig:

<fieldset{{ attributes.addClass(classes) }}>
  {#  Always wrap fieldset legends in a <span> for CSS positioning. #}
  {% if legend.title %}
  <legend{{ legend.attributes.addClass(legend_classes) }}>
    <span{{ legend_span.attributes.addClass(legend_span_classes) }}>{{ legend.title }}</span>
  </legend>
  {% endif %}

  <div{{ content_attributes.addClass(wrapper_classes) }}>

At least it should work if you do this in a `hook_preprocess_fieldset`...

Thanks, I discovered there is a hook `hook_tokens_pre_alter` which fullfills all my needs to do that.

I didn't notice that at the beginning because there is no api.php and I discovered it only by inspecting the code of token_or.

@pianomansam Maybe you could create a `token_or.api.php` ?

Thought about the same but in a different way.

For the example above

[node:field_hero_image:entity:field_media_image:og_image|"/themes/custom/my_theme/image.png"]

why not extend it like that:

[node:field_hero_image:entity:field_media_image:og_image|site:base-url"/themes/custom/my_theme/image.png"]

I think this could be achieved by adding another condition in TokenOrTokensPreAlter::tokensPreAlter:

diff --git a/src/TokenOrTokensPreAlter.php b/src/TokenOrTokensPreAlter.php
index f57cace..0d34def 100644
--- a/src/TokenOrTokensPreAlter.php
+++ b/src/TokenOrTokensPreAlter.php
@@ -44,10 +44,16 @@ class TokenOrTokensPreAlter {
         $sub_tokens = explode('|', $match_clean);

         foreach ($sub_tokens as $sub_token) {
+          $sub_token_matches = [];
           if (substr($sub_token, 0, 1) === '"' && substr($sub_token, -1, 1) === '"') {
             // This is a string replacement.
             $result = substr(substr($sub_token, 1), 0, -1);
           }
+          elseif (preg_match('/([^"]*)"(.*?)"/', $sub_token, $sub_token_matches)) {
+            // This is a token replacement with an appended string.
+            $result = $this->token->replace('[' . $sub_token_matches[1] . ']', $data, $options);
+            $result .= $result ? $sub_token_matches[2] : '';
+          }
           else {
             // This is a token replacement.
             $result = $this->token->replace('[' . $sub_token . ']', $data, $options);

Just a quick question on this, I couldn't find a more appropriate issue. I wondered why ViewExecutable::buildThemeFunctions prefers (or even involves) the display_id as first argument over the view id.

$themes[] = $hook . '__' . $display['id'];
...
$themes[] = $hook . '__' . $id;

Is this intended? For me this looks a little bit like gambling, to even involve display_id as first argument. I stumbled on this after using a "views-view--something.html.twig" and wondered why the display of a view matched another html.twig, because its display id matched it, which I never expected...