Why does deleting a resource not unpublish that resource?

Pretty much what the title says, why does deleting a resource not also unpublish it?

It seems that deleting a resource only changes the deleted data to 1, but leaves the published data at 1. So any function that retrieves a list of published resources for processing also gets the deleted resources prior to emptying the trash.

One would think that when we delete a resource we should also be removing it from any collection of published pages.

I think the assumption is that you're just marking the resource for deletion, not editing its other fields. If you change your mind and undelete it, it should be the same resource as before.

You have lots of options. You can empty the trash if you really want it gone. You can unpublish it rather than deleting it if you plan to publish it again in the future. With many extras, you can change the criteria to ignore deleted resources.

Finally, you could create a plugin attached to the OnResourceDelete System Event that unpublishes deleted resources with this code:

I guess my assumption of what delete means is different, for when I hit delete that means I have decided that resource is no longer wanted, so I expect it to be gone and out of circulation.

And while hitting delete marks it for destruction, it doesn't pull it totally out of the system. So why couldn't delete.class.php & undelete.class.php (or any other related files) be modified to unpublish when it deletes. Seems like it would save developers some additional filtering to remove deleted but still published resources. [ed. note: mrcycling last edited this post 10 years, 7 months ago.]

I think the plugin above does exactly what you want.

I don't feel strongly about it, but I think the whole point of the current system is that if you accidentally delete a resource, you can undelete it in one step.

You have the option of changing the behavior with a plugin, but if your suggestion were followed, people who want it the way it is now would lose the current option because there would be no way to tell if the resource was previously published or not.

BTW, if you really want the resource gone in one step, you could do this in the plugin:

BobRay - Thanks for the suggestions, but I was fishing more for a discussion of the "why", as opposed to a "how to do" (thought I had clicked the discussion button when I started the thread).

I can think of a number of uses where we do not wanted deleted resources included with other published resources, but can think of no cases where a developer would want resources that are both deleted AND published. So it seems that burden of special filtering is being placed on the majority not the minority. And the functionality to restore a temporarily deleted resource's previous published status seems so simple to do logically.

Guess I have a hard time thinking inside the MODX box

I would not want it since deleted is not unpublished. They are two unrelated statuses.

One thing that I like about MODX is that it doesn't force me into things that it thinks ought to be done. If I want unpublished, I unpublish. If for some reason I want it deleted but published, I would have to publish it after deleting it, and now the publishedon date is changed.

Seems you have very special use-case.
For very special use-cases, there are the system-events, where you can hook in with plugins.

I don't want MODX to unpublish a resource, when I didn't say, I want it to be unpublished.
When I delete a resource, I want it to be marked as deleted, nothing else.

OK I got it, modx has a weird definition of what the word delete means. And I have to make a plug-in if I want a proper delete.

I wasn't privy to the decision-making process, but I'd guess that the reason delete doesn't really mean delete is that the real delete is not reversible -- the resource is lost forever. It's easy to select delete on the wrong resource (I've done it), and it's pretty handy to be able to undo that.

Also, automatically making a resource unpublished would destroy the original publication date. The way it is now, you can take a resource offline to work on it without losing the pub date just by marking it as deleted.

I think the issue is actually more a naming issue. What follows is something I posted in a Github discussion regarding changing MODX's delete.

Dictionaries defines "delete" as to remove, to erase, to eliminate. And I would be willing to bet that 99% of English speaking computer users (and probably non-English speakers as well) have that same understanding of that function. It is one of the most universal computer concepts ... save ... delete.

What MODX has is more like a HIDE, the resource is hidden from outside browsers but still active inside MODX. It is not a "delete" in any sense of the word.

Perhaps MODX needs to rename the current delete to Hide and then create a proper Delete function, so that everyone from the developer right down to Betty Boop Business Woman & end user automatically understands what it means.

Yes it means some developers will need to revisit their code and perhaps change OnDeleteXX events to OnHideXX events. And yes it may mean that in some cases someone might have to Hide and then Delete and then Empty Trash or perhaps add a modal on the trash can to offer options to remove hidden, deleted or all. But ultimately the end user will understand better and be happier, hence the developer will be happier, hence the creators of MODX will be happier, cause smiles roll uphill.

I think that the "proper delete" (delete and unpublish if necessary) I mentioned can be achieved with the same reversibility it currently has. A new delete class would have to be written that handled not only delete but also handle the unpublish republish functions to avoid any overwriting that the current publish class would do.