Ibexa DXP Discussions

Community discussion forum for developers working with Ibexa DXP

We want your feedback on `Unpublish`

What action would you like to be executed if you unpublish in the future (scheduled operation)?

  • Sent the content item to trash
  • Hide the content item
  • Move the content item to a different container (not visible on the frontend website)
  • Keep the content item and change the status to unpublished

0 voters

This poll has also been shared on our Slack workspace. Check to see what feedback we got there already.

I voted for “Hide the content item” as only few other did. This comes certainly from a legacy perspective, where object states did not exist and hiding was the natural way. I would certainly vote for “Keep the content item and change the status to unpublished” if there is an easy way the hide the item in this process, as this is what you usually want to do - hide from users and search engines.

Thanks @dfritschy for your explanation.
On eZ Publish, both options (hide and delete) were available (https://doc.ez.no/eZ-Publish/Technical-manual/3.8/Features/Cronjobs/The-cronjob-scripts).
As @emodric said on Slack, hide is at the location level not at the object level, so we will have to hide all the location during the un-publish operation. Meaning that if you want to make a content accessible again you will have to un-hide all the locations and the system will not be able to restore the previous state of the visibility.

Hi everyone!
I wanted to keep you posted about the progress on this feature.

After multiple discussions, we finally decided to reuse the archived status of version. Next sprint, we will have a spike (https://jira.ez.no/browse/EZP-30005) in order to confirm the technical approach.

If you want to see the user experience, we created a prototype: https://invis.io/TEPZLVYJGH5#/340463127_1_Unpublish_

Also, this feature will be available for the opensource edition, the scheduling part will be on the enterprise edition.

Thanks again for your inputs and feedbacks.


Well, that’s disappointing :frowning:

May I ask what was the point of a community vote ? It showed that the community pretty much agrees on the correct course of action for this feature, which would be a new status.


I too am a little disappointed. To me ‘archived’ is a totally different state then ‘unpublished’. For example what state should the content be if it is on a reoccurring schedule? Don’t believe it should be going back and forth from ‘archive’ to ‘published’, and just toggling visibility seems wrong too. To be honest would be nice if we could add our own defined state so we would have a versioned state which object state does not do. Maybe I’m looking at this wrong.


Hi @emodric @wizhippo!

I can understand that you are disappointed. Let me give more details about our conclusions.

When we started to work on this feature we wanted to do it like it was on eZ Publish (sending the item to the trash). We have a lot of requests to implement the same features exactly like they are on eZ Publish :slight_smile:

When we asked you this question, it’s because we wanted to have your feedback and unpublished status was not part of the available answers on the first poll (on Slack). You suggested this new status, we listened and we started to work on this option.

After several iterations (design, specs, meetings with the engineering), we thought that it might be too risky to introduce a new status before v2.5 LTS (it’s a shorter release due to the certification phase). Then, we realized that we already have an archived status that can do the job. “Why not using it?”

We also discussed the naming and editor experience. From the user perspective having a button Archive / Unarchive that matches the version status makes more sense.

The end result (frontend) will be the same: the content won’t be accessible. The visibility of locations won’t be changed, meaning that Unarchiving a content item will restore the content like it was before. So there is not a big difference with unpublished status

For more transparency with the community and because it was a change compared to what has been discussed here, I decided to share it with you before the spike that we will have during the next sprint.

Happy to keep discussing.

Details about the version status:

  • archiving a content item will change the status of the published version to archived.
  • unarchiving a content item will change the latest archived version to published
  • when a content item is archived it won’t be possible to delete archived versions
  • editing and publishing an archived version will create a new published version and the content item will be visible again
  • Error will be displayed on the frontend when accessing sub-items of an archived parent.

I feel like you’re mixing apples and oranges here. Archived status on content has a well defined purpose both on content (sending it to the trash) and on version (historical published versions), in legacy and in the new stack, and trying to fit another meaning to it is contraproductive. Archiving a content also has a very different semantical meaning than unpublishing a content.

The end result will be a mess where potentially dangerous situations may arise, e.g. flatten scripts that clean up archived versions of content, which might now delete the entire content if all it has are the archived versions.

1 Like

Hi everyone!
I wanted to share another update on this feature. After a spike, @slawomir.uchto was able to confirm that using another version status (unpublished) or using archived will be too risky for v2.5LTS. The system and most of the interfaces rely on the published version.

@slawomir.uchto was able to explore the approach of hiding the content item. One of the main concern was that the user won’t be able to restore the previous state of the visibility. During the spike, he confirmed that it’s possible to store this information, so user can definitely go back to the original state (content item with multiple locations).

I checked internally with our Customer Success team and our Sales team and it seems that this option is a good one.

In view of those new details, what do you think about hiding for scheduled unpublish feature?

What about not conflating different concerns? Namely hide-vs-archive-vs-trash and do-action-at-future-time?

In eZ4, there were different way of ‘unpublishing’ a content, based on a cronjob:

  • change-location-hidden status (provided cronjob)
  • set object state (custom cronjob)
  • send to trash (custom cronjob)

What all of those had in common was that, to make all of said actions available for all contents, one had to introduce a ‘hide’ field (or ‘show’ field) in all content classes.
Which is not optimal.

Imho what was missing now (and probably is still missing then) is a way to have multiple hide/show dates attached to every content - without needing to create content fields.

What are the details of the action to be taken at those moments can then be left to the implementor - as requirements still vary from site to site: one will prefer hide, one will prefer delete, one archive and one change-state…

ps: for what is worth, I’d still vote for putting to good use the existing ‘content status’ field. It really is under-used at the moment, and it makes sense at 1st sight to have mutally-exclusive ‘archived’ and ‘published’ states…
(for the record: I did not even check the poll results before writing this)

In eZ Publish, the “official” unpublish action was to send the item to the trash (https://doc.ez.no/eZ-Publish/Technical-manual/3.8/Features/Cronjobs/The-cronjob-scripts#unpublish).
When I asked on slack and on this thread about unpublish, nobody voted for sending the item to the trash. I am not sure this feature is used. If needed, you can create a custom cronjob for it.

Changing the object state is still possible by creating a custom cronjob.

On eZ Publish 2.5, a cronjob will take care of hiding all the locations of the content item. It will be consistent with the publish later feature: the date will not be a field.

I totally understand, but as I said it’s a big change for 2.5 and it’s too risky.
Something we might consider for 3.x

This might cause some confusion this will create by adding yet another, but different hidden state, which again is not controlled by permissions…

But besides this, doing this change in 2.5 might be a bad idea if we take into account legacy bridge usage.