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.

SPServices and Github – This Time I Mean It

SPServicesGitHub_LogoI’ve had some false starts moving SPServices to Git and/or Github over the last few years. If it weren’t for Josh McCarty’s (@joshmcrty) help on every release, I wouldn’t even have gotten SPServices onto cdnjs, since they use Github. (Yes, SPServices is available via CDN at cdnjs and has been for several years now.) I’m just tremendously behind the times.

So it’s only taken me about two years, but I’m really biting the bullet on Github this time. I’ve just read through a bunch of great suggestions I got when I abortively tried to move things to Github long ago and I’m curious given the amount of time that has passed those folks might do differently.

Here are my assumptions/preferences:

  • Simple, simple, simple
  • I’m using a public folder in my Dropbox as my “CDN” for development. I think Paul Tavares (@paul_tavares) knows where it is, but no one else does. This Dropbox-based CDN helps immensely for testing, since I can just point my script references there in all of my test environments. In case anyone is wondering, I’d love to use OneDrive (either flavor) for this, but it just doesn’t work the way it does redirects. I can get a clean URL from Dropbox that just plain works.
  • I’m leaning toward WebStorm for my IDE these days. (Where I can’t install it in client environments, I’ll still use SharePoint Designer and/or Sublime Text.) Webstorm has very robust integration with Github that even seems to make sense to me. I’ve got my Webstorm project embedded in the Dropbox CDN I mentioned above.
  • In case you’re wondering, I do probably 99% of the work on SPServices, so my ideas for version control have been extremely simple to date. SPServices is a one-file project and I make virtually all the changes to it. SPServices wouldn’t be what it is without excellent help and contributions from people like Josh McCarty and Paul Tavares; I couldn’t have gotten to this point without them. But as far as the actual edits and testing, it’s mostly me.
  • I’ll continue hosting the docs and downloads on Codeplex, at least for the foreseeable future. This makes sense because of the volume of documentation and the great discussions history that’s already there.

What I’m looking for is best (better) practices, build ideas, etc. SPServices will continue to live as long as people find it useful, and I want to keep building it and supporting it. That said, it’s my “side project” – something I do for fun and learning opportunities. So any ideas should be labor *saving*, not labor *producing*.

It’s my hope that – as they mentioned in the suggestions I linked to above – more people may decide to contribute with the move to Github. Who knows, maybe we can haul it into RESTland along with SharePoint 2013.

Today I posted the latest beta for the 2014.02 release. I expect to make it a stable release in about a week or so, since quite a few people have been downloading it and testing it as I’ve made changes over the last few months. I’ll write more about why you *really* should upgrade to this new version in an upcoming post. (Thanks yet again to Paul Tavares on this one.)

Thanks in advance for any ideas you can toss into the mix. Feel free to reply in the comments here or on the older thread in the Codeplex Discussions.


SharePoint Forms and Workflow – A Different Perspective

advanced-formWhenever I get into conversations about forms in SharePoint (or anywhere else for that matter), the conversation almost always turns immediately for workflow. It seems to greatly surprise a lot of people when I say that sometimes workflow is irrelevant for forms. I’d say that 80%+ of SharePoint forms have no workflow at all. (I think it’s a higher percentage, but I know many of you live and die by workflow.)

I think forms and workflow are too often intertwined as concepts, making the forms discussion overly complex.

IMO, forms are for collecting or editing data. Workflows are for managing that data. By keeping those two concepts discrete, we can have excellent forms that just do what forms should do.

Conflating the two will probably delay the possibility of a robust new form tool for SharePoint. We know that something is coming to replace InfoPath, but we don’t know what it is yet.

We learned early in 2014 that InfoPath is dead. In actuality, it’s not dead; it’s only entered its twilight years. We have until 2023 before it isn’t “supported” anymore, and it will probably be useful for many people even after that. (I won’t make any snarky comments about “supported” software.)

I made up the 80% number above based on my own experience. It really depends on type of SharePoint installation you’re working in. My work is more toward the KM and Intranet side of things, and it’s very rare that I end up implementing a workflow. Knowledge workers can be trusted to do their work in the right way to create value, and it’s rarely a sequential or predictable thing. The few cases where workflows matter – time sheet submission, time off requests, article posting, etc. – the workflows tend to be very simple.

For similar reasons, I haven’t seen much need for InfoPath. With a little JavaScript and CSS, I can usually layer a veneer over the default list forms to give them any boost they need to meet business needs. Even so, the default list forms are fine probably 90%+ (another number I’m making up) of the time.

So much of this depends on the culture of the organization, too. If it’s an open and trusting culture, workflows come up infrequently. If it’s more of a command and control culture, they want workflows for everything. That is until you ask them to describe the repeatable process and they realize that there really isn’t one. Either they have to define a real process (lots of hard work) or they keep doing things the way they have – in a slightly disorganized way that still works.

My point is that assuming that there’s always a coupling of forms and workflow means that everything gets more complicated fast. I like the fact that forms and workflow are separate but connectable in SharePoint now. It means I can plug in a workflow if and when I need it; the forms engine isn’t too cluttered by the workflow artifacts.

What is your experience on this? Are forms and workflow always intertwined or are they really two separate ideas? I’ve created a little poll below to capture your feelings on this. Add your voice into the mix and I will try not to use the statistics inappropriately, as do may others.

Hidden Content Type Hub on Office365 Tenants

This is a simple thing, but because at the moment it’s sort of invisible, you may need a little help understanding it.

The Content Type Hub is a nice capability that lets you create your Site Columns and Content Types in one centralized Site Collection for syndication across your farm. It’s an excellent idea to use it so that your Content Types have consistent definitions and set up across those Site Collections.

In an on premises farm, you’d create a Site Collection to play this role and activate the Content Type Syndication Hub Site Collection Feature.


However, if you try to do this on Office365 in SharePoint Online, you may get an ugly error. Even if you don’t get an error, you may be creating a redundant Content Type Hub.

This is because there is a Content Type Hub Site Collection already provisioned (in the tenants I can see) at /sites/contentTypeHub. You should probably use this Site Collection for your Content Type Hub if it is there.

Unfortunately, this Site Collection isn’t visible in the admin dashboard listing of Site Collections.


To determine if you have this Site Collection, you can go to the /sites/contentTypeHub URL. However, a more conclusive test is to go into Site Settings on one of your existing Site Collections (probably the root one) and click on Content Type Publishing.


On that page, you’ll see a link to the Site Collection that is acting as the Content Type Hub, if there is one:


Upcoming Bonzai Intranets Webinar – Wednesday November 26th at 10am PST

DynamicOwlLogoMy good friends at Dynamic Owl in Vancouver have been doing some amazing things of late. Not only are they some of the smartest people in SharePoint consulting, they have a relatively new product offering called Bonzai Intranet.

Based on their years of consulting, the folks at Dynamic Owl realized that they had been building similar capabilities for their client’s Intranets over and over again. By capturing those patterns and repeatable components, they have come up with a tool set in Bonzai that can get anyone up and running with an Intranet on top of SharePoint faster and more effectively.

But that’s not the half of it. I’ve been looking into their offering; from the surface at first, and then more deeply as they take me through the architecture. This is a gorgeous Intranet offering. By gorgeous, I mean is simply looks fantastic. Of course, that could all be lipstick on a pig, but it isn’t. As I’ve seen how they have built things, I’m truly impressed. It’s the right mix of server side code and client side code, with a slant toward the latter, as it should be in this cloudy world of ours. It’s extensible, robust, and reliable, too.

There’s a post on Michal Pisarek’s blog about the webinar, and I’ve stolen some of that content below. If you’re considering using SharePoint to run your Intranet and see it as a daunting set of tasks, you owe it to yourself to check out Bonzai and the webinar on Nov. 26th.


As part of the recent launch of Bonzai Intranet for SharePoint we have been receiving many questions about Bonzai such as:

  • What is the difference between Bonzai and a template/skin?
  • How the hell did you make Bonzai not look like SharePoint?
  • What is the 80% of common Intranet functionality that most organization have? How does Bonzai handle these?

In order to provide you with the answers to these questions and to show you a sneak peek at some of the great features of Bonzai we are hosting a webinar on Wednesday November 26th at 10am PST titled “Rethinking SharePoint Intranets with Bonzai”  In this webinar we will go through our thinking behind Bonzai and take a look at some of the features that we think makes Bonzai an amazing Intranet platform.