group of repeated custom field for each product.

Hi,

So I understand that you're talking about custom fields of the table "product" so that the admin can attach custom information to the products.
You can only have one set of custom fields per product. However, if the product has variants, you can have one set of custom fields for each variant of the product. And when the selected variant changes on the frontend, the user will see the data of the custom fields set relative to this variant.

Hi,

Well, the problem is a structure problem of the custom field system.
The custom field system is based on the fact that one custom field correspond to one column of the table in the database.
So, if you create a custom field of the table "product" called "field1", then HikaShop will add a column "field1" in the hikashop_product table.
Now, if you want to introduce repeatable custom fields, it would require adding as many columns to the table in the database for the maximum amount of repeated in the products.
This means potentially adding a lot of columns.
Besides, that also means reviewing the custom field system to support "grouping". Not only the custom field configuration interface in the backend, but any view where custom fields are displayed. Also, you need to change any saving function to support this too. And this also means complex changes for import / export / mass actions. So, these are really extensive changes.
A plugin to support this won't cut it.

A way simpler approach is to just have the layout as a characteristic of your products, with one variant per layout. That way, in each variant you can configure one set of custom product fields, and when the user selects the layout on the product page, the custom fields display will update on the product page to reflect the value of the custom fields for the selected variant.
This doesn't require changing any code, and seems to need your needs. Or am I missing something ?

Hi,

1. Ah yes, if you create your own interface with your own table in the database, you can do it with something much simpler than adapting the whole custom field system and HikaShop to supporting repeatability.
In your plugin, you'll want to implement the onProductBlocksDisplay(&$product, &$html) event and inject your HTML as an extra entry of the $html array. You can also use the onAfterProductCreate(&$product) and onAfterProductUpdate(&$product) events to handle the saving of the data in the database.
You can see an example of this with the plugin which handles shipping prices per product. In shipping methods, you have a "shipping price per product" setting. If you activate that setting, an extra interface "shipping prices" will appear on the product edit screen so that you can configure different shipping prices for different products. This is all handled by a plugin, which implements these events I described above. You can find the files of the plugin in the folder plugins/hikashop/shippingmanual_prices/
The plugin also handles frontend display with the onHikashopBeforeDisplayView (&$view) event, but you can simply add your code in a view override, it will be easier for you.

2. If you use the "AJAX image" or "AJAX file" types in a custom field, you can activate its "multiple files" setting. This allows you to be able to upload several files in one custom field. So if your custom fields are only upload fields, you could use this capability to be able to upload several files without having to create one field per possible upload. That might be an interesting solution maybe ?

There is no discount for black friday.

Hi,

I would recommend going simple here and just use the HTML file type:
developer.mozilla.org/en-US/docs/Web/HTML/Element/input/file
If you want something more advanced, with drag & drop, like in HikaShop, you can use something like this:
bdwm.be/drag-and-drop-upload-files/
The upload system we use in HikaShop (which is a more complex solution but based on the same principle as what is presented in the link above) is not easy to add in a plugin. It's possible, but there is no ready-made example. The system requires several pieces added in different places. It's not easy to use what we already have as an example as we was not made to be used by third party code easily.