decaporg / decaporg/decap-cms

Add a first-class Hidden status for collection entries

Open
#7,945 0 comments 0 reactions 0 assignees View on GitHub
area: ui/collection
Dominant language
JavaScript
Stars
19.4k
Forks
3.1k
Avg merge
1d 14h
Merged PRs (30d)
9

Description

## Is your feature request related to a problem?

Decap CMS does not provide a first-class **Hidden** status for collection entries.

In the current editor, an existing entry displays **Published** in the status dropdown, but the available actions do not include Hidden. A project can add a custom Boolean front-matter field such as `hidden: true`, but that field is treated like ordinary content rather than an entry lifecycle state. It has no standard status control, badge, collection-view behavior, or configurable convention.

This is separate from an unpublished Draft. A hidden entry may remain committed to the published branch and editable in Decap while being intentionally omitted from the public site’s listings and search index.

## Describe the solution you’d like

Add a configurable **Hidden** status for collection entries.

Ideally:

- **Hidden** is selectable from the editor’s status dropdown alongside Published.
- Selecting it writes configurable metadata to the entry, for example `hidden: true`, `published: false`, or another project-defined field/value.
- Hidden entries remain accessible in Decap CMS.
- Hidden entries display a clear badge in collection views.
- Collections exclude hidden entries from their default view, with an explicit **Show hidden entries** control.
- Returning an entry to Published reverses the configured metadata change.

Possible configuration syntax (illustrative only):

```yaml
collections:
- name: posts
folder: content/posts
status:
hidden:
field: hidden
value: true
```

The mapping needs to be configurable because different static-site generators and existing sites use different front-matter conventions.

## Public-site behavior

Decap CMS does not build the public blog or its search index, so the consuming site generator would still be responsible for honoring the configured metadata and excluding hidden entries from public collection pages and search.

The value of this feature is to make that convention a first-class, understandable status in the CMS rather than exposing it only as an ordinary Boolean field.

## Alternatives considered

A Boolean widget can already write `hidden: true`, and a site can filter on it during its build. This works technically, but:

- authors must understand an implementation-specific field;
- the editor status still says Published;
- hidden entries are mixed into the normal collection view;
- there is no standard badge or reveal-hidden workflow.

General collection filtering in #3617 may provide part of the collection-view behavior, but it does not provide a first-class entry status or a configurable metadata mapping.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the related collection filtering work in issue #3617 and the existing status dropdown and collection-view behavior described here. Define how configurable hidden metadata, editor access, badges, filtering, and the Published reversal should work, then verify that the behavior remains separate from Draft status and public-site generation.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.