This project has moved. For the latest updates, please go here.

How to remove SPEasyForms from Ribbon

Mar 16 at 12:28 PM

We've removed SPEasyForms from some sites and it's completely broken the ribbons on lists! The entire ribbon is grayed out and the SPEasyForms button is still there. How do we remove the button if the solution has been deactivated and removed and all files have been deleted?!


Mar 16 at 8:36 PM
Edited Mar 16 at 9:03 PM
Hi Casey,

How did you remove SPEasyForms? i.e. did you remove it programmatically? did you deactivate the associated site collection feature (SharePoint Easy Forms)?

Either way, things obviously weren't cleanly uninstalled, meaning things that were installed via the SharePoint solution/feature packaging were not all uninstalled. Those fall into 3 broad categories:
  • Assets - the files in the 'Style Library', which I assume from your question were already deleted.
  • ScriptLinks - these are what load SPEasyForms and it's dependencies from the 'Style Library' on every page. Since the files are gone, most of these will do nothing (except try to load the files, give a lot of 404 errors, and result in a bit of a performance hit), but one of these is actually a ScriptBlock, not a ScriptLink, and it looks something like:
spefjQuery(window).bind('load', function() { spefjQuery.spEasyForms.init(); });
which is going to throw an exception because spefjQuery is undefined, so this could theoretically cause problems for any other JavaScript in the page. If you do view source in the browser and search for speasyformsassets and/or spef, you can quickly determine if these were left behind when you removed SPEasyForms.
  • Custom Actions - These are the ribbon buttons. These are going to be the most difficult to remove, because the only code I've seen to remove them does it at the list level, so you'd have to iterate all lists in the site collection, look for the buttons, and remove them. This is also probably throwing an exception because one of the properties of the button is EnableScript, which is set to shouldSPEasyFormsRibbonButtonBeEnabled() and that is a global function defined by SPEasyForms that is now undefined since you deleted the scripts. This is probably why the ribbon is screwed up (i.e. grayed out).
To Remove the Script Links

As it happens, I just wrote blog post for somebody else on Installing SPEasyForms in Farms Where Sandbox Solutions are not an Option. This describes a wiki page that you can drop in a SharePoint document library to install/uninstall script links. It will not remove script links put in by the sandboxed solution as is, it will require a little modification, say to delete all script links with speasyformsassets in the path and all script blocks that reference spefjQuery.

To Remove the Ribbon Buttons

I haven't done this, but you would need to write something like what's described in Add Replace or Remove Ribbon buttons programmatically. The code here is C#, but pretty straight forward and shouldn't be that hard to convert to PowerShell or JavaScript depending on your preferences. Again, you'd need to iterate all the lists in the site collection looking for speasyforms buttons. You can use the IDs or LabelTexts from SPEasyFormsCustomActions.xml to identify the buttons.

The article describes two techniques, one for removing custom buttons and one for remove OOTB buttons. I'm not sure which would work here given that the custom actions were installed via a solution/feature. You'd have to play around with it.

Obviously, there's no easy way to do this, it's pretty messy. If it's an option it might be easiest to add the solution back to the solution gallery, activate it, and then figure out the best way to cleanly remove it again. If it's not a huge number of site, that might be through the browser and let Microsoft worry about the complexity ;)

Marked as answer by mcsheaj on 4/1/2017 at 6:20 AM
Mar 16 at 8:44 PM
Edited Mar 16 at 8:52 PM
One more quick thing from past experience. I assume given the current issues with your site, that you may have an orphaned feature (i.e. the site has a feature enabled that is associated with a solution that no longer exists). This won't really cause you any problems until you go to migrate to a new SharePoint version, but then it can be a PITA. I haven't dealt with this in a while, but a Google search for 'sharepoint remove orphaned features' will turn up numerous hits ;)

Mar 16 at 10:34 PM
Edited Mar 16 at 10:35 PM
I just did some debugging of SetScriptlink.aspx, which is the wiki page with JavaScript to add/remove script links that I described in the blog post about adding SPEasyForms without sandboxed solutions. When it first loads up, it loops through the user custom actions of the site collection and does something with the ones that are script links. It ignores all others.

I put a breakpoint in that loop just so I could look at all of the custom actions, and the only one that is not a script link has a location of CommandUI.Button and a name of Ribbon.List.Settings.Controls.SPEasyForms.Action. This is the SPEasyForms button on the ribbon. I think if you delete this custom action, it will remove it from all lists.

Also, if you look through all lists and delete it like I described above, new lists will still have the button if you don't delete the site collection user custom action, so that approach is probably a no go.

I can probably write you something that will do this, but I don't know when I could get to it right now.

Marked as answer by mcsheaj on 4/1/2017 at 6:20 AM
Mar 31 at 6:47 PM

I finally got time to tackle this. Looping through all UserCustomActions for the Site Collection and removing them was the key.

Everything was definitely removed as it should have been but that was left behind during the deactivation of the sandbox solution.

Thanks for the ideas!

Apr 1 at 1:20 PM
Great. The user custom actions are all created by activation of the feature, and removed by deactivation of the feature. When you go through the UI to deactivate the sandbox solution, it also deactivates the feature, but I'm assuming you did it through script in which case that's a two step process. Deactivating the solution through code does not automatically deactivate the feature, so you still probably have an orphaned feature. It may never cause you any issues, but it will probably trip health checks when doing pre-migration to 2016.