Field preprocess makes broad assumptions about data structure, triggering fatal errors in PHP 8

Interesting points, thank you.

Makes no sense to me, unless you help me further with proper documentation.

> might apply a delta to the formatter, ..
What you said sounded a personal prediction or assumption to me.

Mind quoting and pointing it to an exact line of documentation? With proper and documented reasonings, not predictions or assumptions, of course.

AFAIK, Plugin ID, hence Formatters ID, is always a String, never Integer, as clearly noted here:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

If you were using an integer like deltas, you violated the contract, and integers also makes no sense for plugin IDs as numbers will easily conflict.

Unless I missed the obvious, of course.

For doc purposes, the plugin ID is called here:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

'#formatter' => $this->getPluginId(),

The contract is set in stone. Any violation of it in custom codes is possible, but not my responsibility.

'#formatter' => $this->getPluginId(),

The contract is set in stone. Any violation of it in custom codes is possible, but not my responsibility. If you were using an integer like deltas, you violated the contract, and integers also makes no sense for plugin IDs as numbers will easily conflict.

Thanks for the additional perspective. I was beginning to come to the same conclusion -- that this was likely a problem in custom code. On the surface, it had seemed that the Blazy module's use of strpos() to check if the formatter was of the Blazy family of formatters was an imprecise method -- i.e., why not use a Drupal API method to get the field definition formatter's pluginID, and then check if that formatter extends BlazyMediaFormatterBase? But maybe that seemed like overengineering?

Thanks for your continuing contribution to the Drupal contrib module ecosystem!

> to check if the formatter was of the Blazy family of formatters was an imprecise method...
String check is not only faster but also more efficient than class check for reasons:

• We have 6, or so, formatters (blazy_text, blazy_image, blazy_media, etc.) with different base classes. One string "blazy" check is inevitably better than multiple base class lookups or imports.
• Each base class may be extended by sub-modules, I avoided and was worried to leak Blazy specific features into sub-modules last time. I haven't recapped if such worries are still reasonable, though.

No Drupal APIs are involved for both checks, IMHO. They are both native.

Thank you for appreciation :)

Automatically closed - issue fixed for 2 weeks with no activity.