I just saw your code (beta 7) and was working on Ajax form Entity D8 (that will need for sure a module like yours to create walls for examples or mass creation for content), and it seems that there may be a more elegant manner to work with form entities.
/**
* @file
* Contains \Drupal\ajax_form_entity\Plugin\Block\FormBlock.
*/
namespace Drupal\ajax_form_entity\Plugin\Block;
use Drupal\Core\Block\BlockBase;
/**
*
* @Block(
* id = "entity_form_block",
* admin_label = @Translation("Block form"),
* category = @Translation("Forms")
* )
*/
class FormBlock extends BlockBase {
/**
* {@inheritdoc}
*/
public function build() {
// Case of user
$entity = entity_create('user');
// Case of node type
$entity = entity_create('node', array('type' => 'page'));
// Case of taxonomy
$entity = entity_create('taxonomy_term', array('vid' => 'forums'));
// Call the form entity.
$output['form'] = \Drupal::service('entity.form_builder')->getForm($entity, 'default');
return $output;
}
}
So in one line
\Drupal::service('entity.form_builder')->getForm($entity, 'default');
we can get any form entity in a block. Issue is that entity_create should be custom as the parameters are not always the same (sad that we do not have a "bundle" parameter instead of vid / type or whatever). I tested with node / taxonomy / user and I must say it is not that complex !
Next question is how to make a block per entity / bundle. I do not see the solution as we need one file per block it seems in D8 so you can't declare as many block as you wish programatically like in D7. We may need to implement a new block type (?). Any other solution is welcome !
Regards,
Comments
Comment #1
mikey_p CreditAttribution: mikey_p commentedYup, I realized this as well and started work on this in a branch: http://cgit.drupalcode.org/formblock/log/?h=genericentityform.
It's not working perfectly for all entity types, but you can see the attempt at http://cgit.drupalcode.org/formblock/tree/src/Plugin/Block/EntityFormBlo...
Comment #2
eme CreditAttribution: eme at emerya commentedOh, I did not see your reply. I worked on my own also a bit meantime, and got some interesting results : I created a new project today that you can test out (https://www.drupal.org/project/entity_forms_in_blocks) but we need to merge rapidly the two projects I think.
I have the solution for the dynamic block system : we need to use the derivative system , where I use entity_get_bundles to get all bundles for each entity :
With that, I create one bloc for each entity form (better than having a single block I think).
Then you can use the block ID to render the right block (even if I think some more methode should be used instead of my switch above) :
Pretty straightforward and amazingly simple compared to D7 !
Comment #3
eme CreditAttribution: eme at emerya commentedWell I studied a bit your code and I must say that the config solution is more elegant with the ability of D8 to add as many block as needed.
Important change : we now need to change the access part by using
use Drupal\Core\Access\AccessResult;
There is another issue : the cache of the block is not functionnal (once submitted, the form expires). We may cache per user only I think. For now we can specify no cache :
Could you release it as a dev version so that the whole community can elaborate on this ?
Comment #4
eme CreditAttribution: eme at emerya commentedWe've released a new version for the module with part of your code (see last dev version of https://www.drupal.org/project/entity_forms_in_blocks). We replaced the "operation" part that does not seem to have real interest and replace it with the form mode for any entity.
There are still some work remaining of course ! Some entity forms not working (especially comment forms).
Of course, if you wanna merge it into FormBlock you're welcome and we can put Entity Forms in Blocks as obsolete.
Regards.
Comment #5
Greg BoggsHey Mikey_p, do you plan to include this in form_block? We're considering using this in RedHen to build out contact collections to allow for email subscription that's plugable with MailChimp and other email providers.
Comment #6
mikey_p CreditAttribution: mikey_p commentedUpdate: I have some old code in a branch for this, I would like to check with the core maintainers to see how 'operation' was intended to be used before we remove that completely (maybe it should just have a default and be under an "advanced options" section that is hidden).
The biggest problem seems to be that some entity types don't work, and we need a way to whitelist the ones that we know to work correctly. Once this is in place we can have a generic EntityFormBlock class and I think we can try to find a way to subclass it for each individual entity types that need to add custom behavior (like contact form access/flood control/etc)
Patches welcome.
Comment #7
Greg BoggsDo you know off the top of your head an entity type that this fails with?
Comment #8
mikey_p CreditAttribution: mikey_p commentedComments for one, I know there are several others. It's kinda surprising how many different entity types there are in D8.
Comment #9
mikey_p CreditAttribution: mikey_p commentedNow that I've got all the base bugs worked out for a stable 1.0 release for D8, I'm planning on adding this as well as form mode support in a 1.1 release.
Comment #10
phjouAny news on this?
Comment #11
AndyD328Hi phjou,
I intend to look at this once the features & bug fixes in the issue queue are resolved.
I think if we aim to do this generic solution first it will slow down getting a solid D9 version released.
So this is definitely on the road map and I'll aim to use as much of the above work as possible - so additional patches etc are very welcome.
Thanks!