It's a real drag and performance killer to have to load all the WebParts on a page and then laboriously hide and reveal all the ones relevant to user groups / permission levels. Especially when on the homepage (being the best place to show users their important stuff...) - it grinds the site/farm as well as causing major debug overhead. Surely there's a better way of targetting users with only their relevant webparts and not even having to load and hide irrelevant webparts?

So instead of using the old:

Microsoft.SharePoint.WebPartPages.SPLimitedWebPartManager mgr = null;
mgr = oWebUserTokened.GetLimitedWebPartManager(url, system.Web.UI.WebControls.WebParts.PersonalizationScope.Shared);
// first hide them all to avoid exposure…
foreach (System.Web.UI.WebControls.WebParts.WebPart thisWebPart1 in mgr.WebParts)
  thisWebPart1.Hidden = true;
    // and then reveal the required ones….
    foreach (System.Web.UI.WebControls.WebParts.WebPart thisWebPart2 in mgr.WebParts)
      if (boolThisTypeOfUser) // needs particular webparts
        if (thisWebPart2.Title == "Special Webpart Title")
        SetWebPartVisibility(mgr, thisWebPart2); // Show the WebPart etc
      else // check for other user types…

... and revealing the ones appropriate to the user, is there a way of bypassing to avoid loading irrelevant webparts at all?

I appreciate you may shout "use Audiences!!" but A) am on Foundation, and B) not sure if they load everything but then hide anyway, ie same overhead.

Seeing as we're in CreateChildControls() anyway, you'd have thought it was simple to merely avoid loading the irrelevant webparts, but either it's not, or I'm missing something obvious!

2 Answers 2


I would have your code that you have above within all the webparts!

if (boolThisTypeOfUser) // needs particular webparts
   //createchildcontrols as normal

can you see where im getting to? this way it knows to show the webpart by carrying on with the code within the createchildcontrols! otherwise dont do anything!

Your also getting rid of the looping each webpart within the webpart manager twice, once for hiding and the second for showing! this way there is no need to hide as nothing will be shown as no code will be run :)

also to minimise repeating code, you can create a seperate class project that does the working out for you as you have done and it returns a bool as you have shown above. Build the project and add it to each webpart projects references and call it whenever you want to check if the webpart needs to be loaded :)

clean, nice and fast ;)

  • Thanks for this Ali - you're right!! I gave up on that idea when it fell over bypassing itself and MS advisory services didn't seem keen, but tried it properly and it does cleanly bypass the object creation without error in it's own control. Much cleaner and faster indeed, thanks for pushing it! Mar 25, 2013 at 14:11
  • protected override void OnInit(EventArgs e) { if ( (!SPContext.Current.Web.CurrentUser.IsSiteAdmin) && HelperFunctions.IsUserType("Approver", SPContext.Current.Web.CurrentUser)) { base.OnInit(e); InitializeControl(); } } Mar 25, 2013 at 14:12
  • glad to see thats its helped you out :) , its a method that i use and is easy enough for loading time ;) , i use this method when like you i dont want to load anything and therefore why do pointless loops when the webpart can handle it itself! this saves on resources and the dll for checking stops repeat code in multiple weboarts :). happy codeing!
    – Ali Jafer
    Mar 25, 2013 at 14:23

No matter how you do it it's going to be a major headache when you're only limited to SharePoint Foundation. You don't have any advanced out of the box user/audience control with SharePoint Foundation.

  1. When you insert webparts, to avoid heavy load on the page, set them to hidden right after you insert them on the page. That way they are already hidden and won't be loaded until told so by what code you fabric.
  2. Use prefix in your webpart titles to easier tell your code which ones to display when.
  3. You need to manually, either through code or external files, tell the current page which usergroups are allowed to see specific webparts.

What you practically have to do is re-invent what is already default in SharePoint Server.
I would recommend buying the SharePoint Server if it is within your price range.

  • Thanks for conf Daniel - am doing your 2 and 3 fine but just want to not load the webpart rather than "load and hide". Clients want to UAT the basics before committing cash for functions, but this basic grind is killing it. So can you load WebParts programmatically instead of inserting them onto page? Is that what you mean by 1, as I'm not sure how to do that and if it will truly avoid loading them. Mar 22, 2013 at 18:09
  • @Europhile When you insert a webpart on the page, in the title row of the webpart there is context menu in the right side. In this menu choose "Edit webpart". This will open a toolpane for the webpart in which you have 3 tabs. Open the "Layout" tab. It should have a chechbox which says "Hide". Check this and press OK. This should hide the webpart when the page is displayed.
    – user2536
    Mar 22, 2013 at 18:24
  • did that before - so you're saying that if you set them hidden there first rather than depend on my code, they will never actually load their own code? I'll give it a shot, but in my experience the Designer setting is irrelevant because once the code hides them, they're hidden in future anyway (exactly the same as if hidden by the Designer). But if hiding them does stop any running of their code, it's not as bad as I thought (so home page running like a lame dog for some other reason - it always shows the 2013 "working on it" twice too!). Will test with debug trace on monday! Mar 22, 2013 at 19:24
  • As suspected, it's awkward in this case because no matter if you hide first using Designer (not that you can very easily in SP2013 now) or Code, it has to be reset every user, so the code still runs. Best solution (apart from Audiences and possibly SPSecurityTrimmedControl which is also a little awkward) is as per Ali below to bypass the CreateChildControls in SP2010 or InitializeControl in SP2013. +1 for your suggestions and conf of behaviour Daniel. Mar 25, 2013 at 14:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.