I made a change to a widget on a page, and saved it. Now I want to revert back to the previous version of that widget. How do I do that?
If you have workflow or versioning enabled you could rollback using the Versions tab under properties of a page.
If you have not, or the version is no longer available the only thing would be looking into a Database backup.
Related
A business owner of my ticket tracking app in Xpages wants to track every change to the document. If a user opens the doc in edit mode but doesn't change anything, then no tracking. If, however, they open up a document and change one field, I have to capture that.
Here is my solution. When a user edits a doc, I create a "shadow document", which is a "before" vision. When the user saves I am comparing field for field for changes, and then acting appropriately.
Is there a better way to do this?
This is another good use case for Java beans. If you create a bean which sits between XPages-UI and Domino back-end document then you can easily track field changes.
Karsten Lehmann wrote a blog about it some time ago.
... and you could use the OpenNTF Domino API that has functions for exactly this. As far as I remember there is an example of this in the demo database. Not sure if it is also in the new version of the demo database - but then you may just need to find an older version (e.g. for milestone 4.5 where I saw this).
/John
I have content editor on my team site where I added several links. But today while adding some new links, content editor crashed. so now when I tried to open site containing content editor, browser stop working.
The quick solution is:
I can delete the existing content editor and create a new one (using ?contents=1 in the corrupted team site). But since my content editor contains lot of links, so is there a way where I can roll back content editor to previous version (till yesterday afternoon)?
Any suggestion is appreciated.
Your previous version is probably lost in the mess. You will have to go to the site admin, and close / delete the webpart and start over. You may be able to simply close the web part (from site admin) and then edit the web part properties to salvage it's contents.
Either way, content should not be added directly into a Content Editor Web Part (for this reason.) Instead, use the option to point to a file in a Document Library elsewhere in your SharePoint site, with versioning enabled.
Then, in the case of the CEWP blowing up the page from an edit to the contents, you can revert to the previous version of the document, and the CEWP will immediately be updated, and the page immediately restored.
Stackoverflow is about programming related questions, your question is more of a user question.
You can't roll back a content editor. If you have versioning enabled for the page you have the content editor on, you might be lucky and can retrieve an earlier version. Otherwise you could only check the database for the content editor contents, but that will be a pretty tedious task finding it.
I have two webparts that currently have the default "MyGroup" property in the elements.xml file. I'm simply trying to change these values to something more descriptive by updating both the Group and QuickAddGroups property values; rebuildng my dll, uninstalling from WSPBuilder and then re-deploying (using WSPBuilder). However, this does not seem to work. I still see the old property group listed. I've also tried manually deleting the webpart from the webpart gallery page to no avail. What do I need to do? Is there an stsadm command that I should run, perhaps -uninstallfeature or -deactiveatefeature?
Aside from making sure you get it right the first time, manually deleting the web part from the gallery is probably your best option.
If that doesn't work, it may just be the ordering - try deactivate the feature, delete the web part, then activate it again. Also check that the elements.xml in the 12 hive contains what you expect - occasionally these things refuse to update for no apparent reason.
When I deactivate a feature, or even just after removing a Solution package, I can still choose to select the Master Page which belonged to the feature I removed. This is a problem for me.
The only way to get rid of the hanging reference is to open SharePoint Designer and to browse to the sites _catalog directory then remove the .master files from the masterpages directory.
Is there a way to cause different uninstall behavior which would remove the hanging reference? If so how?
Thank you,
Yes deactivating the Master Page feature will not remove the master page from the Site you need to do it manually or using some feature receiver code that hooks the deactivating event.
My MOSS is a bit rusty, but can't you write some code in the
feature_deactivated event?
Do a manual remove of the master page there?
I am developing publishing site. I have some layouts that are pre-populated with web parts and have a problem when I need to make some change on the layout.
Deployment succeeds but I still see old version. If make I change in SP Designer it is reflected OK but not if the change is done by the feature that is being deployed.
It looks like after I deploy particular layout any site collection in that web application will have the first version.
I have tried deleting complete site, all the pages, layouts and nothing happens, after deployment I still see old layout.
Current solution for this problem was that I take new virtual image and start with clean machine.
Real problem is how to solve this on clients installation without reverting to clean machine. There will be some bug fixes and I will have to send new WSP file with some changes in layout.
Is there any way to force SharePoint to use newly deployed layout and not some old Unghosted version?
If the layouts are without web parts I don't have this problem.
Update
I am using default "Publishing Portal" and deploying layouts using features. For development I am using VSeWSS 1.3.
tried in SharePoint designer to detach page from layout and attach it again but still no results.
Since you are using VSeWSS, you can execute your own code upon feature activation. So try writing an SPFeatureReceiver that will call SPWeb.RevertAllDocumentContentStreams() to reghost directly after feature activation on the web(s) in question.
If this doesn't work, then the problem isn't about ghosting, maybe it's about Orphans then. But try this first.
If it's a feature that you are deploying you have do deactivate the feature and activate it after deployment again. And don't forget to do an IISRESET or an AppPool recycle.
If your new site collection has the first version of the layout make sure that it is really your new feature version that you are activating.
Try to reject your solution first and add the new one after that.
Are you using Site Definitons or Site Templates? If you are using either of these it may not update after initial provisioning.
Try completely retracting and deleting the solution from central admin, resetting AppPools and then redeploying the solution.
Make sure your element manifest for your feature specifies that existing files should be overwritten.
Looks like some folks have had problems with layouts too...
See http://msdn.microsoft.com/en-us/library/ms459213.aspx
If you are developing new sitedefinition, you can attach your new layout in the onet.xml file by using the property, i hope it will help you
-->