Archive is very confusing for end users

[guyvanbael]

The archive command that replaces the delete from draft is rather confusing. I think Archiving should mean that the page disappears from the sitetree and is stored somewhere where it can be retrieved later on. Now if you log out and do a flush all, log back in again... page is gone (which can't be the meaning of 'archive'). Next to the archive command, there should be a real DELETE function which deletes the page (after confirmation of course) totally.

[dhensby]

If you read the PR discussion around this, the Archive functionality actually makes a lot more sense and performs the same function that "delete" used to.

Basically, the CMS has never allowed users to "delete" pages (the implication of deleting something is to remove irretrievably); the function of deleting from draft site and live site separately is almost always performed together and the distinction is often misunderstood or confusing for CMS users.

Therefore, the workflow to remove a page from a site has been simplified to a single action ("archive"). Although one could mis-interpret "archiving" as storing away out of the SiteTree but still accessible by URL, that is not it's purpose and other language is equally confusing for it's ambiguity.

Ultimately, it comes down to semantics and I think "Archive", whilst not perfect, gives a pretty good indication of what is going on.

[chillu]

There's been discussion on this naming change here:
silverstripe/silverstripe-framework#4189
#1203

In terms of adding the ability to "fully delete" a page from the CMS, that's a new feature request and should go through uservoice instead.

As for the page "disappearing" after navigating away from a recently archived page and reloading the browser window, that's by design as well - you should always see the currently edited page in the tree, irrespective of its state.

Maybe there's a better UI flow to make this clearer, but I don't think this github issue is at a point where its actionable on either of these points. Closing off for now.

[patricknelson]

This could be useful (ability to "Fully Delete"). After looking through my system, I too was confused when I first started dev on my first major SS website only to realize:

• I had many ->onBeforeDelete() methods on descendants of SiteTree which killed relations that should have been preserved.
• I was about to refactor these to ->onBeforeArchive() because this was more of a real "delete" only to realize "Well what if the user restores?" (and that the ID is still retained, effectively making relation removal pointless as well).
• I looked for a ->ReallyDeleteSrslyGuiz() method where I could stuff this old code to help clean things up.

Now I'm thinking that lots of old assets and relations and etc which never end up ever being restored will clutter my database and I have no way to clean out. This would definitely be a very useful feature. I couldn't find it on UserVoice so I created something here.

https://silverstripe.uservoice.com/forums/251266-new-features/suggestions/17846074-ability-to-fully-delete-page-from-archive

[jeffwhitfield]

Indeed. If anything, there needs to be a way to "prune" pages and resources that are in an archived state. Basically, the only way you can officially delete something is if it's in an archived state. That to me would make sense and also offer a bit of a safety net. Wanna totally delete something? Send it to Archive first...then delete it. :)