🇬🇧United Kingdom @intrafusion

intrafusion → created an issue.

As per my comment in #5, this has been running for a few weeks on our production system and appears to be working as expected

I’m confused, if this has already been committed the tests passing or failing are irrelevant?

Just need a tagged release to enable the module to be installed

Can we get a tagged release?

It's not possible to upgrade to D11 without one

We have been using this on a production D11 site for approx. 1 month without any obvious issues

@trickfun the patch on it's own is not enough to upgrade, your repositories section of composer.json it should look like:

    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8",
            "exclude": [
                "drupal/commerce_klarna_payments"
            ]
        },
        {
            "type": "git",
            "url": "https://git.drupalcode.org/issue/commerce_klarna_payments-3506060.git"
        }
    ],

You may have additional repositories so ensure you don't override something else you need. You should then be able to run composer require drupal/commerce_klarna_payments:dev-3506060-support-commerce-3 to install the patched version allowing the upgrade.

Further debugging has discovered a difference between Facets v3 & Better Exposed Filters v7 (required for D11)

After amending 'widget' => '<nowidget>', to 'widget' => ['type' => 'dropdown', 'config' => []], in \Drupal\facets_exposed_filters\Plugin\views\filter\FacetsFilter::getFacet the error is now gone and I can access the settings link against the filter, but it's not possible to change widgets as per https://project.pages.drupalcode.org/facets/exposed_filters/#better-expo...

I get exactly the same error, different line number, when I simply add a facet to the filter criteria. Same error is also generated when I click on settings.

This might be a D11 issue as we've upgraded recently

From looking through the code, \Drupal\schema_metatag\SchemaMetatagManager::encodeJsonld has JSON_PRETTY_PRINT set in the flags for json_encode

Is there any specific reason for this other than for debugging? It would make sense to remove this when caching and/or aggregate CSS/JavaScript is enabled

At this stage I needed this patch to be able to install Drupal 11.

It will be tested further during the next few weeks.

intrafusion → created an issue.

Any chance of a tagged release?

intrafusion → created an issue.

intrafusion → changed the visibility of the branch 3438140-automated-drupal-11 to hidden.

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

intrafusion → changed the visibility of the branch 8.x-1.x to hidden.

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

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

intrafusion → created an issue.

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

intrafusion → changed the visibility of the branch 3428501-automated-drupal-11 to hidden.

intrafusion → changed the visibility of the branch project-update-bot-only to hidden.

By adding the following to the config section in composer.json the original patch by poker10 applies cleanly and Upgrade Status says the module is compatible:

  "preferred-install": {
      "drupal/commerce_stock": "source",
      "*": "auto"
  },

4b4f933a does not apply cleanly
ae993fcb is not required in this issue, it should be moved to a separate one

This option has now been added by default to dialog.ajax.js as drupalAutoButtons

Usage example:

[
  '#type' => 'link',
  '#title' => $this->t('Log in'),
  '#url' => new Url('user.login'),
  '#attributes' => [
     'class' => ['use-ajax'],
     'data-dialog-type' => 'modal',
     'data-dialog-options' => '{"drupalAutoButtons":false}',
  ],
];

intrafusion → created an issue.

Moved NonKlarnaOrderException into a separate try/catch block

intrafusion → created an issue.

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

The server side key is the normal Rollbar API key, the client side key is for JavaScript

Once the keys have been added, you have to trigger an error for Rollbar to receive data, no errors no data

Would appear that somewhere between 8.5 & 11 this has been rectified

The 10.1.x patch from #62 doesn't apply to 10.2.x but the 11.x patch from #67 does, testing whether this still fixes the issue for me

Anyone landing here from Google, etc. the Drupal 10 version is:

use Drupal\Component\Utility\Number;

/**
 * Implements hook_preprocess_HOOK().
 */
function YOUR_THEME_NAME_preprocess_comment(&$variables) {
  /** @var \Drupal\comment\CommentInterface $comment */
  $comment = $variables['comment'];
  $thread = rtrim($comment->getThread(), '/');
  $variables['comment_number'] = Number::alphadecimalToInt($thread);
}

intrafusion → created an issue.

intrafusion → created an issue.

intrafusion → created an issue.

Added to upcoming release

intrafusion → created an issue.

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

Same problem and MR fixes it

Works great, thanks

Unless I'm mistaken this doesn't pull the config option from Webform settings, simply overrides for each export which is not ideal.

This is unnecessarily complicated, the following changes can be made:

$form['scrub_fields'] = [
  '#type' => 'textarea',
  '#title' => $this->t('Scrub fields'),
  '#default_value' => implode("\n", $config->get('scrub_fields')),
  '#description' => $this->t('Field names to scrub out of the entire payload. Enter one field name per line. Values will be replaced with asterisks.'),
];

->set('scrub_fields', preg_split("(\r\n?|\n)", $form_state->getValue('scrub_fields')))

// Populate basic configuration.
$configuration = [
  'access_token' => $token,
  'environment' => $environment,
  'scrub_fields' => $this->config->get('scrub_fields') ?? [],
];

Also a merge request is much easier for a maintainer to review and accept

You can as I do, use the merge release, in the repositories section of your composer.json:

{
    "type": "composer",
    "url": "https://packages.drupal.org/8",
    "exclude": [
        "drupal/mobile_number"
    ]
},
{
    "type": "git",
    "url": "https://git.drupalcode.org/issue/mobile_number-3288679.git"
}

You might have existing changes which need to kept as well as the above, then run composer require drupal/mobile_number:dev-3288679-automated-drupal-10

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

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

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

This module was the only one blocking my upgrade to D10, by creating the merge request I was able to update my composer.json to:

{
    ...
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.drupal.org/8",
            "exclude": [
                "drupal/paragraphs_summary"
            ]
        },
        {
            "type": "git",
            "url": "https://git.drupalcode.org/issue/paragraphs_summary-3289000.git"
        }
    ],
    "require": {
        ...
        "drupal/paragraphs_summary": "dev-3289000-automated-drupal-10",
        ...
    },
    ...
}

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

New release 2.1.0 which is for Drupal 10 only

New 2.1.0 release added which is for Drupal 10 only

The change to the function signature in this issue actually breaks backwards compatibility as per 🐛 Rollbar is not compatible with Drupal 10 again Fixed

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

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

intrafusion → created an issue.

The functionality this module provides is included in Core

@catch but it's not fixed, the patch still needs to be ported

@catch the last working patch for me is 🐛 Multiple issues when PostgreSQL is used with non-public schema Fixed and none tagged with 9.5.x, etc. apply cleanly. I haven't had an opportunity to review why

If it's going to be ported, I need for 9.5.x as this is issue is holding me back on 9.4.x

Thanks @AdamPS, I originally installed 1.0.0-alpha3 and updated several times along the way (but no real idea when and what would have been updated)

I agree totally with what you're saying about symfony_mailer_update_10006() but could this have been missed when moving between 1.0/1.1 and 1.2 releases?

I too am getting this error a lot in the logs and the cause is related to upgrading from previous versions, etc.

At some point in the past I upgraded from an early beta version of Drupal Symfony Mailer which didn't include the swiftmailer emulation. By simply re-saving the effected policy (*All*) in my case this has gone away

I have created a quick patch which hardcodes the archive type as zip as I could work out how to pull the config option from Webform settings, but this will obviously need changing.

I also had to comment out the section which calls ```verifyArchive``` as this is expecting a tar file, not sure whether that whole chunk of code could be removed?

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