🇩🇪Germany @cspitzlay

The suggestion in the issue summary was to leave it open even after committing the changes because the bot might improve and add more.

On the other hand, it hasn't done so in a year and D11 is out ... not sure if it makes sense to wait any longer.
At least it did not detect any incompatibilities.

So yes, it might make sense to close it now.

I created an alpha release for the 2.0.x branch.

Thank you for testing!

As Commerce 3 is supported on Drupal 10, can you keep Drupal 10 as supported for 2.0.x (and only require Commerce 3.x)?

Yes, if that's the case then I can re-add D10 in the 2.0.x branch.

The dev snapshot 2.0.x-dev is now available. I also updated the project page and created the release 1.0.0-alpha6 which dropped the claim of D11 support.

Thanks for your contribution!

I created a new branch "2.0.x" for support of D11 and Commerce 3.x.
I removed D11 support from the 1.0.x info.yml so it reflects the reality.

I reviewed and committed your changes, so you should soon have them in a dev snapshot.
I haven't tested them yet, though, so I'm leaving the issue open for now.

Here's the patch.

cspitzlay → created an issue.

Thanks for your work on this.

I can confirm that MR33 fixes the issue for me.

Here is the issue for the other crash: 🐛 Crash on jsonrpc/methods route Active

cspitzlay → created an issue.

Found the spot: In \Drupal\jsonrpc\Plugin\JsonRpcMethodManager::alterDefinitions, there's

      $class = $method->getClass();
      $output_schema = $class::outputSchema();
      $method->output = $output_schema;

Ok, so in the debugger I see that it crashes right at the first JSON-RPC method, the one in the issue summary.

 public function normalize($object, $format = NULL, array $context = []): array|\ArrayObject|bool|float|int|string|null {
    $attributes = [];
    foreach ($object as $key => $value) {
      switch ($key) {
        case 'id':
        case 'call':
        case 'access':
          break;

        default:
          $child = $value instanceof AnnotationInterface ? $value->get() : $value;
          if (isset($context[static::DEPTH_KEY]) && $child instanceof AnnotationInterface || (is_array($child)) && Inspector::assertAllObjects($child, AnnotationInterface::class)) {
            if ($context[static::DEPTH_KEY] === 0) {
              break;
            }
            $context[static::DEPTH_KEY] -= 1;
          }
--->    $attributes[$key] = $this->normalizer->normalize($child, $format, $context);
      }
    }
 

The key is 'output' at that time and $this->normalizer is NULL.

There is no mention of output in my method's annotation,
but IIRC the result of the output() method is set dynamically at some point
so the structure of the output appears in the method's self-documentation.

I tested MR31 and it solves the issue for me.

• The methods that crashed with 2.1.0 work with the change. So I guess it adresses the issue correctly.
• The jsonrpc/methods route now gives me a different error, though. See below

The website encountered an unexpected error. Try again later.<br><br><em
        class="placeholder">Error</em>: Call to a member function normalize() on null in <em class="placeholder">Drupal\jsonrpc_discovery\Normalizer\AnnotationNormalizer-&gt;normalize()</em> (line
<em class="placeholder">63</em> of <em class="placeholder">modules/contrib/jsonrpc/modules/jsonrpc_discovery/src/Normalizer/AnnotationNormalizer.php</em>).
<pre class="backtrace">Symfony\Component\Serializer\Serializer-&gt;normalize(Object, &#039;json&#039;, Array) (Line: 177)
Symfony\Component\Serializer\Serializer-&gt;normalize(Array, &#039;json&#039;, Array) (Line: 177)
Symfony\Component\Serializer\Serializer-&gt;normalize(Array, &#039;json&#039;, Array) (Line: 138)
Symfony\Component\Serializer\Serializer-&gt;serialize(Array, &#039;json&#039;, Array) (Line: 67)
Drupal\jsonrpc_discovery\Controller\DiscoveryController-&gt;methods()
call_user_func_array(Array, Array) (Line: 123)

I am not sure this is a bug in the module or a wrong method annotation.
I'll try to find out.

cspitzlay → created an issue.

Well, at least it used to be fixed. I had successfully tested this 6 years ago.
See https://github.com/drush-ops/drush/issues/3672#issuecomment-420950688

Could be a new issue. You may want to report it against drush along with your steps to reproduce it.

Ah, you are using the on-site gateway, don't you?

I was wondering what a donation checkout looked like on the offsite paypage.
For example, if you needed to add a custom donation item to the cart so it all adds up in the cart display on that external page.

Looks good. Thanks to both of you.

@dimaro

• In your opinion, does this warrant a new alpha release or is it enough that it is fixed in the dev version?
• Just out of interest: You mentioned that you have donations. Is there anything different from a regular order that has products with respect to the Unzer payment?

Well, we are still at an alpha version and not a regular release.
But then again: D11 is near so keeping this open may not make much sense.

cspitzlay → created an issue.

The fix is in the 1.0.0-alpha5 → release.

Ouch. Thanks for catching this.

Ah, it seems to fixed in 6.0.x already.

cspitzlay → created an issue.

cspitzlay → created an issue.

I seems a fix for this is already included in https://www.drupal.org/project/openapi/issues/3362322 📌 PHP 8.2 Deprecations RTBC (see https://www.drupal.org/project/openapi/issues/3362322#comment-15333896 📌 PHP 8.2 Deprecations RTBC ).

Closing as duplicate.

Trying to move the issue ...

I think you posted this issue against the wrong project. That controller is in the openapi project, not in openapi_rest.

Did you enable the submodule search_api_solr_admin?

There should be a button on the server config page:

cspitzlay → created an issue.

cspitzlay → created an issue.

• Commerce promotion adjustments are turned into Unzer basket items of type "voucher", grouped by source ID.
• Shipping costs are turned into Unzer basket items of type "shipment".
• The broken general handling of items with negative value has been removed.

Here is the documentation:
https://docs.unzer.com/server-side-integration/direct-api-integration/ma...

The type is "voucher". Another type that may be useful to us: "shipment" for shipping costs.

Now this is the documentation for direct API access. But there is a class in the Unzer SDK that defines types:
UnzerSDK\Constants\BasketItemTypes and there is a setType() method on the basket item.

cspitzlay → created an issue.

That's the reason why search_api_solr tests did not really use drupalCI but ran on github.
But maybe now, with gitlab CI, it will be possible to use the drupal infrastructure.

Now this is embarrassing. Thanks for reporting and fixing this.
Since it is a crasher I created a new alpha release right away ( 1.0.0-alpha3 → ).

@ptmkenny: Regarding the question in #3 about the comment above the property:
I think your stacktrace is from a reviving such an object while fetching it from cache.

The only write access to this property I could find in regular code is in:
Drupal\jsonrpc\Plugin\JsonRpcMethodManager->alterDefinitions()
and that is where I got this deprecation message.

It looks to me as if it was the output schema that went into that property.

I will amend the comment accordingly and adapt the type to match the return type of \Drupal\jsonrpc\Plugin\JsonRpcMethodBase::outputSchema() which is where the value that is written comes from.

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

I created an issue some days ago about code quality improvements and modernization:
https://www.drupal.org/project/commerce_unzer/issues/3403407 📌 Bring code up to snuff Fixed

I made the changes I had in mind and will soon create a new alpha release.

The four tools have been run and the found issues have been fixed.

In addition, some deprecated uses of the Unzer SDK around the handling of the basket have been fixed.
One side effect of this is that there is now a stricter validation on the Unzer side.
Basket items with a value of zero are no longer allowed and will now be skipped
when we create the basket.

cspitzlay → created an issue.

@gruberroland : I committed the patch that removes the dependency on jQuery once.

• Are you aware of any remaining issues with respect to D10 compatibility?
  Other than packaging a release, I mean.
• Are you using the onsite payment gateway? That part is known to have worked at least at some point but we do not use it in our project so it sees little testing.

Makes sense to me. I committed a change based on your patch.

Here's the change record for the JavaScript change: https://www.drupal.org/node/3158256 →

The patch updates the PHP version requirement to >= 8.1 although the Unzerdev SDK still supports 7.4.

Since Drupal 9 is no longer supported now ( https://www.drupal.org/docs/understanding-drupal/drupal-9-release-date-a... → ) and Drupal 10 requires at least PHP 8.1 ( https://www.drupal.org/docs/getting-started/system-requirements/php-requ... → ) I think we can accept that.

cspitzlay → created an issue.

How can an anonymous user choose their subscription language after this change?
Now I need to use the suggestion from #2 ( https://www.drupal.org/project/simplenews/issues/3385578#comment-15222697 🐛 Remove the language selection on subscriptions block form Fixed ) but the other way around, forcing it to TRUE.

The changes to line 57 of js/commerce_unzer.form.js seem wrong. Do they work for you?

This has been done in commit b63c68b9d07a5fb2b67facfb735ffaaeb1886a98

cspitzlay → created an issue.

This has been committed (#8), so setting the issue to fixed.

cspitzlay → created an issue.

cspitzlay → created an issue.

That's true for the exception I'm seeing. Thanks for finding that issue.

NB: Fixing 🐛 ReplicaKillSwitch unnecessarily starts a session on each request Needs work won't help with the original reporter's problem though.

Here is my stacktrace from the watchdog:

Drupal\Core\Entity\EntityStorageException: Failed to start the session because headers have already been sent by "/var/www/html/vendor/symfony/http-foundation/Response.php" at line 384. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 815 of /var/www/html/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php) #0 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityBase.php(339): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object(Drupal\commerce_order\Entity\Order))
#1 /var/www/html/web/modules/contrib/commerce/modules/payment/src/PaymentOrderUpdater.php(101): Drupal\Core\Entity\EntityBase->save()
#2 /var/www/html/web/modules/contrib/commerce/modules/payment/src/PaymentOrderUpdater.php(59): Drupal\commerce_payment\PaymentOrderUpdater->updateOrder(Object(Drupal\commerce_order\Entity\Order), true)
#3 /var/www/html/web/modules/contrib/commerce/modules/payment/src/PaymentOrderUpdater.php(112): Drupal\commerce_payment\PaymentOrderUpdater->updateOrders()
#4 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/KernelDestructionSubscriber.php(51): Drupal\commerce_payment\PaymentOrderUpdater->destruct()
#5 [internal function]: Drupal\Core\EventSubscriber\KernelDestructionSubscriber->onKernelTerminate(Object(Symfony\Component\HttpKernel\Event\TerminateEvent), 'kernel.terminat...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#6 /var/www/html/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(142): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\TerminateEvent), 'kernel.terminat...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#7 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(103): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\TerminateEvent), 'kernel.terminat...')
#8 /var/www/html/vendor/stack/builder/src/Stack/StackedHttpKernel.php(32): Symfony\Component\HttpKernel\HttpKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\TrustedRedirectResponse))
#9 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(712): Stack\StackedHttpKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\TrustedRedirectResponse))
#10 /var/www/html/web/index.php(22): Drupal\Core\DrupalKernel->terminate(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\TrustedRedirectResponse))

Here are some more details:

The common thing in both cases is that Drupal\commerce_payment\PaymentOrderUpdater->updateOrders()
which runs in the kernel termination event triggers code that accesses the session.

I guess it is expected from a method called updateOrders() that it, well, updates orders.
But the general implementation in Drupal\Core\Entity\Sql\SqlContentEntityStorage::save() triggers the
replica kill switch: \Drupal::service('database.replica_kill_switch')->trigger();
which in turn will write to the session(*) (which will crash if called after sending of the response):

  public function trigger() {
    $connection_info = Database::getConnectionInfo();
    // Only set ignore_replica_server if there are replica servers being used,
    // which is assumed if there are more than one.
    if (count($connection_info) > 1) {
      // Five minutes is long enough to allow the replica to break and resume
      // interrupted replication without causing problems on the Drupal site
      // from the old data.
      $duration = $this->settings->get('maximum_replication_lag', 300);
      // Set session variable with amount of time to delay before using replica.
      $this->session->set('ignore_replica_server', $this->time->getRequestTime() + $duration);
    }
  }

Thus it looks fundamentally wrong to me to call updateOrders() from the Kernel termination event.

At least in my case this error even goes unnoticed by the user, as the response has already been sent to the browser
and the crash will not appear in the messenger. There is a watchdog message though,
and the DB transaction that contains the changes that the updateOrders() was about will be rolled back.

(*): Unless there are no replicas at all.

I see a similar error after successful online payment.

The PaymentOrderUpdater->updateOrders() call is executed when the kernel terminates which is after the response has already been sent.

In my case it actually udpates the order. But the entity save method tries to trigger the replica kill switch which in turn tries to write to the session. That is impossible if the response has already been sent.

NB: That particular issue is only triggered if there are replica DBs defined.

cspitzlay → created an issue.

We will integrate this patch into our project and report back.

And the status.

Revert accidental prio change.

Re #4: Of course, that's better. I had looked for issues about the translation handler but didn't come across that one.

The reason I looked at that class was a hard-to-reproduce crash in a custom project with the error message:

In EntityTypeManager.php line 256:

The "commerce_shipping_method" entity type did not specify a translation handler.

That sometimes leaves the system in a broken state until I run `drush cr` again until it succeeds.
Since it is not happening every time I cannot tell yet if removing that line will fix my issue,
but referencing a non-existing class seems wrong in any case.

cspitzlay → created an issue.

Are you really using the Solr feature called "streaming expressions"? It is not available via the UI but requires coding. If you do not know what they are about then you should deactivate this processor as it is only useful if you are affected by the limitation of Solr with respect to quoting the double quote character in streaming expressions.

What is the meaning of a permission "create own <whatever>"?