Create New Schema Field Like HTML Markdown Field, Slug etc.

[serdarozbilen]

Hello,
I want to add new schema filed types.
For example an HTML markdown field or slug.
I tried to add my new field codes to schema_field.go. Everthing same with other fileds
Then created SlugOptions.svelte, then imported it into the FieldAccordion.svelte.
Then built it.
But still cannot see it in admin ui filed selection.
Sorry I'm new in go and Pocketbase. I liked your project too much.
I want to learn and use it.
Great job

[ganigeorgiev]

New collection field types cannot be added adhoc like "plugins" since this will complicate a lot of things (data persistence, db constraints, validation, filtering, etc.).

If you have modified the source and want to display your custom field types, you'll have to also:

• define how the field value will be displayed in the table listing in https://github.com/pocketbase/pocketbase/blob/master/ui/src/components/records/RecordFieldCell.svelte
• create form field component for your field and import it in https://github.com/pocketbase/pocketbase/blob/master/ui/src/components/records/RecordUpsertPanel.svelte

I'm not sure what is your use case, but I wouldn't recommend going with this approach, especially since the project is not stable yet and you'll have to manually keep your modifications in sync.

If you have a need for a "slug" type field why not use the existing text type with a regex pattern for validation?
The same could apply for the HTML/markdown type. As discussed in #50, the Admin UI is mostly for the developers for quick data exploration and configurations and wasn't really designed to be used as headless CMS.

There is also option to add new fields in the PocketBase core so that they are available for everyone, as long as the use case is generic and fairly common. I'll have to think a little more on this, but since the markdown/html field type is practically a text field type but with different visualization, I may consider implementing it for a future release as a field option (eg. plaintext and wysiwyg/markdown editor).

[serdarozbilen]

Thank you very much for your valuable reply.
Your suggestions on slug and html can definitely be used.
But I had thought of adding the auto-generate feature for the slug.
In addition, text can be used for html, of course, but as you said, using it without an editor will not be realistic. As you said, it would not be wise to make changes to the source code of the project. I think it would be much more correct to wait for your developments in this regard.

Yes I read in the answers that this system was not developed for a CMS. But why not ? In order for it to be a CMS, a few fields such as slug and HTML are sufficient to present a simple CMS structure. Apart from these, there are no serious shortcomings. Text fields are sufficient to use for SEO meta. Relations is sufficient for taxonomies such as categories and tags. There isn't much left. Of course, if there is a plugin logic, this will speed up the development of the system, but it is not an urgent priority for CMS.

Personally, I can make a very adequate CMS out of this system with html field. Because the system provides me with almost everything I need.

For example, I have read the map field suggestion, and it seems to have been added to the road map. It will also be a super feature for CMS.

When Slug and HTML support comes, I'm sure many people will start using this system as a CMS. This will certainly contribute to further support of the project. As this project supports CMS structure, I am sure that modules such as html template editor and liquid template editor will be developed by other developers. I will probably do the first study on this subject :)

In short, maybe a few areas that you can easily add in a few days will allow the project to gain many contributiors.

Frankly, I've been experimenting with orchard core cms and docs for months. It's a very well planned project, but the way it's broken down into too many parts has made the project overly complex and difficult to understand. Therefore, while I was looking for something more practical, I saw your project and was amazed. The flexibility I was looking for and the simplicity I was looking for in this project. Of course, they are not exactly the same things, but I also studied Qor, but Pocketbase offers a more flexible structure than that.

I will continue on my way with pocketbase and try to contribute as much as I can.

Best regards Gani

[ganigeorgiev]

I'm afraid there is a lot more work to be done in order to make PocketBase useful as headless CMS.

It may seems easy at first glance, but adding even something simple like auto generated slug field comes with a lot of complications. How the auto generation will work? Based on another field (eg. title)? What if I decide to remove the linked field? What if someone doesn't need slug? What if someone want the slug value to have a specific format? What if someone want the slug to be constructed from multiple fields? And the list can go on.

If you are looking for a headless CMS, you may want to check Directus or Strapi.

[serdarozbilen]

Yes you are right. I thought as if there was a title field as default. However, it can be solved by putting the "use as slug on text fields" option. If the field is deleted, the id can be assigned as slug.
If there is an html field, it may be enough for now. I will try too. Thanks for the CMS suggestions, but I'm committed to Pocketbase. Another possibility is maybe qor. I'll wait for the project to finish first.