Content Properties vs Page Properties - choose your limitation
Asked by M_S_:

Confluence pages have 'content properties' (key value pairs) and 'page properties' (provided by the macro).

Why do we have the distinction and why do we combine various disatvantages/limitations?

(I know content properties also apply to other elements, such as spaces, but that is not the point here).

Content properties are easily accessible via REST and Java API and supported by a number of plugins (Comala Workflows, Reporting, Scroll Exporter, ...). However, these seem to be considered 'internal' as I am not aware of any way to edit a set of custom content properties as part of a page.

The metadata 2 plugin may be an attempt to do this, but it is largely outdated. The editing experience with the old wiki syntax is awful.

On the other hand, editing page properties on a page is very user-friendly: drop in a macro, edit key/value pairs in a table. But these are not accessible via REST or Java API (they need to be parsed from the xhtml of the page - uh and slow) and thus not very well supported (e.g. not accessible from the Reporting plugin).

Am I missing something here? Why two concepts, each with its own set of disadvantages/limitations?


Answers:
author: Robert Reiner _smartics_
body: I think that this has historical reasons. [Page properties](https://confluence.atlassian.com/doc/page-properties-macro-184550024.html) were (to my knowledge) first. [Content Properties](https://developer.atlassian.com/static/connect/docs/latest/modules/confluence/content-property.html) have a type so they can perform some more advanced use cases, I suppose.

Note that there is acutally a REST API to query page properties:
> rest/masterdetail/1.0/detailssummary/lines

But I think it is somewhat a trial-and-error-approach to get it working. [How to use Confluence API to get actual data / values from Page Properties](https://community.atlassian.com/t5/Confluence-questions/How-to-use-Confluence-API-to-get-actual-data-values-from-Page/qaq-p/617867) provides some information to get started.

And now some advertising ... :)

Since we had similar concerns with what is natively provided, we developed a commercial add-on, the projectdoc Toolbox, to support properties (and some other [features](https://www.smartics.eu/confluence/display/PDAC1/Features) to support documentation) based on the concept of page properties. The (free) [Web API Extension](https://www.smartics.eu/confluence/x/v4F4Ag) for the projectdoc Toolbox provides a REST API to fetch and update properties.

The basic building block is a [projectdoc document](https://www.smartics.eu/confluence/x/rgDG) (which is a Confluence page with properties and sections). More on the add-on and can be found on [its homepage](https://www.smartics.eu/confluence/x/1YEp) and the [online manual](https://www.smartics.eu/confluence/x/EAFk). Maybe you would like to have a look ti check, if it matches your requirements.

The [projectdoc Toolbox is available on the Atlassian Marketplace](https://marketplace.atlassian.com/1212629) for Confluence Server. Also [a number of free extensions and free doctype add-ons](https://marketplace.atlassian.com/vendors/1211428/smartics) (the later also as [open source projects on Bitbucket](https://bitbucket.org/smartics/)) are available.

comments: author: M_S_
body: Thank you for the feedback, basically confirming my concerns.

I had noticed projectdoc Toolbox - but frankly, I find it to complex for what we want.

Content properties and page properties should be harmonized and I believe it to be Atlassian's responsibility to cleanup any (historically grown) discepancy.