Issue storing data from Custom Fields in v4.x

[nefarioustim]

Bug report

Describe the bug

In Strapi 3 it is possible to declare a custom field within a content-type schema and have it link to a custom component for data entry using what is essentially undocumented functionality. In order to do this, we need to update the attributes within schema.json to include a columnType like so:

  "attributes": {
    "Title": {
      "type": "string",
      "required": true
    },
    "Video Stream": {
      "type": "videostream",
      "columnType": "text"
    }
  }

This allows the component attached to the videostream type to store data in a DB column matching columnType.

In Strapi 3, we are still able to attach a custom component to a custom field, using the addFields method within the register method of a plugin:

app.addFields({ type: "videostream", Component: VideoStream });

However, adding the columnType to schema.json no longer creates the relevant column in the DB table for a content type, which means a custom field can no longer store or retrieve data for said content type. I suspect this is due to the addition of Yup schema validation under the hood.

Steps to reproduce the behavior

1. Add a custom field via a plugin, using app.addFields() within the register(app) method.
2. Reference the custom field in the attributes section in schema.json for a content type.
3. The custom component will be rendered for the field in the content manager.
4. When data is saved or attempted to load from an existing entry, it will fail.

Expected behavior

There should be some method to allow storage as a standard DB-ready data type.

In my case, I simply want to save a UUID from a custom menu drop-down that renders thumbnails for a list of video streams.

I appreciate this is essentially an undocumented feature, but it has broken a large number of plugins developed within the community. This includes the Color Picker plugin tutorial that is often referenced for documentation: https://www.paulgaumer.com/blog/how-to-create-a-color-picker-plugin-for-strapi-cms

Am happy to work on a PR to fix the issue if someone can give me some pointers around the integration of Yup and how the creation of DB tables works during startup.

System

• Node.js version: v16
• Yarn version: Classic
• Strapi version: v4.0.3
• Database: MySQL
• Operating system: Docker hosted Alpine linux

[strapi-bot]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/custom-fields-not-showing-in-version-4-0-0/13057/5

[soupette]

Hello @nefarioustim custom fields is not yet supported in the admin panel.

However you can use patch-package in order to make a small modification in the @strapi/admin package in order to make custom renderers working.

Here's what you can do:

in your schema.json apply this modification:

 "attributes": {
    "Title": {
      "type": "string",
      "required": true
    },
    "video_steam": {
      "type": "text",
      "pluginOptions": { "content-manager": { "type": "videostream" } }
    }
  }

Then in your node_modules change this line to

type={fieldSchema.pluginOptions?.['content-manager']?.type || inputType}

Then using the register your field as documented app.addFields({ type: "videostream", Component: VideoStream }); and run strapi build

[soupette]

I am closing this issue as a workaround has been provided.

[yohanBarilleau]

Another workaround that doesn't change the node_modules package, is to intercept the render of your component :
https://github.com/akcyp/strapi-plugin-point-list/blob/main/admin/src/index.js#L9-L20
Find in this discussion : #strapi/documentation#1062
Use this file too for the workaround : https://github.com/akcyp/strapi-plugin-point-list/blob/main/admin/src/utils/intercept.js

You can use your custom field like this :

// src/api/example/content-type/schema.json
{
  "attributes": {
    "path": {
      "type": "string",
     "fieldRenderer": "pointlist"
    }
  }
}

[sapkra]

@soupette Sorry, but to me it makes no sense why this issue is closed. It's still a bug even though there is a hacky workaround. It is still not working as expected in 4.3.0-beta.2.

Or have a missed another issue where the custom field support ist tracked?

[derrickmehaffy]

@soupette Sorry, but to me it makes no sense why this issue is closed. It's still a bug even though there is a hacky workaround. It is still not working as expected in 4.3.0-beta.2.

Or have a missed another issue where the custom field support ist tracked?

We are actually working on real custom fields, see: https://feedback.strapi.io/developer-experience/p/custom-fields

Likewise see: https://strapi.io/custom-fields

---

What we had in v3 and what was transfered over to v4 was basically a hacky solution that we are trying to get rid of in favor of real custom fields. There should hopefully an alpha/beta on this in aug/sept ideally.