I'm afraid issue #3037956 (empty values) is a far too away from my very case (string or integer) . Proposing to reopen.
When using EntityStorageBase->loadMultiple() with entity reference fields in PHP 8.4, a warning is thrown when target_id values are passed as strings instead of integers.
Problem
The warning occurs in EntityStorageBase->loadMultiple() at line 279 when array_flip() encounters non-integer/non-string values. The issue arises when entity reference field values have target_id stored as strings rather than integers.
Warning Message
Warning: array_flip(): Can only flip string and integer values, entry skipped in Drupal\Core\Entity\EntityStorageBase->loadMultiple() (line 279 of core/lib/Drupal/Core/Entity/EntityStorageBase.php).
Steps to Reproduce
Have an entity reference field with target_id values stored as strings
Call $entity_reference_field->referencedEntities()
Observe the warning in PHP 8.4
Code Example
php
// This produces error when target_id is string
$data['references'] = $data['event_target_entity_reference']->referencedEntities();
// Fix: Ensure target_id is integer
foreach ($data['event_target_entity_reference'] as $k => $v) {
$data['event_target_entity_reference'][$k] = ['target_id' => (int) $v->target_id];
}
// This works without error
$data['references'] = $data['event_target_entity_reference']->referencedEntities();
Proposed Solution
The target_id values should consistently be integers as expected by the entity reference system. The issue might be in:
Data storage layer: Ensure target_id is always stored and retrieved as integer
Entity reference field handler: Add type casting in referencedEntities() method
Input validation: Validate target_id type during entity save/update
Environment
PHP 8.4
Drupal Core (version)
Entity Reference fields
Additional Notes
The stricter type handling in PHP 8.4 exposes this type inconsistency that might have been silently tolerated in earlier PHP versions. The target_id should indeed always be integer values for entity references.
I'm reading this documentation and I'm confused about the intended use of H1 tags.
Could you clarify if H1 tags should be used to define:
Mandatory consecutive steps in a process,
OR
Alternative configuration choices
From HTML standards, H1 tags define the main heading and document structure rather than procedural steps or choices. Some clarification on the intended convention in this context would be very helpful for proper implementation.
Thank you!
Hi!
Can you please add here reference with related outdated issues?
Thanks
Not on my latest updated BAT instance.
Can you please confirm everything is up to date on your side?
Interesting,
Can you please confirm your having same issue at today lastest?
Worth to say this is good also for today latest Drupal 11
Answering to #5, in Drupal you can:
* install REST UI module (drush en restui or open /admin/modules > enable "Rest UI" )
* open /admin/config/services/rest config page
* enable both paths /bat_api/rest/calendar-events: GET and /bat_api/rest/calendar-units: GET
This is actual error message
{"message":"No route found for \u0022GET https:\/\/WEBSITE\/bat_api\/rest\/calendar-units\u0022"}
this happened on
https://www.drupal.org/project/commerce_account_balance/releases/1.0.3 →
where .module file was wrongly doubled
This merge request is ready for your review.
Thanks in advance!
afagioli → created an issue.
#7 in interesting indeed.
Do you see something to do in this very drupal module?
afagioli → created an issue.
Thanks a lot for contribuiting.
We are now moving forward with release 2.x
afagioli → created an issue.
afagioli → created an issue.
Can you please report a few recent lines from your favourite log?
This issue is about a multi-features module, not a report.
I believe views can report commerce entities in several different ways
"This gets quite tedious"
Not sure "tediousness" can be an issue.
Multi-step uninstall is pretty common to me. I find this process useful instead to better understand how that Drupal instance is made of.
Following though..
afagioli → created an issue.
afagioli → created an issue.
afagioli → created an issue.
following
To whom it may concern, dbout sponsorship, I read this on project page
"Development proudly sponsored by German Drupal Friends & Companies:
webks: websolutions kept simple (https://www.webks.de)
and
DROWL: Drupalbasierte Lösungen aus Ostwestfalen-Lippe (OWL), Germany (https://www.drowl.de)
Supporting organizations:
DROWL.de
proudly developed the original Drupal 7 module for the community!"
As things are today, Should we maybe update this?
If conversation gets complicated, I 'll open a separate issue of course
Thanks Anybody
"Please stick to Drupal best practices and coding standards."
Sure thing! Your support will make the difference
Best!
following
afagioli → created an issue.
I'm already using the project and I want it to be well-maintained.
Sorry to see this module is still so far back.
Can we somehow move forward?
refreshing...
Doc link at #3 gives "404 - Not found"
Thanks for accepting