🇫🇷France @Toki

Patch #7 worked for me on Drupal 10.4.1 with Custom breadcrumbs 1.1.2 (English and French). Need to create one custom breadcrumb for each language.

Views Selective Filters → has an alpha version since April 24. Just installed and activated it and it works perfectly with Address country.

+1 for patch #30, worked perfectly on Drupal 10.3.9 and Gin Login 2.1.3

toki → created an issue.

toki → created an issue.

Patch #19 worked for me here, thanks!

I can't get uid from D7 node table.
I have tried this :

bibcite_migrate_bibliography.yml

id: bibcite_migrate_reference
label: Reference
migration_tags:
  - Drupal 6
  - Drupal 7
source:
  plugin: bibcite_reference
destination:
  plugin: entity:bibcite_reference
process:
  # Adtitional fields:
  # biblio_full_text
  # biblio_coins
  # biblio_md5
  # biblio_formats
  # biblio_sort_title
  title: title
  uid: uid
  created: created
  changed: changed
  bibcite_year:...

Reference.php

 public function query() {
    $query = $this->select('biblio', 'b');
    $query->join('node', 'n', 'b.vid = n.vid');
    $query->distinct();

    $query->fields('b');
    $query->fields('n',['uid','title','created','changed']);

    return $query;
  }
 /**
   * {@inheritdoc}
   */
  public function fields() {
    $fields = [
      'nid' => $this->t('Node ID'),
      'vid' => $this->t('Revision ID'),
      'uid' => $this->t('User ID (Author)'),
      'created' => $this->t('Created date'),
      'changed' => $this->t('Changed date'),
      'biblio_type' => $this->t('Type'),
      'biblio_number' => $this->t('Number'),
.....

I have just migrated 2500+ references from D7 Biblio to D10 Bibcite and uid is 0 for all of them.
If we change the yml file (uid: node_uid), we should also add something in the source plugin Reference.php?
Thanks for any tip here, migrate from Biblio is critical now that D7 EOL is close.

Has anyone managed to install the module and especially to create references under Drupal 10 using the DOI?

Several users are in dire need of this procedure, thank you for any additional information on the installation process through Composer and operation of this critical module for Bibcite.

When trying to require the dev version today (with minimum-stability on dev) on Drupal 10.3.5 :

$ composer require 'drupal/bibcite_crossref:2.0.x-dev@dev'

./composer.json has been updated
Running composer update drupal/bibcite_crossref
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - cache/array-adapter[1.0.0, ..., 1.0.1] require php ^5.6 || ^7.0 -> your php version (8.2.20) does not satisfy that requirement.
    - cache/array-adapter 1.1.0 requires psr/cache ^1.0 -> found psr/cache[1.0.0, 1.0.1] but the package is fixed to 3.0.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - cache/array-adapter[1.1.x-dev, ..., 1.2.0] require psr/cache ^1.0 || ^2.0 -> found psr/cache[1.0.0, 1.0.1, 2.0.0] but the package is fixed to 3.0.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - drupal/bibcite_crossref dev-2.0.x requires renanbr/crossref-client dev-main#2e1f52988eca031633823449a92baad3a40f7768 -> satisfiable by renanbr/crossref-client[dev-main].
    - drupal/bibcite_crossref 2.0.x-dev is an alias of drupal/bibcite_crossref dev-2.0.x and thus requires it to be installed too.
    - renanbr/crossref-client dev-main requires cache/array-adapter ^1.0 -> satisfiable by cache/array-adapter[1.0.0, ..., 1.2.0].
    - Root composer.json requires drupal/bibcite_crossref 2.0.x-dev@dev -> satisfiable by drupal/bibcite_crossref[2.0.x-dev (alias of dev-2.0.x)].

As stated in this comment ✨ Is there an upgrade path from Drupal 7 to Drupal 10? Active , migration seems broken (global settings) for me too. And I have no specific exceptions on D7 configuration.

Using drush commands to migrate items from D7 to D10, it fails indeed with Matomo.
Launching drush mim upgrade_d7_matomo_settings shows immediate error message : Drupal\Component\Plugin\Exception\PluginNotFoundException: The "migration" plugin does not exist.
The migrations folder is here, no problem, with its *.yml files for D6 and D7.
I have imported many other things before (Fields, Commerce, Bibliography...) so I guess my Migrate install is OK.
Last thing, if I try drush mim upgrade_d7_matomo_user_settings, it works.

UPDATE 2 : I finally managed to migrate all my orders with VAT from Drupal 7 thanks to the 2 patches in this issue. Thank you very much for this work which deserves to be implemented in the module (unless it is too "workaround"). On the other hand, the patch for shipping VAT could not be applied with the patch command (failed), I had to apply it manually.

UPDATE : I have applied the first patch (handle-vat) and launch order_item and order migrations again and I can confirm it's working fine, I have all my order items now even if VAT was applied on D7.
Now I need to test the shipping_vat patch since calculation is wrong as mentioned in the previous comment from grahl.

I need to migrate a Drupal 7 site to Drupal 10 and I have problems with VAT as mentioned on this topic (I haven't tried the patches yet).

The D7 site has Commerce 1 and the D10 site has Commerce 2.
The D7 site manages VAT with the commerce_eu_vat and commerce_vat modules (I need to calculate VAT for orders in France).
The D10 site is managed with Commerce Core which now has autonomous tax management.

The majority of migrations went well (with Commerce Migrate of course, Migrate Upgrade, Migrate Tools, Migrate Plus via drush) except upgrade_commerce1_order_item_product which ignores almost 20% of the items because of an error linked to the adjustments?
Here is the message:
upgrade_commerce1_order_item_product:adjustments: Unknown adjustment type for line item '18082' (for example).

By checking a few of these lines, I found a VAT for France each time.
Upstream, I migrated the fields (upgrade_d7_field) and the commerce_fr_vat field (VAT rate reference field type) was not migrated either.
Here is the Migration error message :
Attempt to create a field storage commerce_fr_vat with no type. (/public_html/my_website/web/core/modules/field/src/Entity/FieldStorageConfig.php:271).

How to solve this situation and migrate 100% of order_items from the Drupal 7 site?
Is it the commerce_fr_vat field from my Product type or do we need to modify something in the migration configuration file (commerce1_order_item.yml)?

Looking at the patches, it does not seem to create any VAT field or something related to?

Thanks for any help here, the D7 site is ten years old, you can imagine the amount of orders with VAT rates I need to migrate and I would really appreciate to find an automatic solution.

+1, got the same issue with Olivero and a View with Unformatted list display and mini pager settings. A Grid display is set to view and view-content classes but view-filters is included in view, so filters appear on the left and content on the right. Maybe a simple CSS edit on views.css?

I tried several times to get the PDF module to work...
Now I am using PDF Reader → on Drupal 10 and everything goes well out of the box.

Toki → created an issue.

Toki → created an issue.

It seems there is no difference between database abstract values from Biblio D7 and Bibcite D10. But in bibcite, format is defined in a second column (bibcite_abst_e__format) and NULL values are displayed after migration. If I save the bibcite reference from UI, text format is detected and NULL value disappears.
So I guess one line is missing in the migration process about format?
Anyway, for the moment, as a workaround for abstracts, I will save references just after migration to force the format column to be filled.

Concerning bibcite_notes, in Bibcite, this is a Longtext field without any format whereas it's a formatted text in Biblio.
For the moment, I will use Feeds to import these notes from Biblio inside a custom field with formatted text type so HTML tags will be displayed properly as my client needs.
Perhaps in the future this bibcite_notes field could be updated to accept format?

For any purpose, this is what I have for one example on target (D10 Bibcite) in the database (html tags on abstracts and notes). Views displays what you can see on screenshot "ref-bibcite-views-d10.png".

INSERT INTO `bibcite_reference` (`id`, `revision_id`, `type`, `uuid`, `langcode`, `status`, `title`, `uid`, `bibcite_abst_e__value`, `bibcite_abst_e__format`, `bibcite_abst_f__value`, `bibcite_abst_f__format`, `bibcite_notes`, `bibcite_custom1`, `bibcite_custom2`, `bibcite_custom3`, `bibcite_custom4`, `bibcite_custom5`, `bibcite_custom6`, `bibcite_custom7`, `bibcite_auth_address`, `bibcite_year`, `bibcite_secondary_title`, `bibcite_volume`, `bibcite_edition`, `bibcite_section`, `bibcite_issue`, `bibcite_number_of_volumes`, `bibcite_number`, `bibcite_pages`, `bibcite_date`, `bibcite_type_of_work`, `bibcite_lang`, `bibcite_reprint_edition`, `bibcite_publisher`, `bibcite_place_published`, `bibcite_issn`, `bibcite_isbn`, `bibcite_accession_number`, `bibcite_call_number`, `bibcite_other_number`, `bibcite_url`, `bibcite_doi`, `bibcite_research_notes`, `bibcite_tertiary_title`, `bibcite_short_title`, `bibcite_alternate_title`, `bibcite_translated_title`, `bibcite_original_publication`, `bibcite_other_author_affiliations`, `bibcite_remote_db_name`, `bibcite_remote_db_provider`, `bibcite_label`, `bibcite_access_date`, `bibcite_refereed`, `bibcite_pmid`, `created`, `changed`)
VALUES
	(1, 1, 'journal_article', '480303b4-8cc6-47bb-bb23-bcab863965ad', 'fr', 1, 'Updated checklist of the freshwater and estuarine fishes of French Guiana', 0, '<p>The fish fauna of French Guiana is among the best known of South America. Various fieldwork campaigns have been conducted since the publication of the “Atlas des poissons d’eau douce” de Guyane, particularly in poorly surveyed areas, leading to the discovery of new taxa, and numerous scientific publications have provided new insights concerning this fauna. An updated checklist of the fishes of French Guiana, including all of this new information, is therefore desirable. The list contains 416 species, 367 of which are strictly freshwater. Fish diversity is strongly correlated with catchment size and is, on average, higher in French Guiana than in Suriname. The largest groups are the Characiformes (41{%}), Siluriformes (33{%}) and Perciformes (13{%}). The relative abundance of taxonomic groups differs between catchments, probably reflecting the ecological character of the rivers. Eighty seven species, around a quarter of the ichthyofauna, are listed as endemic, but this may be an underestimate because a rather strict definition of endemism is used. The rate of endemism is strongly correlated with catchment size, with some families showing higher than average rates. Comparison of the number of species shared by the different catchments suggests a highly complex pattern of dispersal as a function of the catchment size, topography, and species. The Oyapock River seems to belong to a relatively distinct biogeographic zone influenced by the Amazon basin, but it is not possible to show a broader trend. These results provide an additional tool for environmental managers and decision makers.</p>\r\n', NULL, NULL, NULL, '<p><strong>How to cite</strong>:&nbsp;Le Bail, P.-Y., Covain, R., Jégu, M., Fisch-Muller, S., Vigouroux, R., &amp; Keith, P. (2012). Updated checklist of the freshwater and estuarine fishes of French Guiana. <em>Cybium</em>, 36(1): 293-319. https://doi.org/10.26028/CYBIUM/2012-361-016</p>\r\n', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 2012, 'Cybium', '36', NULL, NULL, NULL, NULL, '1', '293-319', NULL, NULL, 'eng', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 'https://doi.org/10.26028/cybium/2012-361-016', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 1695376428, 1712854272);

And this is the same example in the source (D7 Biblio). Views displays screenshot "ref-biblio-views-d7.png"

INSERT INTO `biblio` (`nid`, `vid`, `biblio_type`, `biblio_number`, `biblio_other_number`, `biblio_sort_title`, `biblio_secondary_title`, `biblio_tertiary_title`, `biblio_edition`, `biblio_publisher`, `biblio_place_published`, `biblio_year`, `biblio_volume`, `biblio_pages`, `biblio_date`, `biblio_isbn`, `biblio_lang`, `biblio_abst_e`, `biblio_abst_f`, `biblio_full_text`, `biblio_url`, `biblio_issue`, `biblio_type_of_work`, `biblio_accession_number`, `biblio_call_number`, `biblio_notes`, `biblio_custom1`, `biblio_custom2`, `biblio_custom3`, `biblio_custom4`, `biblio_custom5`, `biblio_custom6`, `biblio_custom7`, `biblio_research_notes`, `biblio_number_of_volumes`, `biblio_short_title`, `biblio_alternate_title`, `biblio_original_publication`, `biblio_reprint_edition`, `biblio_translated_title`, `biblio_section`, `biblio_citekey`, `biblio_coins`, `biblio_doi`, `biblio_issn`, `biblio_auth_address`, `biblio_remote_db_name`, `biblio_remote_db_provider`, `biblio_label`, `biblio_access_date`, `biblio_refereed`, `biblio_md5`, `biblio_formats`)
VALUES
	(63, 63, 102, '1', '', 'Updated checklist of the freshwater and estuarine fishes of Fren', 'Cybium', NULL, NULL, '', NULL, 2012, '36', '293-319', NULL, '', 'eng', '<p>The fish fauna of French Guiana is among the best known of South America. Various fieldwork campaigns have been conducted since the publication of the “Atlas des poissons d’eau douce” de Guyane, particularly in poorly surveyed areas, leading to the discovery of new taxa, and numerous scientific publications have provided new insights concerning this fauna. An updated checklist of the fishes of French Guiana, including all of this new information, is therefore desirable. The list contains 416 species, 367 of which are strictly freshwater. Fish diversity is strongly correlated with catchment size and is, on average, higher in French Guiana than in Suriname. The largest groups are the Characiformes (41{%}), Siluriformes (33{%}) and Perciformes (13{%}). The relative abundance of taxonomic groups differs between catchments, probably reflecting the ecological character of the rivers. Eighty seven species, around a quarter of the ichthyofauna, are listed as endemic, but this may be an underestimate because a rather strict definition of endemism is used. The rate of endemism is strongly correlated with catchment size, with some families showing higher than average rates. Comparison of the number of species shared by the different catchments suggests a highly complex pattern of dispersal as a function of the catchment size, topography, and species. The Oyapock River seems to belong to a relatively distinct biogeographic zone influenced by the Amazon basin, but it is not possible to show a broader trend. These results provide an additional tool for environmental managers and decision makers.</p>\r\n', '', 0, '', NULL, '', '', '', '<p><strong>How to cite</strong>:&nbsp;Le Bail, P.-Y., Covain, R., Jégu, M., Fisch-Muller, S., Vigouroux, R., &amp; Keith, P. (2012). Updated checklist of the freshwater and estuarine fishes of French Guiana. <em>Cybium</em>, 36(1): 293-319. https://doi.org/10.26028/CYBIUM/2012-361-016</p>\r\n', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 'LeBailP.Y.2012', '<span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&amp;rft.atitle=Updated+checklist+of+the+freshwater+and+estuarine+fishes+of+French+Guiana&amp;rft.title=Cybium&amp;rft.date=2012&amp;rft.volume=36&amp;rft.spage=293&amp;rft.epage=319&amp;rft.aulast=Le+Bail&amp;rft.aufirst=Pierre-Yves&amp;rft.au=Covain%2C+Rapha%C3%ABl&amp;rft.au=J%C3%A9gu%2C+Michel&amp;rft.au=Fisch-Muller%2C+Sonia&amp;rft.au=Vigouroux%2C+R%C3%A9gis&amp;rft.au=Keith%2C+Philippe&amp;rft_id=info%3Adoi%2Fhttps%3A%2F%2Fdoi.org%2F10.26028%2Fcybium%2F2012-361-016\"></span>', 'https://doi.org/10.26028/cybium/2012-361-016', NULL, NULL, NULL, NULL, NULL, NULL, NULL, '2bd1c12018875082b2bb47823104a07c', X'613A31333A7B733A31333A226269626C696F5F616273745F65223B733A31333A2266696C74657265645F68746D6C223B733A31333A226269626C696F5F616273745F66223B733A31333A2266696C74657265645F68746D6C223B733A31323A226269626C696F5F6E6F746573223B733A31333A2266696C74657265645F68746D6C223B733A32313A226269626C696F5F72657365617263685F6E6F746573223B733A31333A2266696C74657265645F68746D6C223B733A31343A226269626C696F5F637573746F6D31223B733A31333A2266696C74657265645F68746D6C223B733A31343A226269626C696F5F637573746F6D32223B733A31333A2266696C74657265645F68746D6C223B733A31343A226269626C696F5F637573746F6D33223B733A31333A2266696C74657265645F68746D6C223B733A31343A226269626C696F5F637573746F6D34223B733A31333A2266696C74657265645F68746D6C223B733A31343A226269626C696F5F637573746F6D35223B733A31333A2266696C74657265645F68746D6C223B733A31343A226269626C696F5F637573746F6D36223B733A31333A2266696C74657265645F68746D6C223B733A31343A226269626C696F5F637573746F6D37223B733A31333A2266696C74657265645F68746D6C223B733A31323A226269626C696F5F636F696E73223B733A31333A2266696C74657265645F68746D6C223B733A31393A226269626C696F5F617574685F61646472657373223B733A31333A2266696C74657265645F68746D6C223B7D');

I have just tried to save one bibcite reference from UI and the abstract is now HTML tags free. The bibcite_abs_e__format column in the bibcite_reference table is now filled (filtered_html). So I guess if I save all references again they will apply the default text format from Abstract field? For Notes, this workaround will not work, the bibcite field is not formatted (raw text). Is there a way to edit the field type for bibcite_notes or to format values in Views?

Toki → created an issue.

I have the same problem here after migration from D7 to D10 with references imported from Bibliography module (D7). Abstract (both english and french) and Notes (missing on the patch) are now in plain text in the database with html markups everywhere. I can't find a way to render them correctly, even with Views. I will try soon the patch and see if a new migration could solve this issue.

@pftech, thank you for time on this tutorial.

Unfortunately, I still get the blank viewer with this message twice, on pdf.mjs and viewer.mjs :

Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "". Strict MIME type checking is enforced for module scripts per HTML spec.

May I ask which version of pdf.js you have used? in my example, I tried with the latest, 4.0.379.
The .htaccess you mentioned is the one in sites/default/files?
Could you be more precise on the 3b step : add AddType application/javascript? Maybe share your .htaccess file?
Have you set something special for the custom path to viewer.html (at admin/config/media/pdfjs)?

Thanks for any tip here.

Toki → created an issue.

Thank you for this big update.
I tested on a fresh website with ECA and the change made for the translation fulfills exactly the role I expected. I was able to create a template then translate it in full (subject, title, etc.) and when I add a Send Easy Email action on ECA, if the event triggers from the English version, the email sent is the one translated into English. If the event triggers from the French version, it is the email in French which arrives in the targeted mailbox. No more need to create 2 different email templates and add a test on the language of the site to send translated emails from ECA. The model is considerably simplified and pragmatic. Thanks again!

First of all, thank you for this module, it becomes more and more a "must-have" module in Drupal.

I had a requirement to setup a model that performs a queued operation to send out e-mails to multiple users, and each user may have a different preferred language. Of course the sent out mails need to be translated in the proper language.

I have the exact same case than you @mxh but I can't build the right model.
Do you mind sharing your solution or a few guidelines?

Some details : I am using Easy Email to send HTML emails and custom templates. Unfortunately they can't be translated through the Drupal configuration translation UI so I thought I can create two different email templates (one for each language) and then decide which one to send with ECA and user's preferred language.

Here is a case where email templates translation is important: I am using ECA and Easy Email to send HTML email to an user who has just created their account on a bilingual site and I need the email to be in the interface language during registration.
If I activate content translation for emails, I can see the list of template fields (To, BC, Body...) but if I go to the translation tab of my template, I can only translate the title of the template (which is visible only for admin).
Is there a configuration that I'm missing or will I be forced to create two templates (one for each language) and create two paths of actions on my ECA model, with a condition based on the interface language during registration?

That looks really promising, I will definitely try this tomorrow!
Thanks for the advice.

Thank you for your reply, I understand your point.
Maybe ECA maintainers have an answer for this?

Working with Drupal 10.1.4, symfony_mailer 1.4.0.-beta1 and ECA 1.1.4
I don't know if my feedback as an humble site builder can help but the patch created by jurgenhaas in #2 and then corrected by s.sinitsa in #11 does indeed work, while the more elaborate patch in #34 crashed my ECA model test (cf screenshot eca-model-test.png).
In my case, I will need to send several emails depending on the status of a node set by Workflow module and these emails will contain information from tokens that I want to see formatted in HTML and not in plain text (and also attachments if possible).
With patch #11 and its related action "Send HTML Email" (second task on ECA model test), I was able to receive HTML Email (cf screenshot html-email.png) whereas with the basic action "Send an email" offered by default by ECA (first task on ECA model test) I received an unformatted email (cf screenshot standard-email.png).
Is this issue still on?

While visiting the Drupal Slack migration group, I came across another user who recently was also unable to recover his Workflow between D7 and D10. After a week of research and testing, I finally gave up on the idea of recovering my Workflow configuration. So I finally used the excellent Migrate Skip Fields → module and deleted my Workflow field on the target site. The migration process for the nodes associated with the workflow was unblocked and I was able to recover them. Now I'm going to edit these nodes with a new fresh workflow and some SQL or Views Bulk Operations queries.

Digging further into the files triggered by upgrade_d7_workflow_config_transition, I traced back to the d7_user_role.yml file where the permissions associated with each role are retrieved in the role_permission (D7) table.
However, from the first line of this table, the permission is linked to a module (biblio) which is no longer available on Drupal 10 and which has been replaced by another with a different machine name (bibcite).
It is therefore very likely that the process will fail because of this.
I traced the problem to this thread → (see related issue).
Roles in D10 site are already set and the permissions will probably evolve and be managed manually.
Would it be possible to simply modify the d7_workflow_config_transition.yml file so as not to trigger d7_user_role and thus unlock the situation?

Thanks for your time anyway.

Indeed, I have tried to understand where something goes wrong in both WorkflowConfigTransition.php or d7_workflow_config_transition.yml.
I will continue to look for the error in my case.

After upgrade_d7_workflow, upgrade_d7_workflow_state and failed upgrade_d7_workflow_config_transition, workflow and its states are in config table but only one transition (xxxx_creation) appears.

In D10 UI, I can't see any settings on creation state when adding new workflow? Only label, permissions, form settings and watchdog.

I am pretty confident someone has already managed to migrate workflow configuration from Drupal 7 to Drupal 10, so please if you are this person, feel free to share your experience :)

If it's OK with you johnv, I change the status to Active.

Any idea?
Could it be the new states machine name patterns?
If I am correct now it is workflow_name_state_name so my first default state went from creation to manuscrit_creation.
And if I try to enter manually my D7 states, machine names are automatically created and untouchable.

It worked here from D7 to D10, only with this core version requirement modification.

Toki → created an issue.

Just one more precision, users and user roles have been imported first, of course.

Concerning the error linked to upgrade_d7_workflow_config_transition (with NULL values apparently), I have also checked the workflow_transitions on source site (d7) and I have data, notably in roles column (see capture).

Sorry but still an issue.

upgrade_d7_workflow : no problem, my workflow named "manuscrit" is imported from D7 to D10.

upgrade_d7_workflow_state : 12 states are imported but from here if I try to open /admin/config/workflow/workflow/manuscrit/transition_roles I get a wsod with this error in the log :

Drupal\Core\Entity\EntityStorageException: 'workflow_config_transition' entity with ID 'manuscrit_creation' already exists. in Drupal\Core\Entity\EntityStorageBase->doPreSave() (line 519 of /home/my_d10_website/public_html/my_d10_website_root/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php).

then, I have tried upgrade_d7_workflow_config_transition : 44 failed with this error for each in Migrate Tools UI :

upgrade_d7_workflow_config_transition:roles:migration_lookup: flatten: Input should be an array or an object, instead it was of type 'NULL'

finally, tried upgrade_d7_workflow_transition (with both patch #3 and modification #8) :

[warning] array_flip(): Can only flip string and integer values, entry skipped EntityStorageBase.php:278
 [warning] Array to string conversion EntityStorageBase.php:142
 [error]  TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load() (line 263 of /home/my_d10_website/public_html/my_d10_website_root/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php) #0 /home/my_d10_website/public_html/my_d10_website_root/web/core/lib/Drupal/Core/Entity/EntityBase.php(488): Drupal\Core\Entity\EntityStorageBase->load()
(...)
TypeError: Illegal offset type in /home/my_d10_website/public_html/my_d10_website_root/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php on line 263 #0 /home/my_d10_website/public_html/my_d10_website_root/web/core/lib/Drupal/Core/Entity/EntityBase.php(488): Drupal\Core\Entity\EntityStorageBase->load()
(...)
TypeError: Illegal offset type in Drupal\Core\Entity\EntityStorageBase->load() (line 263 of /home/my_d10_website/public_html/my_d10_website_root/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php).
 [warning] Drush command terminated abnormally.

Thanks for your time.

Yesterday, I have applied the patch in #3 manually and the original error message has disappeared, leading to the second one in #4.

I have just checked "my" workflow.migrate.inc file and surprisingly there is no use statement line 8 (that explains the line 39/line 41 difference).
Let me go back to you after a new test.

I added the related issue because there was some similarity with this issue but if it does not help I can delete it from here.

Here si the message in Migrate Tools UI for each new fail for upgrade_d7_workflow_config_transition :

upgrade_d7_workflow_config_transition:roles:migration_lookup: flatten: Input should be an array or an object, instead it was of type 'NULL'

Thanks for the quick answer.
I can't find that patch this morning.
I have just tried it but unfortunately a new error appears :

 [error]  Error: Class "WorkflowState" not found in workflow_migrate_upgrade_d7_workflow_transition_prepare_row() (line 39 of /home/my_d10_website/public_html/my_d10_website_root/web/modules/contrib/workflow/workflow.migrate.inc) #0 [internal function]: workflow_migrate_upgrade_d7_workflow_transition_prepare_row()
#1 /home/my_d10_website/public_html/my_d10_website_root/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(409): call_user_func_array()
(...)
#28 {main}. 
Error: Class "WorkflowState" not found in /home/my_d10_website/public_html/my_d10_website_root/web/modules/contrib/workflow/workflow.migrate.inc on line 39 #0 [internal function]: workflow_migrate_upgrade_d7_workflow_transition_prepare_row()
#1 /home/my_d10_website/public_html/my_d10_website_root/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(409): call_user_func_array()
(...)
#28 {main}
Error: Class "WorkflowState" not found in workflow_migrate_upgrade_d7_workflow_transition_prepare_row() (line 39 of /home/my_d10_website/public_html/my_d10_website_root/web/modules/contrib/workflow/workflow.migrate.inc).
 [warning] Drush command terminated abnormally.

Toki → created an issue.

+1 RTBC

Actually I got the same error here after trying to update database through Drush cr and I am working on PHP 8.1.20 and Commerce 2.36.

ParseError: syntax error, unexpected 'protected' (T_PROTECTED), expecting variable (T_VARIABLE) in Composer\Autoload\{closure}() (line 26 of /home/my_website/public_html/modules/contrib/commerce/modules/checkout/src/EventSubscriber/GuestCheckoutCompletionSubscriber.php)
#0 /home/my_website/public_html/vendor/composer/ClassLoader.php(433): Composer\Autoload\{closure}()
#1 [internal function]: Composer\Autoload\ClassLoader->loadClass()
#2 [internal function]: spl_autoload_call()
#3 /home/my_website/public_html/core/lib/Drupal/Core/DependencyInjection/Compiler/RegisterEventSubscribersPass.php(30): ReflectionClass->__construct()
#4 /home/my_website/public_html/vendor/symfony/dependency-injection/Compiler/Compiler.php(94): Drupal\Core\DependencyInjection\Compiler\RegisterEventSubscribersPass->process()
#5 /home/my_website/public_html/vendor/symfony/dependency-injection/ContainerBuilder.php(762): Symfony\Component\DependencyInjection\Compiler\Compiler->compile()
#6 /home/my_website/public_html/core/lib/Drupal/Core/DrupalKernel.php(1351): Symfony\Component\DependencyInjection\ContainerBuilder->compile()
#7 /home/my_website/public_html/core/lib/Drupal/Core/DrupalKernel.php(948): Drupal\Core\DrupalKernel->compileContainer()
#8 /home/my_website/public_html/core/lib/Drupal/Core/Update/UpdateKernel.php(42): Drupal\Core\DrupalKernel->initializeContainer()
#9 /home/my_website/public_html/vendor/drush/drush/src/Drupal/DrupalKernelTrait.php(69): Drupal\Core\Update\UpdateKernel->initializeContainer()
#10 /home/my_website/public_html/core/lib/Drupal/Core/DrupalKernel.php(487): Drush\Drupal\UpdateKernel->initializeContainer()
#11 /home/my_website/public_html/vendor/drush/drush/src/Boot/DrupalBoot8.php(241): Drupal\Core\DrupalKernel->boot()
#12 /home/my_website/public_html/vendor/drush/drush/src/Boot/BootstrapManager.php(293): Drush\Boot\DrupalBoot8->bootstrapDrupalFull()
#13 /home/my_website/public_html/vendor/drush/drush/src/Boot/BootstrapManager.php(447): Drush\Boot\BootstrapManager->doBootstrap()
#14 /home/my_website/public_html/vendor/drush/drush/src/Boot/BootstrapManager.php(396): Drush\Boot\BootstrapManager->bootstrapToPhaseIndex()
#15 /home/my_website/public_html/vendor/drush/drush/src/Boot/BootstrapHook.php(28): Drush\Boot\BootstrapManager->bootstrapToPhase()
#16 /home/my_website/public_html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php(44): Drush\Boot\BootstrapHook->initialize()
#17 /home/my_website/public_html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php(36): Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->doInitializeHook()
#18 /home/my_website/public_html/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php(29): Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook()
#19 /home/my_website/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(145): Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize()
#20 /home/my_website/public_html/vendor/consolidation/annotated-command/src/AnnotatedCommand.php(376): Consolidation\AnnotatedCommand\CommandProcessor->initializeHook()
#21 /home/my_website/public_html/vendor/symfony/console/Command/Command.php(221): Consolidation\AnnotatedCommand\AnnotatedCommand->initialize()
#22 /home/my_website/public_html/vendor/symfony/console/Application.php(1039): Symfony\Component\Console\Command\Command->run()
#23 /home/my_website/public_html/vendor/symfony/console/Application.php(275): Symfony\Component\Console\Application->doRunCommand()
#24 /home/my_website/public_html/vendor/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun()
#25 /home/my_website/public_html/vendor/drush/drush/src/Runtime/Runtime.php(118): Symfony\Component\Console\Application->run()
#26 /home/my_website/public_html/vendor/drush/drush/src/Runtime/Runtime.php(48): Drush\Runtime\Runtime->doRun()
#27 /home/my_website/public_html/vendor/drush/drush/drush.php(72): Drush\Runtime\Runtime->run()
#28 /home/my_website/public_html/vendor/drush/drush/drush(3): require('/home/my_website/pu...')
#29 /home/my_website/public_html/vendor/bin/drush(115): include('/home/my_website/pu...')
#30 {main}

My mistake, I have edited manually the file on PHPStorm.
After adding the modifications line 31, use lines have been added automatically.
With my manual add on EntityTypeManager, I got an error message on drush about an "use" already done.
So the patch is completely fine!

This is a critical issue in my opinion since no one can order because of that (I got the exact same issue with wsod).
I have just patched the module with #2 (but without the use on line 8 since there is already a call to EntityTypeManager) and it seems OK now.

@DrupalDope
De rien !
(You're welcome!)

I had the same error message last week and it was related to a contrib module "Permissions by Term".
See this issue here : https://www.drupal.org/project/drupal/issues/3358534 🐛 Twig template not defined, LoaderError Closed: duplicate

Yes it seems this is an error related to Permissions by Term module and it should be fixed soon.
In my case, a downgrade from 3.1.22 to 3.1.21 was enough to fix this issue (still got some errors but it is my fault, I have modified so many things on my dev website during my investigation!)
Thank you for pointing me to the backtrace information.

The backtrace is so useful to investigate...
It seems to be linked to Permissions by Term module (recent update).
A patch is on its way.
I have attached issues to that one, if it can help someone else.

Toki → created an issue.

Hi, I have the same problem here, for two customers who tried to pay with a credit card.
Would you please explain how you fixed it?

@nojj Are you sure it is fixed by the Symfony Mailer dev version?
Until I have switched from SwiftMailer to Symfony mailer, I can not get Commerce Invoice attaching invoices to emails.
I am working on Drupal 9.5 (on PHP 8.1) with Commerce invoice 2.0-rc3 and Symfony Mailer 1.x-dev.
As it worked on drupal test website, I have uninstalled Mail System and SwiftMailer (emails are fine globally).

Drupal log sent this message (Type : commerce_invoice) :

RuntimeException: Failed to start the session because headers have already been sent by "/home/my-website/public_html/vendor/symfony/http-foundation/Response.php" at line 1239. in Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->start() (line 152 of /home/my-website/public_html/vendor/symfony/http-foundation/Session/Storage/NativeSessionStorage.php).

Thanks for any tip here.

OK, great, thanks for answering.

Same issue here (like @Libbna).
I have modified the composer.json file in recaptcha folder ("drupal/captcha": "^1.4 || ^2",).
I have rebuilt caches (drush cr).
I have tried to require the D10 compatible captcha version (composer require drupal/captcha:^2.0@beta).
Same error message than @Libbna.
Is there another step to let recatpcha accept the captcha 2.0 version?
Should I uninstall and re-install ReCaptcha?

Same issue here today. @jshosseini Have you found a solution? Thanks

Within the previous bilbiography Drupal 7 module (Biblio), that kind of sorting was available in Views thanks to the bilbio_handler_sort_contributor_lastname.inc file.

Does someone has any idea where to start to "convert" this code into Drupal 9/Symfony code?
And sorting by the first rank author would be probably enough here, no need for the rank_options function.

<?php

/**
 *
 */
class biblio_handler_sort_contributor_lastname extends views_handler_sort {

  /**
   *
   */
  public function option_definition() {
    $options = parent::option_definition();

    $options['rank'] = array('default' => 0);
    return $options;
  }

  /**
   *
   */
  public function admin_summary() {
    $order = parent::admin_summary();
    $rank = $this->rank_options();
    return $rank[$this->options['rank']] . ' ' . t('Author') . ', ' . $order;
  }

  /**
   *
   */
  public function options_form(&$form, &$form_state) {
    parent::options_form($form, $form_state);
    $form['op_val_start'] = array('#value' => '<div class="clearfix">');
    $form['rank'] = array(
      '#title' => t('Sort by which author?'),
      '#type' => 'select',
      '#options' => $this->rank_options(),
      '#default_value' => $this->options['rank'],
    );
    $form['op_val_end'] = array('#value' => '</div>');

  }

  /**
   *
   */
  public function rank_options() {
    return array('1st', '2nd', '3rd', '4th', '5th');
  }

  /**
   *
   */
  public function query() {
    parent::query();
    $this->query->add_where(0, "biblio_contributor.rank", $this->options['rank'], '=');
  }

}

Toki → created an issue.

And just to confirm what @johnnny83 wrote in his question on Drupal Answers, when adding a Contributor relationship, each reference is displayed as many times as it has authors. Even with Aggregation activated, the issue is still here. Using the short code above, as we filter by only the first author (delta = 0), the issue disappears but it sounds like a workaround to avoid a deeper problem?
Let us know how we can help, at our humble level.

Hi @AardWolf

Thanks for testing alternatives here.
Actually I have managed to get a view sorted by year and then secondly by first author last name, thanks to the code suggested by @antongp (I have started with that in comment #8).
My issue here is to get rid of the condition on delta=0 because if I expose a filter on last name author I can't get people which are never first author (my client's request).
So I was wondering how to build a custom sort based on this delta column in bibcite_reference_author in relation with last_name in bibcite_contributor.

Toki → created an issue.

This is great news, many thanks, don't hesitate if you need some testing from a humble site builder.

I suppose the SQL query is this one :
SELECT last_name FROM bibcite_contributor LEFT JOIN bibcite_reference__author ON bibcite_contributor.id=bibcite_reference__author.author_target_id WHERE bibcite_reference__author.delta=0
Now it would be nice to get this information for each row of the View and use the result as sorting criteria.
Anyone?
This feature is critical for any end-user, unsorted bibliography is a bit useless, I'm afraid.
Something else, when I use the contributor in a relationship to access last_name, I need to aggregate results.
If not, each reference is repeated for each author.
And finally, when displaying a contributor field to get the last_name, the result for each reference is chaotic, once it is the first author last name, once it is the third author last name, etc.
I am more and more lost...

Hello @antongp

I added the mini-module defined above (#2) and indeed the sorting is good.
Now I have a problem because my exposed filter on the author name only works on the first author since the condition imposes the delta to zero.
Would it be possible to have some code to sort the view without adding a filter?
I need some help to start this little code.
I imagine we can start with $query->set('order',$first_author) where $first_author is the bibcite_reference__author where delta is 0? and then $query->set('order','asc')?
I am not quite sure how to get the $first_author though.
Thanks for any tip here.