🇧🇪Belgium @matthijs

matthijs → changed the visibility of the branch 3107501-order-summary-shows to active.

matthijs → changed the visibility of the branch 3107501-order-summary-shows to hidden.

I encounter the same bug and tracked it down to the order changes in \Drupal\commerce_promotion\Plugin\Commerce\InlineForm\CouponRedemption::applyCoupon and \Drupal\commerce_promotion\Plugin\Commerce\InlineForm\CouponRedemption::removeCoupon having no effect on the order in the checkout flow form object.

If you add following code (which forces the order to be reloaded in the form object) after saving the order in these methods, the issue is fixed.

This is obviously not the proper fix. I guess the best solution would be to extend \Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\CheckoutFlowBase with a setOrder method?

Since the lifetime of the access token is rather short and there's no refresh token I saw no other workaround than adding a setting that allows you to use a realm only for authentication. This means that Drupal will not store the OpenID Connect tokens, validate the remote session or trigger a remote logout when applicable.

So basically when a user logs in using OpenID Connect the remote session is "forgotten" after the claims are processed.

There will be coming one later this week, but I first want to see if I can add a fix for #3507175 as well.

Changes have been merged, thanks for your effort.

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

Changes merged, thanks for the effort!

This was fixed in 🐛 With 10.2 image styles might get wrongly flushed Active

I've spend a long time investigating this bug and it seems image_effects_image_style_flush() is to blame, it doesn't implement the $path parameter causing the whole style to be flushed.

I wanted to share a simplified (aka extending on the default widget) version of the widget above:

namespace Drupal\module\Plugin\Field\FieldWidget;

use Drupal\commerce_order\Adjustment;
use Drupal\commerce_order\Plugin\Field\FieldWidget\AdjustmentDefaultWidget;
use Drupal\Core\Field\FieldItemListInterface;
use Drupal\Core\Form\FormStateInterface;

/**
 * Provides the adjustment with percentage widget.
 *
 * @FieldWidget(
 *   id = "commerce_adjustment_percentage",
 *   label = @Translation("Adjustment with percentage"),
 *   field_types = {
 *     "commerce_adjustment"
 *   }
 * )
 */
class AdjustmentPercentageWidget extends AdjustmentDefaultWidget {

  /**
   * {@inheritdoc}
   */
  public function formElement(FieldItemListInterface $items, $delta, array $element, array &$form, FormStateInterface $form_state) {
    $element = parent::formElement($items, $delta, $element, $form, $form_state);

    /** @var \Drupal\commerce_order\Adjustment|null $adjustment */
    $adjustment = $items[$delta]->value ?: NULL;

    $element['percentage'] = [
      '#type' => 'value',
      '#value' => $adjustment?->getPercentage(),
    ];

    return $element;
  }

  /**
   * {@inheritdoc}
   */
  public function massageFormValues(array $values, array $form, FormStateInterface $form_state) {
    $result = parent::massageFormValues($values, $form, $form_state);

    foreach ($values as $key => $value) {
      if (!$result[$key] instanceof Adjustment || empty($value['percentage'])) {
        continue;
      }

      $value = ['percentage' => $value['percentage']] + $result[$key]->toArray();
      $result[$key] = new Adjustment($value);
    }

    return $result;
  }

}

The solution of #3508677 also seems to work for this one

The MR adds a JavaScript callback to properly encode the current query parameters.

matthijs → created an issue.

matthijs → changed the visibility of the branch 3193844-leverage-views-grouping to hidden.

matthijs → changed the visibility of the branch 3193844-leverage-views-grouping-11.x to active.

Created a MR for 11.x, which also works for 10.4

matthijs → changed the visibility of the branch 3193844-leverage-views-grouping-11.x to hidden.

Initial code review looks okay, will do some more testing in the upcoming days.

Thanks for your work so far.

The patch still applies to 2.x and seems to work fine.

The patch seems to work nicely, but shouldn't we also require Paragraphs 1.18 in composer.json?

Thanks for the patch.

With the current setup you have a dedicated dev environment for the module. I agree it's not common, but it eases development a lot.

The unneeded dependencies are in require-dev, so they aren't installed when you install the module in your project. The only thing that would be visible it is the scaffold integration (as in core mentioning that it is ignoring it). I will investigate if I can remove/prevent that.

Noticing the same issue while updating from 3.0.1 to 3.0.5, the patch seems to fix it. It seems my project used 8.x-1.x-dev in the past, which explains why the class is known in the DB.

matthijs → created an issue.

Patch committed, thanks!

I created an MR in 🐛 Range slider settings don't allow different min/max type Needs review that also contains some range/rounding related (not sure if it will fix all issues mentioned here).

Created MR for Facets 3.0.x. I also fixed some issues related to the min/max being not in sync with the step (related to #3182839).

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

Fixed various issues, e.g. compatibility with the 6.x version.

matthijs → changed the visibility of the branch 3479830-the-enyodropzone-library to hidden.

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

I converted the patch from #3118296-17: Add extra fields to config → into an MR and fixed compatibility with 4.3.3.

matthijs → changed the visibility of the branch 4.x to hidden.

@vidorado @gaëlg I resolved them all.

Removed the fieldable property from the entity annotation as per https://www.drupal.org/node/2346455 →

The project has his own phpcs config, please use that one.

There's no "real" benefit, except preventing a call to the system's clock. But to be honest I'm not convinced of the timestamp usage, you could also display the file creation time when listing the files.

matthijs → created an issue.

matthijs → created an issue.

I assume your signature field is in a group that's hidden by default? Apparently this is a limitation of the element, it cannot be "initialized" in a hidden element.

To fix this I would have to adjust the initialization to detect if the widget is visible and if not postpone further processing until it becomes visible. That sounds like a lot of work/changes for a relatively small added value. I'm not gonna invest time in this, but feel free to open an MR and I'll review your changes.

Merged, thanks for your contribution!

I personally prefer the current approach, what are the benefits of using a timestamp?

Would it be a good idea to make this configurable? I'm thinking of a textfield in the field settings where you can specify the filename (format) using tokens. This adds some flexibility, but it might also be overkill?

Closing since D7 compatible version is no longer maintained

Closing since D7 is no longer maintained

The MR adds the destruct method.

Matthijs → created an issue.

This module doesn't use jackocnr/intl-tel-input I think you use another module that implements jackocnr/intl-tel-input.

Added a workaround to include the file token in the ajax response.

The patch doesn't fully work yet, due to the missing file tokens.

The MR removes the CSFR token and changes the way the key is generated.

Matthijs → created an issue.

This looks like the same issue I reported in #3425688, no?

Matthijs → created an issue.

Just to be clear: I meant when I created this module (3 years ago). At that time there were a few long-standing open issues with pending patches that I needed in all my projects because otherwise the module didn't work (at least not for Belgian numbers). And those patches didn't seem to get committed, even tough they were tested and reviewed by various people.

But I see both your modules have a recent release, so I was obviously wrong! And no need to apologize, we're all aware of how time consuming an issue queue can be. I don't think I ever reached out, I just started this module because I also had the requirement to format phone number in the DB for e.g. searching and exporting (unless I'm mistaken this wasn't/isn't supported by your modules?) and I didn't want to create a patch and had to maintain it for a long time until it got merged.

Anyhow, I agree that core should have at least some basic functionality regarding phone numbers, but I'm afraid this is never gonna happen since this will yet be another library requirement also needing maintenance.

Thanks!

Any news on this?

I started this module because because those two other modules were kinda broken/dead at that time (no clue what their current state is) + it felt kinda odd having two modules for these features.

Joining forces might be an option, but the most logical scenario would be that the other modules are deprecated and an upgrade path is provided. WDYT? Did you open an issue on the other 2 modules as well?

Thanks for reporting. I changed the constructor property promotion to old school arguments.

Matthijs → created an issue.

Since the embedded cache tag hashing tries to fix the same thing as #2952277 it would make sense to use the minificator from that issue. So the MR I opened removes the existing mechanism and uses the minificator service instead (and thus depends on the patch from #2952277).

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

Thanks for the MR, it looks okay (I can't easily test it either), so I merged it.

We noticed a performance impact on our project due to this patch (the query took often 300-500ms) and decided to remove it.
As a safety (in case it ever gets merged) I converted the patch from #130 into an MR and added a config option to enable wildcard support.

I did not update any tests, these might still need changes.

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

Patch applied and comitted, thanks!

Changing the project after 2 weeks as described on https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or... →

Project link: https://www.drupal.org/project/cache_debug →

Forgot to mention this, but before creating this issue I also contacted Josh Waihi via his profile to ask the same thing.

Hi,

Good news, this module ain't dead! I just consider it feature-complete (as stated on the home page) and since I don't have any projects using it I did not make is D10 compatible.

That said, I do fillow-up the queue for any new issues and try to repond within an appropriate time, but my effort will be limited to reviewing and merging. E.g. in the case of #264483 I asked to rework the hook into an event and use DI where applicable.

I will try tot review your D10/11 compatibily patch later this or next week.

PS: the other maintainers are no longer actively involved, I developed and maintain the D8+ version.

Matthijs → created an issue.

Matthijs → created an issue.

Created a new one especially for you ;-)

Changes merged, thanks for your contribution.

Matthijs → created an issue.

It should be usable everywhere, the only requirement is a valid oidc session.

Since the cache ID is actually cached, the $vary_headers passed to \Drupal\page_cache\StackMiddleware\PageCache::getCacheId() actually did nothing.

I created a merge request from #2430335-194: Browser language detection is not cache aware → and did some changes to cache the cache ID by $vary_headers.

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

Matthijs → created an issue.

Great!