Find That Missing Web Part

Have you ever “lost” a Web Part on a SharePoint page? That happened to me (again) today. I tried and tried to figure out why I wasn’t seeing the contents of the Web Part. I knew it had some, and I knew what it should look like.

Where's my content?I’ve been bitten by this before, so I figured I’d write a note here to my future self in the hopes that I’m smart enough to search for “missing Web Part” and find this post. Of course, this bites me infrequently, so I never remember that it happened to me before. It’s gotten me in every version of SharePoint, too, I’ll bet.

It turns out that I had accidentally clicked on the Minimize option in the Web Part settings dropdown:

Minimize Web Part

You can set this back from the same dropdown menu, where Minimize will have been replace with Restore. You can also fix it in the Web Part Tool Pane.

Chrome State

It can actually be worse, though. There’s another place that you can do yourself in that’s even harder to spot. (I hit myself with this as a double whammy today.)

Right below the Chrome State above is the Chrome Type. The options there are generally “Default”, “None”, “Title and Border”, “Title Only”, and “Border Only”. If, like I did today, you accidentally select the “None” option, then your Web Part disappears altogether! With the branding I have on the site I’m working with today, the Web Part simply collapsed to a blue line.

Where's my Web Part?

At least I could tell it was there, but since it was a Content Search Web Part and I was working on the Display Templates, I assumed it was my code that was breaking it.

Live and learn, I guess. And always try to write future you a note so that you can fix it more easily the next time.

“Codeless” SharePoint Enhancements

I’ve always been a lazy programmer and if you can believe it, I see this as a good thing.  I never want to write anything more than once.  (I’ve written an assembler-based keyboard handler for DOS.  Do I need to do it again?  As much fun as it was: no.)  I also believe that the simplest way to solve a problem can often be the most elegant one.

With SharePoint, there are basically three “tiers” where you can do development: in the UI, in SharePoint Designer, and in Visual Studio.  To me, you should think of the tiers in that order of preference, which goes from simplest to more complex.  I ran across several posts today that I think back me up.

Thanks to David Whittle in Japan for the pointer to the Path to SharePoint blog.  In it, Christophe shows us how to do some pretty amazing things by generating HTML in calculated columns, among other things. I might turn to SharePoint Designer for some of the things that he pulls off, but his approaches work just fine, depending on your environment.  For instance, your governance rules may preclude you from using some of his techniques (You do have a well-documented governance model, right?), but that doesn’t make them bad approaches, just not the right approaches for you.

Christophe had a pointer to Joel Oleson’s blog where Joel talks about Webpart and Widget No Assembly Required Simplicity.  Joel’s premise is that you can do a heck of a lot by using script-based widgets in SharePoint without actually writing *any* code.  (Sure, you may need to configure a widget’s script through someone’s Web page UI and drop it into a CEWP, but that doesn’t count as writing code in my book.)

All in all some more strong arguments against needing a top notch .NET programmer to do very cool and useful things on top of the SharePoint platform.  In these days of mashups and instant apps, don’t rule out these same approaches from being highly useful in a serious business application, either.