Select form mode

Note that all other form modules usually imply to edit an existing entity, so this is not useful unless we also add context support to use an existing entity.

Which possibly requires to use the same approach as entity_view, with a deriver for each entity type + context for that entity type.

Bumping this. It would be nice to have form modes. I'll see if I can make out some time to work on this.

This is probably going to break tests. I implemented a deriver for each entity type to display the entity from context as an update form. I am using this with panels and page manger, but have not tested the admin/structure/block side of things.

I've sorted my additions out to play nicely with the original block plugin. The attached patch has a migration path that updates the plugin id entityform_block to entityform_block_add for any configuration. A dependency for ctools is introduced with the new Edit and Delete plugins, because they implement Drupal\ctools\Plugin\Deriver\EntityDeriverBase.

I've introduced two new classes and renamed EntityEditFormBlock.php to EntityFormBlockAdd.php.

* EntityEditFormBlock -> EntiyFormBlockAdd
* EntityFormBlockEdit
* EntityFormBlockDelete

Warning: This patch makes database updates to rename any block ids containing entityform_block to entityform_block_add. This is applied to settings of configuration entities with entity type id 'page_variant' or 'block'.

I've made an effort so that the tests may pass, so I'm placing this back in "Needs Review" status.

Add test_dependencies key to info.yml.

This patch removes the hard dependency for ctools and adds the new features as individual modules, entityform_block_edit and entityform_block_delete. I will try to write unit tests for the new modules, but the existing module's unit tests should pass now.

:-/ It looks like the test configuration needs to be updated to discover EntityFormBlockAddTest.php. They do pass locally.

Thanks for working on this.

I don't understand why this needs to be so complicated.

We can't we just add a select to the existing block that allows to select that? I guess the context? In theory, it should be possible to specify that it accepts any entity with type "entity", but not sure if that actually works, possibly not.

But even then, we could limit it to a single block/deriver that accepts the entity context and it doesn't need to be delete/edit specific.

And I think we should avoid renaming the existing stuff, that wil llikely cause a lot of pain (there could be other things that use blocks, e.g. block_field), we could just add a new one with a different name? Maybe the naming of that won't be perfect, but I can live with that.

And the only thing that EntityDeriverBase provides is a constructor and create method, I'd rather copy that than add a dependency which can cause troubles for users that are updating.

Also not sure why you add a composer.json file that doesn't have anything special?

I re-rolled this with a deriver and context aware block that extends the original addform_block. I removed the dependency for ctools.
composer.json was me attempting to get the tests to pass, thinking it would help with dependencies.

Here's an updated patch that should pass tests.

I have created the patch form from the scratch.

Updated EFEB to use new EntityFormDeriver.

This patch works for both add and edit pages.

Now it works with custom view modes.

Minor doc fixes.

Let's review it first before fixing the tests.

WIth proper form display.

Review as follows.

1. +++ b/src/Plugin/Block/EntityEditFormBlock.php
   @@ -13,27 +23,114 @@ use Drupal\user\EntityOwnerInterface;
   +  public function defaultConfiguration() {
   +    return [
   +      'bundle' => NULL,
   

   This block needs an associated schema definition.

2. +++ b/src/Plugin/Block/EntityEditFormBlock.php
   @@ -13,27 +23,114 @@ use Drupal\user\EntityOwnerInterface;
   +      'view_mode' => 'default',
   

   Should this be form_mode?

3. +++ b/src/Plugin/Block/EntityEditFormBlock.php
   @@ -41,42 +138,32 @@ class EntityEditFormBlock extends BlockBase {
   +    $form['view_mode'] = [
   

   Should be form_mode.

4. +++ b/src/Plugin/Block/EntityEditFormBlock.php
   @@ -84,34 +171,30 @@ class EntityEditFormBlock extends BlockBase {
   +    $form_display = EntityFormDisplay::collectRenderDisplay($entity, $this->configuration['view_mode']);
   +    // Set the form_display in form state.
   +    $form_state = (new FormState())->set('form_display', $form_display);
   +    // Get the default entity form object.
   +    $form_object = $this->entityTypeManager->getFormObject($entity->getEntityTypeId(), 'default')
          ->setEntity($entity);
   -    return \Drupal::formBuilder()->getForm($form);
   +
   +    return $this->formBuilder->buildForm($form_object, $form_state);
   

   Should be able to use entity.form_builder::getForm

5. +++ b/src/Plugin/Deriver/EntityFormDeriver.php
   @@ -0,0 +1,78 @@
   +  use StringTranslationTrait;
   ...
   +      $container->get('string_translation')
   

   All this effort and no unit test? :)

6. +++ b/src/Plugin/Deriver/EntityFormDeriver.php
   @@ -0,0 +1,78 @@
   +      if (($entity_type->getGroup() == 'content') && $entity_type->hasFormClasses() && $entity_type_id != 'comment') {
   

   This is the second time comment has been excluded. Should be it's own function somewhere which can exclude entity types in the one place.

7. +++ b/src/Plugin/Deriver/EntityFormDeriver.php
   @@ -0,0 +1,78 @@
   +      // If this entity is bundle of a content entity than add the context of
   +      // bundle entity.
   +      if (($bundle_of = $entity_type->getBundleOf()) && ($bundle_of_definition = $entity_types[$bundle_of]) && $bundle_of_definition->hasFormClasses() && $bundle_of != 'comment') {
   +        $this->derivatives[$bundle_of] = $base_plugin_definition;
   +        $this->derivatives[$bundle_of]['admin_label'] = $this->t('Entity form (@label)', ['@label' => $bundle_of_definition->getLabel()]);
   +        $this->derivatives[$bundle_of]['context'] = [
   +          'entity' => new ContextDefinition('entity:' . $entity_type_id),
   +        ];
   +      }
   

   Why is this needed? If you load a bundle config entity type, should the associated content entity already be added to the list of derivatives?

Thanks, for the review.

1. Nice catch.
2. I always confuse it between form view mode and form mode but I'll rename.
3. ok.
4. If we want to set a custom form_display then we can't.
5. Patience :P
6. Agreed.
7. On /node/{node}/edit page we have the node in context but on /node/add/{node_type} we don't have node context we have node type context. This works around that it provides a node type context and use node as derivative ID.

But wont /node/{node}/edit not satisfy the context requirements anymore, because $this->derivatives[$bundle_of] is overriden the node derivative to require node_type?

Perhaps needs a good comment.

But wont /node/{node}/edit not satisfy the context requirements anymore, because $this->derivatives[$bundle_of] is overriden the node derivative to require node_type?

Indeed you are correct. Updated the patch for that.

Fixed the block access.

Found another issue

Rerolled last patch

Adding config schema for block deriver

As per this CR

Uploading patch to take into user from current url context

Rerolling Patch

Rerolling the patch

Rerolling patch for access, if usr has access to form

Hi, I have a problem with de last version of the patch.

PHP message: AssertionError: assert(strpos($data_type, 'entity:') !== 0 || $this instanceof EntityContextDefinition) in /var/www/html/web/core/lib/Drupal/Core/Plugin/Context/ContextDefinition.php on line 115 #0 /var/www/html/web/core/lib/Drupal/Core/Plugin/Context/ContextDefinition.php(115):

I changed ContextDefinition by EntityContextDefinition to try and solve the error.

Hello all,

I have approached the problem in a completely different way. Sorry for adding a divergence here. If you want, I can create a separate issue for this even if the objective is the same.

I agree with the latest comment of Berdir when he stated that this issue is getting too complicated. Maybe I am missing something but I think that the approach followed in this MR https://git.drupalcode.org/project/entityform_block/-/merge_requests/3 is much easier.

This is a PoC that needs more work:

- Only allow the users to select the form modes that belong to the selected entity type (probably the Form mode field should be loaded via AJAX)
- To test it

Also, there is something that I don't understand about the block context and the edit/delete permissions. I don't know why we have to care about this in this issue if we are not caring about it (AFAIK) when displaying the default form mode. Is not Drupal core checking the permissions when showing the form? Even if it's not the default one?

Please let me know if it worths to continue with this path or if I am missing something. Thanks!