Conflict with Simplenews

I will see that issue today, I come to you about the feedback.

Hi,

I can confirm this module conflicts with simplenews.

When module form_mode_manager is enabled, entity handlers are altered in hook_entity_type_alter(), as a result, any page containing a simplenews subscription block throws fatal error:

The website encountered an unexpected error. Please try again later.
Error: Call to undefined method Drupal\simplenews\Form\SubscriberForm::setUniqueId() in Drupal\simplenews\Plugin\Block\SimplenewsSubscriptionBlock->build() (line 164 of modules/simplenews/src/Plugin/Block/SimplenewsSubscriptionBlock.php).

See screenshot in related issue.

I traced down the error to method FormModeManager::setFormClassPerFormModes which alters the form class to the default form class.

No idea as to what the right way of fixing this would be though...

Hi @bmunslow,

I will see that fast now I'm more free to help us. The related issue are fixed now and 8.5 are stable the problems persist ?

Hi @woprrr

I can confirm this issue persists in Drupal 8.5.3.

No action was taken by the conflicting module (simplenews).

I'm happy to help if you can point out some ideas on how to fix it.

In case someone else stumbles upon this issue, this is a temporary fix which allows to have both modules enabled at the same time (patch attached).

Not need to change the code to exclude a specific entity from form mode manager. You have an interface to choose what entities and form mode you need to use eg add_to_cart for drupal commerce. You can also specify it directly in config. You error sound similar to #2963743: Visiting /admin/config causes endless loop ? Is that error you seen ?

I see what’s happen tomorrow for sure !

Thanks for your input @ woprrr

I don't think this issue is related to the issue you point out about infinite loop.

This issue is very easy to reproduce on a clean Drupal 8.5 install:

1. Install and enable Form Mode Manager module
2. Install and enable Simplenews module
3. Create a new form mode for node or any other entity type
4. Place Simplenews subscription block in any region
5. Load page with the block. Web crashes with following error:
   

   The website encountered an unexpected error. Please try again later.
   Error: Call to undefined method Drupal\simplenews\Form\SubscriberForm::setUniqueId() in Drupal\simplenews\Plugin\Block\SimplenewsSubscriptionBlock->build() (line 164 of modules/simplenews/src/Plugin/Block/SimplenewsSubscriptionBlock.php).

Not need to change the code to exclude a specific entity from form mode manager. You have an interface to choose what entities and form mode you need to use

Thank you very much for this hint!

I can confirm this conflict is solved by excluding block form mode for Simplenews subscriber entities.

For those with the same issue, this is how to do it:

1. Go to: Administration > Configuration > Content authoring > Form Mode Manager settings
   URL: /admin/config/content/form_mode_manager
2. Select 'Simplenews subscriber' and choose 'block' to be excluded
   
3. Error fixed

@woprrr Can this issue be closed, since it's possible fix it by excluding entity in config? Or do you still want to look into it?

Looks like that UI is using machine names for entity types, so that could be improved.

IMHO, form mode manager should be more careful in replacing other form classes, because there's a reason when there is one and even if it doesn't expose new public methods, it could still break things?

Hi all :) I'm glad to see you here @berdir !!! I'm really open (as usual) about your feedback for Form Mode Manager (code). I really try to make a more clean/powerfull code as possible to provide this important feature and take flexibility for site builder (It's hard to plug this system with every possible entities ...) Entity operation was the MOST BIG Challenge and Plugin(factory) can solve the problem instead using statics class (like IEF).

Come back to this subject !

Looks like that UI is using machine names for entity types, so that could be improved.

It's already done for 2.x branch but I admit ... UI/UX isn't really my strong point \(X_X)/
@see :

IMHO, form mode manager should be more careful in replacing other form classes, because there's a reason when there is one and even if it doesn't expose new public methods, it could still break things?

The part of code responsible to that part will not replace any existing Form classes this is why a part of complexity was to take ability for developper to define/expose her specific class name for FormClass in EntityRoutingMap plugin.

  /**
   * {@inheritdoc}
   */
  public function setFormClassPerFormModes(EntityTypeInterface $entity_definition, $form_mode_name) {
    $entity_type_id = $entity_definition->id();
    /** @var \Drupal\form_mode_manager\EntityRoutingMapBase $route_mapper_plugin */
    $route_mapper_plugin = $this->entityRoutingMap->createInstance($entity_type_id, ['entityTypeId' => $entity_type_id]);


    if ($default_form = $entity_definition->getFormClass($route_mapper_plugin->getDefaultFormClass())) {
      $entity_definition->setFormClass($form_mode_name, $default_form);
    }

    if ($edit_form = $entity_definition->getFormClass($route_mapper_plugin->getEditFormClass())) {
      $entity_definition->setFormClass('edit_' . $form_mode_name, $edit_form);
    }
  }

    if ($default_form = $entity_definition->getFormClass($route_mapper_plugin->getDefaultFormClass())) {
      $entity_definition->setFormClass($form_mode_name, $default_form);
    }

This part is totally proper to Form Mode Manage that take ability to people to identify form_mode_specific FormClass to play with it after and that use by default the default FormClass OR a specific FormClass in EntityRoutingMap Plugin.

    if ($edit_form = $entity_definition->getFormClass($route_mapper_plugin->getEditFormClass())) {
      $entity_definition->setFormClass('edit_' . $form_mode_name, $edit_form);
    }

That part is specific to 'edit' actions and we are mandatory to create a new one for Edit action too because lot of entities need to add form alteration directly in FormClass (eg: User and Custom entities in 70% of cases). That take the possibility to easily identify the form mode manager FormClass and deal with her for developper (but that a little heavy for people not need to customize at this level ...).

In Form Mode Manager we have only one place altering 'default' entities behavior is that "Edit/Add as Default" feature request. It has been asked to bring the possibility of being able to restrict access to form mode by default of the entity via a permission. And that a specific Subscriber \Drupal\form_mode_manager\Routing\EventSubscriber\EnhanceEntityRouteSubscriber

For SimpleNews case I will see what's the problem faster and take feedback/patch if needed.

Thank all to using Form Mode Manager and help to improve It !

@bmunslow Are you sure you using 2.x and not 1.x branch ?

I try to reproduce all usecases and all seem's work as a charm with simplenews. If you use 1.x branch saddly it's "normal" because this is why I have re architectured/Redesigned ALL Form Mode Manager integration with FormClass / Listener etc... The old approach was so destructive for complex entities / unbundled entities Or very specific.

@bmunslow Are you sure you using 2.x and not 1.x branch ?

Yes, I can confirm this issue happens with the 2.x branch.

In the steps to reproduce, I forgot to mention you have to create a form mode for any entity type.

For example, create form mode 'Test' for entity type: node.

Setup:

Drupal 8.5.3
Form Mode Manager Version: 8.x-2.0-beta1
Simplenews Version: 8.x-1.0-alpha3

After a Cache rebuild I can See the problem now this is why the problem happen after "For example, create form mode 'Test' for entity type: node."
@Berdir you right (Again) Infact in my thought Form mode manager define new form modes based on machine name of form_mode. And Simplenews use

$form_object = $this->entityTypeManager->getFormObject('simplenews_subscriber', 'block');

for his blocks (legitimately) and that match with form_mode_manager pattern "$entity_definition->setFormClass($form_mode_name, $default_form);" It's really simple to change it prefix it like "$entity_definition->setFormClass("fmm_$form_mode_name", $default_form);" to avoid all possibles collision with usage of programatic form modes.

Here the fix to avoid all obscure unneeded behaviors :D and to reply to berdir :

IMHO, form mode manager should be more careful in replacing other form classes

Yes ! I did not think another module would use the machine name to use in the $form_object like that but it's my fault !! To overcome this problem FormClass add by "Form Mode Manager" is prefixed to be identifiable and avoid conflicts.

Bonus fix a bug to block in edition mode the wording was that of add in 8.5.

I have tested all usecases but not hesitate to make feedbacks.

I can confirm patch in #15 fixes the issue for good, excellent job @woprrr.

Tested on a production site with many different existing form modes, etc. Conflict with simplenews has disappeared completely (without having to exclude the block form mode from simplenews_subscriber entity type) and both modules seem to be functioning normally.

Looking RTBC to me!

All seem's good to me too after a good night and re-test this morning :D