Enable Gin edit form for Commerce Product

$route_names array need also following to support translations:

'entity.commerce_product.content_translation_add'
'entity.commerce_product_variation.content_translation_add'

Updated patch #2 by addressing #3, please review it.

Thanks!

This makes me wonder if this wouldn't be desirable for other commerce sites. Your reasoning does make sense to me but I'm just thinking more generally. Could Gin make these gin content forms configurable via a setting in the UI? In addition to allowing other modules to specify this in a hook?

@paul121

Could Gin make these gin content forms configurable via a setting in the UI?

Not in the UI, and we’re not planning in introducing lots of new settings to our UI – but that’s actually already possible via hook_gin_content_form_routes().

The only thing that is kind of weird is the blank sidebar on product variations, but I guess we can't do much here about that. Maybe an issue could be created in commerce to add some more informations there.

Updated patch #4 for version 3.0-rc10.

By default Gin theme should only care about core functionality. Everything else should be easily configurable or extendable.

In this case you can do this as:

/**
 * Implements hook_gin_content_form_routes().
 */
function mymodule_gin_content_form_routes() {
  return [
      'entity.commerce_product.add_form',
      'entity.commerce_product.edit_form',
      'entity.commerce_product_variation.add_form',
      'entity.commerce_product_variation.edit_form',
      'entity.commerce_product.content_translation_add',
      'entity.commerce_product_variation.content_translation_add',
  ];
}

or move the issue to commerce to make sure all commerce forms work correctly with Gin theme.

I understand that Gin should care only about core as there are tons of contrib modules which might need to adapt themselves to Gin as well, which would bloat the module to handle all or even many of them. On the other hand, should all those contrib modules be aware of Gin and maybe other themes which need adjustments of he modules to work with them? That's the same problem just from the other side.

What about a more generic approach, like the Gin everywhere → module does? It even enables Gin for some core forms which are not covered by Gin itself (Block Content, Media, Menu). Why not integrating Gin everywhere completely into Gin?

And additionally, please document it better how to enable Gin for your own custom entity type. At least put a section in the project documentation which points to the proper hooks in the gin.api.php. Thanks.

By default Gin theme should only care about core functionality. Everything else should be easily configurable or extendable.

So I guess this should be removed : https://git.drupalcode.org/search?search=commerce&nav_source=navbar&proj...

@nicolasgraph why would we want to remove the icon? These are two completely different things

@saschaeggi, I'm just saying that if, as @Pasqualle said "By default Gin theme should only care about core functionality.", which is a completely admissible argument, I guess the commerce icon should not be embed by default. Is it used when Commerce is not installed ? The fact that this icon is there by default could be interpreted as a Commerce support, and thus, justify issues like this one.

Did you try https://www.drupal.org/project/gin_everywhere → ?

Thanks @hydra, I can live with a custom hook for now, but i'll give gin_everywhere a try.