I've mentioned this before but didn't get any responses to the feature idea/request. I think it's an extremely important feature so I'll explain it again and see if there's any interest. Almost all other big player CMS systems have this type of feature.

A module recycle bin.

I often have clients who don't fully understand how to add/delete pages, change module and page titles, etc. It's a tad confusing until you understand the concept of a page that contains modules and that a "title" could be in different places.

Getting off subject a little, but what sometimes happens during that client confusion is that they will delete a page or module from the page in order to change the "title" for example. Of course removing a module and re-adding it with a new name effectively deletes the content that was in that module. I've had clients delete modules/pages that had a ton of very complex formatting and rebuilding the page content wasted a LOT of time.

It would be AMAZING if mojoPortal included an option to save all deleted (HTML Content) modules with an option to view what has been deleted and possibly restore it to a page.

FEATURE DETAILS:

• I was thinking it's a site-by-site setting as to whether HTML modules are archived when deleted, or permanently deleted.
• There could be a new link/page (with permission options) that would take users to a page listing all the HTML modules that have been deleted (date/time stamped) with an option to preview the content from the module.
• The user could then choose to restore the module to a page (any page, as selected from the treeview of pages). The module could simply be added to the "center" panel at the bottom of any other existing modules on the page (for simplicity). The user could then move the modules around as desired through the normal options.
• I'd assume the deleted HTML modules would move off to another table in the database for storage. When a module is then restored to a page it's deleted from the module "recycle bin" and inserted into the CMS as a normal module.

Any ideas or thoughts? I've had many people delete pages/modules on accident and there's no way to really get that content back. The content versioning is GREAT, but it doesn't help if the module is deleted.

If the above is more difficult than it sounds I would be thrilled with nothing more than having the deleted HTML modules (with their content) go into a holding database table. This way when I get a frantic client call I can go into the database, copy the HTML from the field and paste it back on their web site (saving the day). This alone would be a life-saver, the GUI interface and ability for end users to restore their own modules would just be icing on the cake.

I could make a small donation to have this features, if others did the same maybe it could become a reality.

Hi,

First I'd like to point out that removing a feature instance from a page does not delete it and creating a new instance with the same name also does not delete the original one. There are only 2 places where a content instance can really be deleted, one is using the delete button at the bottom of the feature settings page, and the other is from Content Manager (which is only available to admins and content admins roles).

So really the only place non admin users can delete a feature instance is from the feature settings (ModuleSettings.aspx) page. We could easily add config setting so that the delete button there is only available to admins as well.

If the content instance has not been deleted, it can be restored to the page (or any page) from Content Manager by and admin or content admin user.

Handling deleted pages is a bit more problematic. Any solution has to consider what to do in terms of the friendly url. If we don't actually delete it then we cannot re-use the url.

Keep in mind that deleting a page does not delete the content instances on the page because they may be used also on other pages, so again the content of the page is not lost by deleting the page, it can be recovered from Content Manager.

Best,

Joe

If you look in Content Manager you will see that each feature instance has a number next to it indicating how many pages it is used on, so unused content is easy to find and delete because they have 0 next to them. However, be aware that if you are using some instance on all pages like using modulewrapper in the layout.master file, that does not get counted as a page (content manager has no knowledge of it) so a content instance used that way may show it is used on 0 pages in content manager but is really used on all pages used by the skin.

For now I will add a simple config setting for the next release, so you could ad this to user.config 

<add key="HideModuleSettingsDeleteButtonFromNonAdmins" value="true" />

which will hide the delete button from users who are not admins or content admins.

Normal users can still remove it from PageLayout.aspx and that seems most natural since that is where they add things to a page. I'm less inclined to add a remove button to ModuleSettings.aspx since that controls settings on the content instance regardless of whether the instance is on a page or multiple pages or no pages. So the scope of ModuleSettings.aspx is not limited to the current page, it is scoped at the module instance. I don't rule out ever adding a remove button there but I think it is not really needed and confuses the scope of what is being edited because modulesettings.aspx is about the module not about the page and mixing the two blurs that distinction.

Best,

Joe