Remove implicit dependency on node module for gin content form

Aha! A big reason why this doesn't work without the node module may simply be because the node-edit-form template isn't registered. Gin does override this template in templates/node/node-edit-form.html.twig but it doesn't register the template itself, that is done by the node module here: https://git.drupalcode.org/project/drupal/-/blob/9.5.3/core/modules/node...

I found that simply registering the template in the Gin theme solves the issue; the gin content form works (the sidebar is populated) without the node module being enabled:

/**
 * Implements hook_theme().
 */
function gin_theme() {

  // Add node edit form template if not provided by node module.
  $themes = [];
  if (!\Drupal::moduleHandler()->moduleExists('node')){
    $themes['node_edit_form'] = [
      'render element' => 'form',
      'template' => 'node/node-edit-form',
    ];
  }
  return $themes;
}

So that is great! But then this makes me wonder: is the claro/node-form library really needed? I commented out this line and the gin content form still looks and works just fine: https://git.drupalcode.org/project/gin/-/blob/8.x-3.0-rc1/src/GinContent... That said, I'm testing with a custom entity type, not nodes, so perhaps this library is still needed for nodes.

I think I need some input from @saschaeggi to confirm.. but it seems that Gin may override nearly all the layout styles the claro/node-form and node/form libraries provide? If this is the case, does it make sense to try and move towards a more generic content-edit-form template & libraries?

I'm going to create branches with both approaches:
1) Still using node-edit-form, maybe as a more near term solution
2) Renaming as a content-edit-form to generalizing and moving away from nodes. If much of the css classnames change this could certainly be a breaking change and require a new major version.

I'm going to create branches with both approaches:

I did a quick test with a custom node bundle as well and both of these approaches seem to be working (see screenshot). But it would be nice if someone could further test option 2 with nodes and custom content types, especially if you are already using this Gin content form for your custom entity type.

I assume that option 2 would be too much of a breaking change (beyond css, its likely others would depend on the template name for preprocessing, etc) so I will just open a MR for option 1 for now.

Adding correct screenshot, this is a simple "test" node type with the content-edit-form

Aha. With some help from @wotnak I've found a slightly easier to way to adopt content forms in farmOS. We can register the node_edit_form template ourselves as a little hack with just the following:

/**
 * Implements hook_theme().
 */
function farm_ui_theme_theme($existing, $type, $theme, $path) {
  return [
    'node_edit_form' => [
      'render element' => 'form',
    ],
  ];
}

Once we implement hook_gin_content_form_routes() the content form starts working great.

There is just one issue, this warning is thrown in the log messages the first time you load an entity form after clearing the cache:

User warning: The following theme is missing from the file system: node in Drupal\Core\Extension\ExtensionPathResolver->getPathname() (line 63 of /var/www/html/web/core/lib/Drupal/Core/Extension/ExtensionPathResolver.php)

Deprecated function: dirname(): Passing null to parameter #1 ($path) of type string is deprecated in Drupal\Core\Extension\ExtensionPathResolver->getPath() (line 85 of /var/www/html/web/core/lib/Drupal/Core/Extension/ExtensionPathResolver.php)

This is caused by the implicit (and unnecessary) dependency on the node module as described above. Removing the claro/node-form library solves this issue. I'm attaching a patch for this single change so that we can use it in farmOS, but it should not be considered a complete fix for this issue.

Hey Paul

I left some comments in the MR

Cheers!

paul121 → closed merge request !228

Thanks @saschaeggi, please see new MR 563!

Hey what is your opinion on the other approach I proposed to generalize the "node edit form" to be the "content edit form"? You can see the changes in that branch here, I just didn't make a PR for it: https://git.drupalcode.org/issue/gin-3342164/-/compare/8.x-3.x...3342164...

It isn't clear to me how much Gin depends on the core claro/node-form library/styles/JS, in which case this could also be a bit of a core issue. Otherwise if Gin really overrides all of the claro node form template + library then perhaps this is an opportunity for Gin to continue further improve this outside of core.