Make Entry status extendable

[jonassiewertsen]

We would wish for an option to make an Entry Status extendable. I would guess we might need an extendable PHP and Vue solution, depending on how this should work.

We are talking about those dots:

For many cases the defaults are great, but making them extendable (or giving the option to overwrite them, would be really helpful). This would open up for projects, to extend an entry status.

Possible usecases for an article could be:

• unpublished
• prepared
• review
• approved
• published

Possible usecases for an orders collection might be:

• unpaid
• pending
• expired
• ...
• paid

Statamic should not offer them, just making it possible to extend the behaviour.

[aerni]

This would be a great addition! Probably connected to this idea.

[mikemartin]

I'd love to see this. Here are some examples of content workflows from GatherContent:

[edalzell]

Questions for those that are interested in this:

• what should the status be if an entry has an existing status (published, expired, etc) and has a custom status?
• should this be a different method, instead of status? If so, ideas on name?

[jonassiewertsen]

It would be my personal expectation to only have one state/status. This does avoid making things too complex.

In that case, an entry has a 1 to 1 relation with the state. If an entry is published, it's published. Not for example approved && published, ONLY published. As shown above in a few examples, an entry could only have one of those states.

I would think that the published state does some publish action behind the scenes and that all other states, are some kind of internal draft status with a custom label, custom icon and custom status name. On top of that, it would be super helpful to fire an event if a status does change with the entry and belonging status information.

By having that event, we can listen to a change and specific states, to add custom behaviour via Event listeners.

For other use cases, you can always add another fieldtype to collect som extra information, which isn't coupled that strong to the entry itself.

[edalzell]

On top of that, it would be super helpful to fire an event if a status does change with the entry and belonging status information

@jonassiewertsen couldn't we use the existing EntrySaved event? What's the use case for a new event?

[jonassiewertsen]

@jonassiewertsen couldn't we use the existing EntrySaved event? What's the use case for a new event?

Actually, I think that might be the best option.

[aerni]

What about entries that don't fall into a publishable workflow, e.g. a collection of orders. They should never appear on the frontend and don't need a status of published but an equivalent status like paid.

[jonassiewertsen]

Good point!

If no slug is provided, a published order can't be visited anyways. But it's the last status, as it's finished and I think you want the green dot to show up as well.

Might that be solvable via an alias or a different label, to keep the same workflow somehow? Just thinking out loud here :-)

[edalzell]

No reason you couldn't rename the published status, similar to how you can rename the title field

[jesseleite]

Should these custom statuses be handled separately from our internal status? The reason I mention is that the status field is meant to be dynamic, and Statamic references the 4 existing statuses in multiple places...

• Published & future/past date behaviour handling
• Status Filter
• Querying status on various tags
• etc.

I'm thinking the custom statuses you're adding are more for team flow, whereas the status field is used to determine when to actually show/hide entries by Statamic. If we allow extention of status, we'd have to be super careful of where it's used by Statamic.

Conversely, if you had your own separate team_status field or something, it can still be filtered, queried against, etc.

Curious what @jasonvarga thinks 👋

[jonassiewertsen]

What do you think @jasonvarga ?

[dominikradl]

Is there any ETA on this? This sounds super promising and would be a great addition that sometimes is asked for (because it's known from other CMS).

[bernhardberger]

I just stumbled upon this in the docs and I would need the status depend on a start date(time) and end date(time) for some (a lot of different) time sensitive collection entries. Currently this doesn't seem possible with Statamic but I'd kinda want to avoid implementing complete custom logic of showing/hiding entries everywhere when there's already similar functionality in the CMS itself (publish date)

[emran-alhaddad]

Hi from 2024 🙌 , is there any updates on this idea ??