Custom (Meta-) Fields for Pages and as a Template #2853

New Issue

OVERLORD · 2026-02-05T05:27:54+03:00

OVERLORD commented

2026-02-05 05:27:54 +03:00

Originally created by @Der-K-2000 on GitHub (Jun 17, 2022).

Describe the feature you'd like

It's nice to see, that there are Templates https://github.com/BookStackApp/BookStack/issues/1123#ref-issue-806365368, but for my cases it's not enough and I'd like to have additional structured custom fields for a page (like meta fields you know from CMS like WordPress).

The regular field in pages is too (auto) formatted. This input field is good for a normal text, but not for structured data.

ID and Plaintext-Value for each field would be enough (and maybe a Label as addition).

And to make it comfortable those extra fields should be available as a kind of a template (like for pages/chapters). Of course for the templates there could be multiple solutions and this would be a second big step. But at least custom fields would be really really helpful.

Describe the benefits this would bring to existing BookStack users

Using the API for a couple of cases it would be awesome to add additional fields in the json-output, which are 1) an unique ID 2) plaintext from the value-field.

Can the goal of this request already be achieved via other means?

I'm not sure, but I don't think so.

Solution for me so far: Table in a page, but the output via API has to be sanitized/cleaned from html and other formated strings. And that's something I can do for my internal projects, but not for clients and outsourcing the content.

And even though it's possible to clean the output correctly, the whole content is only available in the html-field.

Have you searched for an existing open/closed issue?

I have searched for existing issues and none cover my fundemental request

How long have you been using BookStack?

0 to 6 months

Additional context

No response

Originally created by @Der-K-2000 on GitHub (Jun 17, 2022). ### Describe the feature you'd like It's nice to see, that there are Templates https://github.com/BookStackApp/BookStack/issues/1123#ref-issue-806365368, but for my cases it's not enough and I'd like to have additional structured **custom fields** for a page (like meta fields you know from CMS like WordPress). The regular field in pages is _too_ (auto) formatted. This input field is good for a normal text, but not for structured data. **ID and Plaintext-Value** for each field would be enough (and maybe a Label as addition). And to make it comfortable those extra fields should be available as a kind of a template (like for pages/chapters). Of course for the templates there could be multiple solutions and this would be a second big step. But at least custom fields would be really really helpful. ### Describe the benefits this would bring to existing BookStack users Using the API for a couple of cases it would be awesome to add additional fields in the json-output, which are 1) an unique ID 2) plaintext from the value-field. ### Can the goal of this request already be achieved via other means? I'm not sure, but I don't think so. Solution for me so far: Table in a page, but the output via API has to be sanitized/cleaned from html and other formated strings. And that's something I can do for my internal projects, but not for clients and outsourcing the content. And even though it's possible to clean the output correctly, the whole content is only available in the `html`-field. ### Have you searched for an existing open/closed issue? - [X] I have searched for existing issues and none cover my fundemental request ### How long have you been using BookStack? 0 to 6 months ### Additional context _No response_

OVERLORD added the 🔨 Feature Request label 2026-02-05 05:27:54 +03:00

OVERLORD closed this issue

2026-02-05 05:27:55 +03:00

OVERLORD commented

2026-02-05 05:28:07 +03:00

@ssddanbrown commented on GitHub (Jun 17, 2022):

Thanks for this request @SebastianBerlin but could you please expand on your own intended use-case of this desire? Just to help me understand the fundamental need a little better. (eg. what are you attempting to do/build using this and how would this data be read/wrote in terms of API vs in-platform user).

May likely be related to past issue #1552.

@ssddanbrown commented on GitHub (Jun 17, 2022): Thanks for this request @SebastianBerlin but could you please expand on your own intended use-case of this desire? Just to help me understand the fundamental need a little better. (eg. what are you attempting to do/build using this and how would this data be read/wrote in terms of API vs in-platform user). May likely be related to past issue #1552.

OVERLORD commented

2026-02-05 05:28:13 +03:00

@Der-K-2000 commented on GitHub (Jun 17, 2022):

Yes, indeed, it's related to #1552 and similar, but not the same, because I need those custom fields for different use cases, especially with this easy, but powerful API in BookStack it could be a great benefit and would make it a lot easier for managing content.

Examples: 1) The API will be used as a glossary/lexikon for an app whit a few fields of ONE page (e.g. fields/IDs grammar, meaning, history, related pages). And it would be tricky, but in the end ineffective for the app to sanitize the big content (from table (and other html-stuff) and strip every ID from it, because it's problematic, too, if only ONE thing in the big html-field is different or new/an addition, which is not known by the app so far. 2) Parallel a external publisher will have only read only rights for the API to show it for other cases, while 3) a different publisher will have full access to edit one or two custom fields (like in a correction mode) and 4) some editors will have the right to edit/publish via API every field and often, without logging into the backend of the CMS, because they will do it in a different connected CMS.

Only with a structured way (→ custom fields) you can handle that. I cannot be more clear, sorry, but EVERY content in the html-field leads to many problems.

@Der-K-2000 commented on GitHub (Jun 17, 2022): Yes, indeed, it's related to [#1552](https://github.com/BookStackApp/BookStack/issues/1552) and similar, but not the same, because I need those custom fields for different use cases, especially with this easy, but powerful API in BookStack it could be a great benefit and would make it a lot easier for managing content. Examples: 1) The API will be used as a glossary/lexikon for an app whit a few fields of ONE page (e.g. fields/IDs grammar, meaning, history, related pages). And it would be tricky, but in the end ineffective for the app to sanitize the big content (from table (and other html-stuff) and strip every ID from it, because it's problematic, too, if only ONE thing in the big html-field is different or new/an addition, which is not known by the app so far. 2) Parallel a external publisher will have only read only rights for the API to show it for other cases, while 3) a different publisher will have full access to edit one or two custom fields (like in a correction mode) and 4) some editors will have the right to edit/publish via API every field and often, without logging into the backend of the CMS, because they will do it in a different connected CMS. Only with a structured way (→ custom fields) you can handle that. I cannot be more clear, sorry, but EVERY content in the **html**-field leads to many problems.

OVERLORD commented

2026-02-05 05:28:21 +03:00

@ssddanbrown commented on GitHub (Jul 25, 2022):

Okay, thanks for expanding. My thoughts are similar to that in #1552, in respect that I don't want to expand scope to an additional data storage format, unless there is clear widespread benefit.

Would the existing tag format be suitable for your use-case?

@ssddanbrown commented on GitHub (Jul 25, 2022): Okay, thanks for expanding. My thoughts are similar to that in #1552, in respect that I don't want to expand scope to an additional data storage format, unless there is clear widespread benefit. Would the existing tag format be suitable for your use-case?

OVERLORD commented

2026-02-05 05:28:26 +03:00

@Der-K-2000 commented on GitHub (Jul 25, 2022):

Thanks for the reply, but it's not enough for my cases. Anyway I switched to cockpit cms for a large amount of field-types.

@Der-K-2000 commented on GitHub (Jul 25, 2022): Thanks for the reply, but it's not enough for my cases. Anyway I switched to cockpit cms for a large amount of field-types.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#2853