TypeError: Argument 1 passed to Drupal\simple_sitemap\Form\Handler\EntityFormHandlerBase::isSupportedOperation() must be of the type string, null given

Just reporting that I ran into the same issue here with a custom entity.

Hello,

f you don't mind I reopen this issue and added a patch for it.

I can reproduce it using Drupal 10.1, PHP 8.1, while editing a menu item using the Group Content Menu module.
https://www.drupal.org/project/group_content_menu/ →

Even though simple sitemap is enabled only for node and media entities, I get the same error message editing an entity (menu item in this case).
I think custom entity types can also trigger this error, which prevent editing them.

We were also experiencing this after D10.1 upgrade. For us it seems to be caused and fixed by 🐛 Operation is null in custom menu link form Needs review . The patch also did fix it though.

The patch is not needed. If $form_object->getOperation() returns NULL it means that the EntityFormInterface is not implemented correctly.

This fixes the same error for me that I experience when deleting group_content_menu items.

I don't think it would be criminal to consider making the code here a bit more tolerant, especially since in it's tolerance everything is hunky dory.

@walkingdexter could you explain your resistance or what the issue would be in implementing this bit of code?

I don't think it's fair to say that getOperation() returning NULL is a third party problem, since getOperation does not specify return types.

I don't think it's fair to say that getOperation() returning NULL is a third party problem, since getOperation does not specify return types.

@jnicola The return type is specified in PHPDoc, which is respected by PHPStan.

Eh, I suppose. I wonder just how much of Drupal would need to be redocumented or fixed once return types are specified and discover how much wasn't actually as expected...

Is there any loss to be had adding a sanity check here besides a milisecond or two of time?

Is there any loss to be had adding a sanity check here besides a milisecond or two of time?

I'm not a fan of adding unnecessary checks that go against the documentation. Incorrect implementation can lead to errors not only with this module. The above case clearly shows that the problem is related to the third party.

I support walkingdexter on this matter - I do sometimes work around other modules' problems, but those modules better be in core, otherwise this is a never ending endeavour.