Introduce hook_entity_prepare_form() to generalize hook_node_prepare()

Generally, +1 on doing so. Here some thoughts about it:

• I think hook_entity_prepare() isn't a good a name as it's not talking about forms as all. I think the typical use case for it is pre-populating entity field values for the given form, so we should a) mention that and b) call the hook accordingly. So what about hook_entity_prepare_form() - analogously to hook_entity_prepare_view()?
• We typically invoke entity generic + entity type specific hooks, so let's do that here as well?
• The docs should clarify that the hook is just once and not per form rebuild.
• I think we should pass on the form controller also, such that stuff like the form operation is available in the hook.

Looks generally good except a missing healthy does of dependency injection.

+++ b/core/includes/entity.api.phpundefined
@@ -452,6 +452,27 @@ function hook_entity_display_alter(\Drupal\entity\Plugin\Core\Entity\EntityDispl
+ * Act on an entity object about to be shown on an entity form.
+ *

Acts

+++ b/core/includes/entity.api.phpundefined
@@ -452,6 +452,27 @@ function hook_entity_display_alter(\Drupal\entity\Plugin\Core\Entity\EntityDispl
+  if ($form_state['controller']->getOperation() == 'default') {
+    $entity->label->value = 'Altered label';
+    $form_state['mymodule']['label_altered'] = TRUE;
+  }

I think we are moving away from default in favor of "edit", "delete", etc, no?

+++ b/core/lib/Drupal/Core/Entity/EntityFormController.phpundefined
@@ -414,9 +414,19 @@ public function setEntity(EntityInterface $entity) {
+   *
+   * This can be used to fill in a default values. It then invokes

"in default values"

+++ b/core/lib/Drupal/Core/Entity/EntityFormController.phpundefined
@@ -414,9 +414,19 @@ public function setEntity(EntityInterface $entity) {
+  protected function prepareEntity(array &$form_state) {
+    $handler = \Drupal::moduleHandler();

Well, so @YesCT would say if you call \Drupal from a method, you do it wrong, the modulehandler should be injected on controller creation. She has references to show in case needed :)

+++ b/core/modules/views_ui/lib/Drupal/views_ui/ViewFormControllerBase.phpundefined
@@ -66,6 +66,8 @@ protected function prepareEntity() {
+    // Invoke prepare hooks.
+    parent::prepareEntity($form_state);

You don't have this comment elsewhere either, I don't think we need / should have this here.

Do you mean explicitly? Because it should be available in the form state (see the example in entity.api.php)

+++ b/core/includes/entity.api.php
@@ -452,6 +452,27 @@ function hook_entity_display_alter(\Drupal\entity\Plugin\Core\Entity\EntityDispl
+function hook_entity_prepare_form(\Drupal\Core\Entity\EntityInterface $entity, array &$form_state) {

I see we can get the controller via $form_state, but yeah - I think the operation is something most implementations should or will have to check here. I'd pass $operation and $langcode as separate parameters to highlight this will run per operation and language, for anything special people still can go for $form_state['controller'].

+++ b/core/modules/node/node.api.php
@@ -592,23 +593,6 @@ function hook_node_access($node, $op, $account, $langcode) {
-function hook_node_prepare(\Drupal\Core\Entity\EntityInterface $node) {

Why is that removed - shouldn't it be updated instead?

The patch seems to still pass $entity not $controller as first argument?

Howsoever, I think this should work analogously to hook_entity_prepare_view().

So how about going with hook_entity_prepare_form($entity, $form_display, $operation, $form_state) ?

The passed entity can be just $controller->getEntity() - so that should not make a difference compared to passing $controller. However, imho it's better DX to have all the used parameters separately compared to having to get everything out of the controlller?
Regarding language I agree - it's probably the way it will work in d8 everywhere that you just get a language-aware $entity.

I found nothing to complain about, not even code style and @plach walked me through the recent changes too.

git ac https://drupal.org/files/entity-prepare-2025991-23.patch
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 38655  100 38655    0     0  12157      0  0:00:03  0:00:03 --:--:-- 13914
error: patch failed: core/modules/node/lib/Drupal/node/NodeFormController.php:18
error: core/modules/node/lib/Drupal/node/NodeFormController.php: patch does not apply

Re-roll

Changed status

Looks good, reviewed multiple times above.

+++ b/core/includes/entity.api.phpundefined
@@ -452,6 +452,31 @@ function hook_entity_display_alter(\Drupal\entity\Plugin\Core\Entity\EntityDispl
+function hook_entity_prepare_form(\Drupal\Core\Entity\EntityInterface $entity, $form_display, $operation, array &$form_state) {
+  if ($operation == 'edit') {
+    $entity->label->value = 'Altered label';
+    $form_state['mymodule']['label_altered'] = TRUE;
+  }

What does this do that a form alter cannot? Seems strangely overkill

+++ b/core/modules/views_ui/lib/Drupal/views_ui/ViewEditFormController.phpundefined
@@ -39,12 +40,16 @@ class ViewEditFormController extends ViewFormControllerBase implements EntityCon
-  public function __construct(TempStoreFactory $temp_store_factory, Request $request) {
+  public function __construct(ModuleHandlerInterface $module_handler, TempStoreFactory $temp_store_factory, Request $request) {

This just worsens the DX for a simple entity form.

+++ b/core/modules/views_ui/lib/Drupal/views_ui/ViewFormControllerBase.phpundefined
@@ -41,7 +41,7 @@ public function init(array &$form_state) {
-  protected function prepareEntity() {
+  protected function prepareEntity(array &$form_state) {

I went out of my way to *not* pass $form_state to prepareEntity

+++ b/core/modules/views_ui/lib/Drupal/views_ui/ViewPreviewFormController.phpundefined
@@ -26,18 +27,23 @@ class ViewPreviewFormController extends ViewFormControllerBase implements Entity
+  public static function createInstance(ContainerInterface $container, $entity_type, array $entity_info, $operation = NULL) {

Why is $operation added here?

Based on #36 I think we need more discussion here...

This is much more reasonable, IMO.
Back to RTBC if green.

+++ b/core/lib/Drupal/Core/Entity/EntityManager.phpundefined
@@ -227,11 +227,11 @@ public function getFormController($entity_type, $operation) {
+        $this->controllers['form'][$operation][$entity_type] = new $class($this->container->get('module_handler'));
       }
+      $this->controllers['form'][$operation][$entity_type]->setOperation($operation);

Btw, I like this change.

Committed f74d298 and pushed to 8.x. Thanks!

Let's ensure the change notices are up-to-date...

https://drupal.org/list-changes/drupal?keywords_description=EntityFormCo...

I read the change notice and looks clear to me. The only thing that confused me is the example of hook_menu, because I expected to find a Routing example instead.

That menu example is adding a local tab. Those are still in flux, so I would not bother with keeping that updated to interim APIs. It was already there before. Thanks for the update!