eZ Platform Discussions

We want your feedback on `Unpublish`


#1

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.


#2

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.


#3

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.


#4

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.


#5

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.


#6

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.


#7

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.

#8

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.


#9

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?