🇨🇳China @skyredwang

D10 release https://www.drupal.org/project/commerce_moneris/releases/8.x-2.0-rc6 →

This version simplified the owner checking.

Why are you fetching the profile to check ownership?

This is documented as in the comment

// skip handling payment methods for anonymous users for now.

The attached patch corrected the access of the fields.

skyredwang → created an issue.

skyredwang → created an issue.

Stripe Payment Element was already implemented in the last stable. Closing this ticket

Reopening this issue, the original problem statement is still accurate, not outdated. #10 needs a reroll

I'd like to suggest to include a Docker instruction for the morden SolrCloud setup.

Step 1, start a Zookeeper container:

docker run -d --name zookeeper -p 2181:2181 zookeeper

Step 2, save a copy of Solr security configuration in your project, e.g. DOCROOT/config/dev.security.json, whose content is below:

{
  "authentication": {
    "class": "solr.BasicAuthPlugin",
    "credentials": {
      "solr": "IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="
    }
  },
  "authorization": {
    "class": "solr.RuleBasedAuthorizationPlugin",
    "permissions": [
      {
        "name": "security-edit",
        "role": "admin"
      }
    ],
    "user-role": {
      "solr": "admin"
    }
  }
}

Step 3, start a Solr container running in a cloud mode with basic authentication.

docker run --name solr9 -p 8983:8983 -e ZK_HOST=zookeeper --link zookeeper:zookeeper -v "$PWD/config/solrcloud.security.json:/opt/solr/server/solr/security.json" -d solr:9 bash -c "docker-entrypoint.sh solr zk cp file:/opt/solr/server/solr/security.json zk:/security.json && exec solr-foreground"

Step 4, Upload the config and create a collection

On the Drupal side, visit /admin/config/search/search-api/server/[SERVER_NAME]/solr-admin/upload-configset, then click "Upload and Create Collection"

The bug is fixed in ✨ Add the option to not setup payment methods for future usage Needs review , but you would need a new plugin to use Blik and Przelewy24

giropay is a single use payment method

---- https://stripe.com/docs/payments/giropay/accept-a-payment

Here is why https://www.drupal.org/project/commerce_stripe/issues/3392413#comment-15... ✨ Add the option to not setup payment methods for future usage Needs review , and the fix is in that issue

I am not sure about Paypal

@agoradesign, you would need ✨ Add the option to not setup payment methods for future usage Needs review to see single-use payment methods

In https://www.drupal.org/project/commerce_stripe/issues/3392413#mr56-note2... ✨ Add the option to not setup payment methods for future usage Needs review , I added a condition.

Here is one more thing we have to deal with: when a payment succeeded, we have the logic to create a customer and attach the payment method in both Stripe.php and StripePaymentElement.php.

However, when we set setup_future_usage: null to make/allow single-use payment method. We cannot create the customer and attach the single-use payment method. Otherwise, Stripe API will return:

400 invalid_request_error
This PaymentMethod was previously used without being attached to a Customer or was detached from a Customer, and may not be used again.

This is documented here https://stripe.com/docs/payments/payment-methods#usage

Single-use payment methods (for example, some kinds of bank transfers) can’t be attached to customers because they’re consumed after a payment attempt.

So, depending on the gateway, we will conditionally attach the payment method that just completed.

This was already handled in the latest dev

skyredwang → created an issue.

@vmarchuk Thanks for the reference, I repurposed this issue.

I brought the latest changes from 8.1-1.x to this MR.

However, I temporarily removed the changes to Stripe.php

In #3, @rszrama wanted to add this third option for Card Element. But, Card Element uses Stripe Card Element (Stripe.php) gateway, which doesn't have on-session and off-session configurations.

@vmarchuk made this 3rd option available to Card Element by using the configuration from Stripe Review Pane. Programming wise, add a condition or dependency on routing makes Stripe.php less robust, as routing isn't always safe assumption. Personally, I think if we want the Card Element to have this configuration, then we want to add this configuration to its gateway. The configuration for Stripe Review Pane serves as an option to override in the checkout process.

What do you think?

https://www.drupal.org/project/commerce_stripe/issues/3392413#mr56-note2... ✨ Add the option to not setup payment methods for future usage Needs review works, I can see the new option "Single use: the payment method will not be made available for subsequent transactions" under Stripe Payment Element payment gateway. When choosing it, I can see single-use payment methods showing up, although they don't actually work, that's new issues.

Can we get this in first, so follow up issues can fix additional problems.

Since Stripe Payment Element was added to the module, this initial implementation is no longer relevant. Move to ✨ Support single-use payment methods like Link, Alipay and WeChat Pay Active

skyredwang → created an issue.

Full access granted. Thanks for stepping up.

alexpott → credited skyredwang → .

Please see the screenshots.

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

Just to provide another reference:

BCP 47: 2.1.1. Formatting of Language Tags

At all times, language tags and their subtags, including private use
and extensions, are to be treated as case insensitive: there exist
conventions for the capitalization of some of the subtags, but these
MUST NOT be taken to carry meaning.

Thus, the tag "mn-Cyrl-MN" is not distinct from "MN-cYRL-mn" or "mN-
cYrL-Mn" (or any other combination), and each of these variations

Phillips & Davis Best Current Practice [Page 6]

RFC 5646 Language Tags September 2009

conveys the same meaning: Mongolian written in the Cyrillic script as
used in Mongolia.

The ABNF syntax also does not distinguish between upper- and
lowercase: the uppercase US-ASCII letters in the range 'A' through
'Z' are always considered equivalent and mapped directly to their US-
ASCII lowercase equivalents in the range 'a' through 'z'. So the tag
"I-AMI" is considered equivalent to that value "i-ami" in the
'irregular' production.

Although case distinctions do not carry meaning in language tags,
consistent formatting and presentation of language tags will aid
users. The format of subtags in the registry is RECOMMENDED as the
form to use in language tags. This format generally corresponds to
the common conventions for the various ISO standards from which the
subtags are derived. ---- https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1.1

The lastest version is functioning. It supports two use cases:

- Change password knowing the existing password
- Change password without knowing the existing password, but have the timestamp and token from forget password URL

Remaining work to do:

- Tests
- Some of the code are copied from /core/modules/user/src/AccountForm.php and /opt/drupal/web/core/modules/user/src/Controller/UserController.php , better to re-organize them, but need suggestions, as I am not familiar with core.

I spoke with @alexpott on Slack, and understood that I can keep the same endpoint but defining a new route based on the new HTTP method.

I pushed the change to the issue fork 11.x

Corrected the patch path

The reason I didn't want to use a seperate controller is because the existing resetPassword uses /user/password.

/user/password is generic, if I use a new path like /user/change_password for changing password, then we have two end points for the consumer. One generic, one specific, that's confusing to me. What do you think?

Attached improved the code comment per suggestion 2

Here is the first draft, no tests. I am reusing the /user/password endpoint, if the HTTP method is POST, then this implementation assume it is for resetting password, if the HTTP method is PATCH, then it is for changing password.

@jrglasgow, thank you for your solution.

Based on your suggestion, I didn't use build script, but rely on composer scaffolding capability to achieve the same thing.

my code snippet looks like below:

"extra": {
        "patchLevel": {
            "drupal/core": "-p2"
        },
        "patches-file": "composer.patches.json",
        "drupal-scaffold": {
            "locations": {
                "web-root": "docroot/"
            },
            "allowed-packages": [
                "amazeeio/drupal_integrations"
            ],
            "file-mapping": {
                "[web-root]/sites/default/all.settings.php": "assets/all.settings.php",
                "[web-root]/modules/custom/.gitkeep": "assets/gitkeep",
                "[web-root]/themes/custom/.gitkeep": "assets/gitkeep",
                "[project-root]/vendor/google/.gitattributes": "assets/google.gitattributes"
            }
        },

The number of results is supported now. Removing the doc about that limitation

skyredwang → created an issue.

tested #4, it works

@heddn Can you please roll a new release for D10?

Can we get this committed?

A workaround is found:

- Install drupal/redirect module
- enable the module
- On GraphQL Core Schema, enable Routing and Redirect entity type
- Clear cache

This error is still reproducible on both 1.0.0-beta5 and 1.0.x-dev

Can you please tag a new beta release?

> Isn't this just a bug in the decoupled application? It's the responsibility of any decoupled application to transform relative URLs?

No, I think this is at least a DX issue. When CKeditor is used to embed a remote media, the iframe is embedded in the body of a long text. For most front end applications, sure, they can add a domain to the URL that output by Media OEmbed, but that means the front end needs to parse the body of the text.

For few frontend apps, multiple Drupal backends can be connected at the same time, therefore, the frontend would have a little bit more logic to write when prefixing a domain.

Proposed solution: And a checkbox somewhere to allow Media OEmbed to output absolute URLs when checked, and default to relative path for backward compatibility

skyredwang → created an issue.

> I send a email to skyredwang and there is no reply.

@g089h515r806, I did not receive an email from you. Please resend it through the contact form, or paste the whole email below.

skyredwang → created an issue.

skyredwang → created an issue.

@Lugir, I only review the translations that I need for clients projects at work, but I also help onboard new contributors sometimes.

I think there are more than 50 translation community moderators in the Chinese group. @Gábor Hojtsy do you know a way that I can filter the members list by their roles?

@Lugir, we have this review process in place to guard the quality. I am not comfortable to give you self moderator role right now, as you don't have a track of approved translations. However, please ping me or use the contact form for a large list of pending translations that you want me to review. I can do that for you.

I then emailed the group admin with the link to the post, but no response for now

FYI: I actually did not receive an email from @Lugir, I only received one from @Gábor Hojtsy on February 9th

@Lugir Hi, maybe you did not get the notification, I did reply to your request https://localize.drupal.org/node/64171 on February 10th

Because 2.x is no longer supported, I re-rolled #4 patch for 3.x

Looks like this code is already committed on 3.x

I added one more line null safety check to handle the case that a revisioned reference in a block could be missing (possibily deleted)

              /** @var \Drupal\Core\Entity\EntityInterface $reference */
              /** @var \Drupal\Core\Entity\EntityInterface $reference_clone */
              $reference = \Drupal::service('entity_type.manager')->getStorage($target_type)->loadRevision($value['target_revision_id']);
              if ($reference) {
                $reference_clone = $reference->createDuplicate();
                $reference_clone->save();
                $new_values[] = [
                  'target_id' => $reference_clone->id(),
                  'target_revision_id' => $reference_clone->getRevisionId(),
                ];
              }

The problem can be reproduced if the page to be translated has blocks which are not pointing to its latest revision.

I tested the patch, it fixed the problem, and the code makes sense to me. I have been thinking on writing a test against it. But, I haven't found a way to update an inline block outside the layout builder to create a new revision which is not referenced by the layout overrides. Maybe, there is another easy way to reproduce the problem on a fresh install?

A block could be missing, but also the references in the block can also be missing.

/** @var \Drupal\Core\Entity\EntityInterface $reference */
/** @var \Drupal\Core\Entity\EntityInterface $reference_clone */
$reference = \Drupal::service('entity_type.manager')->getStorage($target_type)->load($value['target_id']);\
$reference_clone = $reference->createDuplicate();

These two lines need a null check.

Tested #34 with Facets. Steps:

1. Go to edit the views of interest
2. Expand "Advanced" section
3. Click "Exposed form style: Settings"
4. Put f in the Preserve query parameters from URL
5. Save and clear cache

It works.

Simple fix.