This has been merged, thanks!
We could definitely add something like WHERE collection='entity.definitions.installed' AND name LIKE %.field_storage_definitions'.
My bigger concern is if this is too database specific or not. We might want to do a SELECT, do the replacement in php and do a separate UPDATE instead.
To sum up our findings with @siegrist:
Since this commit commerce's BundleFieldDefinition got deprecated in favor of the implementation of the entity module. This happened 7 years ago.
The issue is that the sites that existed before the deprecation might still have commerce's BundleFieldDefinition serialized in their field storage definition. See e.g. select * from key_value where collection='entity.definitions.installed' and name='commerce_payment_method.entity_type'; So when updating to DC 3.x these definitions start referring to a nonexistent class.
This affects pretty much all payment method types, profile types and product types as well.
@jsacksick Would it make sense for you to have an update hook in commerce core 2.x that updates these field storage definitions to use the entity module implementation instead? (Once you update to 3.x it's too late.) I haven't tried but just saving the entity type might recreate the field storage definitions as well.
This one is fixing 09be1f63ff32bbc154f74c7367cb18023f814113 to keep the speed gain. Probably this is the better approach.
That's partially reverting 09be1f63ff32bbc154f74c7367cb18023f814113.
czigor → created an issue. See original summary → .
Patch #2 makes sense and fixes the issue for me as well.
I just checked the site again and now the bug is gone. I've rebooted my laptop since the last try.
What I've found so far is that something goes wrong during the plugin annotation parsing.
When language-url is not found the following happens:
- When running
drush crthe annotation gets parsed inDrupal\Component\Annotation\Doctrine::parse(). This time the "[#" string gets a correctT_ATTRIBUTE (351)code which makes the annotation be parsed. Right after this the cache_discovery table contains the correct data for thelanguage_negotiation_pluginscid. - After this the cache_discovery table is emptied due to clearing the caches).
- After this when I go to any page the plugin definitions are rebuilt. This time the "[#" string gets a
T_COMMENT (387)code which makes the annotation be skipped. The cache entry will be an empty array.
Not sure yet why the difference is.
Experiencing this issue. I don't know what triggered it but now I can't get rid of it. The missing plugins it's complaining about is either language-url or block_page.
Adding D11 support.
They also offered that they could make name fields visible on the credit card form on their side. Because I have some concerns that the name we have in Drupal might not actually be the name on the credit card and it might be worse to have the wrong name as opposed to no name?
Yes, these two names might not necessarily coincide although at least in Hungary we have some rule that they should. (I.e. I cannot pay with my personal card if I ask for an invoice for some company.)
@Berdir Thanks for the review! Fixed the issues. Since VISA will stop working without 3DS, I think some boilerplate 3DS handling has its place in contrib.
Adding
$this->userStorage->resetCache();
before
$account = $this->userStorage->load(1);
$account->init = $account->mail = $account_values['mail'];
in \Drupal\Core\Installer\Form\SiteConfigureForm::submitForm() makes the issue go away.
Wondering whether this is a Drupal core issue.
We see this issue as well when running our tests on a site and it breaks our CI. However, I was not able to reproduce this on a minimal drupal install (where only commerce_payment_example was enabled).
@omarlopesino Do you know what the other modules or config is required to see this?
Let's remove the custom order item fields requirement.
czigor → created an issue. See original summary → .
The deprecation happens only from Drupal 10.3 so the MR fails.
czigor → created an issue.
czigor → created an issue.
czigor → created an issue.
czigor → changed the visibility of the branch 3413020-using-a-translatable to hidden.
czigor → made their first commit to this issue’s fork.
I get the same warning with composer behaving as it should but with a href="void(0); link to replace.
czigor → made their first commit to this issue’s fork.
This works.
In my case it turned out to be extra white space in front of a <?php tag. I used the regexp \s+<\?php to find such occurences in my codebase.
@ikphilip Looks like you have a similar issue.
I have a commerce add to cart form that fails like this. The MR in 🐛 Only set content-length header in specific situations Fixed does not solve the issue, I guess because the AJAX response has a 200 status for which Content-Length is still added after applying the MR.
@vaish In Drupal core < 10 this was not the case. The if condition is needed to not break backward compatibility.
Reroll.
Rerolling #14 for 10.1.x. in case someone else needs it too.
Committed, thanks!