I think the correct phrase would be "Mark for Deletion," but that might be long enough to cause styling problems.
The current behavior may be confusing to new users, but it's consistent. When you mark a resource for deletion, nothing changes but the 'deleted' field. It's not my decision, but I'm pretty sure it's not going to change. Unpublishing it would create its own brand of confusion -- e.g., "I accidentally marked a resource for deletion. I undid that, but now it doesn't show up anywhere."
-
☆ A M B ☆
- 24,524 Posts
That's what lexicon files are for.
yeah, a field 'save_the_published_state_before_deleting' could be added to the resource-table.
Then the status could be saved, before marking a resource as deleted and unpublish it at the same time.
But don't you think, this overcomplicates things to much?
If we had fields for all scenarios like that, we would probably double the amount of fields in all tables. Unnessesary Complication.
No, if you really need that functionality, you, as the developer of the website, will have to create a plugin, maybe store that value for 'save_the_published_state_before_deleting' into the properties of the resource and get it back with a plugin, when undeleting the resource.
[ed. note: Bruno17 last edited this post 10 years, 7 months ago.]
@bruno17 - There is no need for new fields it could all be done with existing ones.
You simply check the resource's published state. If it is unpublished, you leave it alone. If it is published, you set the published field to 0 and you assign the unpub_date field the same timestamp you use for the deletedon date.
On undelete you compare the deletedon and unpub_date, if they are the same then you change the published field back to 1 and clear the unpub_date, same way you do for the deleted on date. If the dates don't match you again leave things alone.
As you haven't messed with any other publish or edit fields, the resource should return to the same state as before.
But what really puzzles me, is why everyone is against a traditional delete function in the core, a standard function everyone expects when dealing with docs or files? Why is everyone so intent on preserving this idiosyncracy of MODX and forcing users & developers to adapt? The current pseudo-delete could be retained as well adding a real delete in the core.
[ed. note: mrcycling last edited this post 10 years, 7 months ago.]
I tried Susan's suggestion.
You can go to System (gear icon) -> Lexicons.
In the core namespace, default topic changing 'Delete' to 'Mark for Deletion' (or whatever) changes the button on the Create/Edit Resource panel.
In the core namespace, resource topic, changing 'resource_delete' to 'Mark for Deletion' (or whatever) changes the Resource Tree context menu.
These changes will survive upgrades to MODX.
Once resources are marked as deleted, you can remove them completely with a single click on the trashcan icon at the top of the tree.
Most extras that I'm aware of will ignore resources marked for deletion (unless told not to). Wayfinder and getResources certainly do. Have you found any that don't?
BTW, I would not be opposed to changing the 'Delete' entry in the MODX lexicon files to something clearer, but 56 lexicon files in 28 languages would have to be modified to do it. The 'Undelete' options would also have to be changed, though I'm not sure to what (Unmark for deletion?).
[ed. note: BobRay last edited this post 10 years, 7 months ago.]
@BobRay - Actually I came across this quirk while writing a plug-in. My deleted resources were not behaving as one would intuitively expect for a deleted item. While watching the process to find my error I discovered that MODX's delete is not really a delete.
And, yes you are right, adding a proper delete option (and perhaps renaming the old one) would require many lexicon changes. But then most every improvement to the manager UI likely requires lexicon updates, so that shouldn't be a barrier reason for not improving.
I think one of the barriers to this idea is that the long time users are used to the quirk and how to work around it, so it has become second nature to them and so they see no need to change. But for casual users and new users the quirk is an issue. One of Susan O's selling points for MODX is that it doesn't force it's ideas about how something should be done, yet here it is forcing it's non-standard version of delete on us making us adapt our code to fit.
Imagine if excel used this type of delete, a cell value is removed but is still used in formulas. Forcing you to rewrite all your formulas to ignore cells C34 & D99, because they are 'deleted' but really still there.
[ed. note: mrcycling last edited this post 10 years, 7 months ago.]
You didn't answer this question:
Most extras that I'm aware of will ignore resources marked for deletion (unless told not to). Wayfinder and getResources certainly do. Have you found any that don't?
I have used very few plug-ins, basically just wayfinder in a test install and played with articles a while back. As you mentioned the developers have built in the additional code to filter deleted but still published. And I have had to build that extra filtering for my plug-in. But why should extra filtering code be forced on people to recreate a standard software function? Why is the old cadre so deadset against a standard, intuitively understood delete function? While yes I started this thread about changing the existing delete, the current code could be retained for folks who have found it useful while adding a proper delete. They don't have to be mutually exclusive.
I don't know of any plugin or snippet that requires extra filtering to keep it from showing deleted but published resources. If there is one, you need to tell us which one it is. The solution, imo, is for it to be fixed.
I agree with you that using 'Delete' is confusing, but once that's changed and all extras ignore deleted resources (assuming that they don't already), there's no problem left to fix.
@BobRay - the "extra filtering" I refer to is the code that the developers had to write originally to filter out deleted resources, that currently appear in a general list of resources. I am not talking about extra things that the end user has to add.
And I think overall my goal is not so much to correct an error, but to add an improvement. The current function could be retained to allow existing plugins & extras to purr along, while adding a proper delete to benefit everyone in the long run.
