Property (content)
A property is an attribute of a content item, such as an article’s title, an event’s date or a listing’s price. Developers declare it in the content type definition. Editors provide its value through a field when they enter the content. Together, these attributes decide what a content item can hold.
Definition and how it works
Choosing properties commits the team for a long time. Whatever is stored in a separate attribute can be filtered, sorted, reused in a list, translated on its own or served through an API to another application. Whatever is buried in a large text field cannot. An event date typed into the body of an article will never let you list upcoming events.
Technically, each attribute has a type (text, rich text, date, number, yes/no, reference to another content item...). It can be translatable or shared across all languages. It can hold a single value or a list. It is declared in a .cnd file shipped in a module, the code package installed on Jahia.
Academy documentation: modifying existing content definitions
Related terms: Content Type · Field · Property (jExperience) · Content item · Content type definition · Content Editor
Resources that cover this term
- CMS Security: Why It's Crucial for Your Business
- How Integrators Can Design the Ultimate Content Author Experience in a CMS? (Integrators Tips Pt.1)
- How to develop a DXP platform with the best UX for business users?
- What Is a Content Management System?
- What is Content Architecture and Why Does it Matter?
- Choosing the Best Multilingual CMS: the 9 Criteria That Matter
Property vs field: the differences
The property is the stored data. The field is how it is entered. The content type is the set of attributes that describe one family of content.
| Concept | What distinguishes it |
|---|---|
| Field | The field is the input control displayed in Content Editor. It edits a stored value. |
| Content Type | The content type brings together the attributes of one family of content, such as a job offer. |
| Property (jExperience) | In jExperience, the same word describes a visitor, a session or an interaction, not editorial content. |
Property in practice
A Job offer type has separate attributes for the title, location, contract type, publication date and description. The site can then offer a filter by location and contract. It can also drop outdated offers from the list automatically. Had location and contract been typed into the description, none of this would be possible without re-entering the data.
During scoping, ask of each piece of information whether anyone will ever want to filter it, sort it or reuse it elsewhere.
Frequently asked questions
Do all properties need to be translated?
No. A property can be translatable or shared across all languages. That choice is made in the type definition. A title or a description gets translated. A price, a date or a reference to an image can stay shared. Getting this right spares teams from re-entering the same value in every language, or from being blocked when a local adaptation is needed.
Can a property be added to a content type already in use?
Yes, as long as the new attribute carries no constraint, such as being mandatory. It is then added to the type definition and deployed with the module. Existing content items have no value for it yet. Plan who will fill it in, or how the display behaves when it is empty. Removing an attribute or changing its type is far riskier. Content items that use it can become unreadable or uneditable, so the data has to be migrated first.