This project is read-only.

WebPart to view site directory?

Apr 22, 2010 at 9:23 PM


I've installed the Site Directory and it seems to be working fine. But I now have the site listing on /sites/SiteDirectory/Sitelistings. How can I get that list to show on my root site? Perhaps you could also think about creating a (Silverlight?) webpart which allows searching through a great number of sites. I'm in a project which will involve hundreds of subsites being created and I need a good way of navigating them. I'm going to add some custom metadata to the sites, although I'm not yet sure what the best way would be of doing that. That metadata would be a great help in searching for the right site too.

Apr 23, 2010 at 10:36 AM

Hi - as it stands there is no way to do this other than search (perhaps a special search scope?). You could use the out of the box Content Query webpart if both sites were in the same site collection but it does not sound like they are. The next release will hopefully allow you to create your site directory as a sub-site of a site collection rather than mandating a root site, which would enable this scenario.

We do already have a 'site listing data' webpart as top of the list for the next batch of improvements. This would be a webpart that you could put on any site and it would show the metadata for the site where it is located (from the associated site listing item). This would be dynamic and include any additional fields that you added to the 'site listings' list.

If you are going to add additional fields to the site listings list, it is like you would with any other list. I'd also recomend using the Managed Metadata Service that is new in 2010.

Great feedback, thanks

Martin Kearn

Apr 23, 2010 at 10:54 AM

Hi Martin,

thanks for you quick response. The improvements sounds great, do you also have a timetable or estimate on when we can expect a new version?

I'm already using the managed metadata service, it's great. Suppose I would add such a column to the SiteListings, how would I get that populated when a site is dynamically generated?

Apr 23, 2010 at 11:26 AM


Unfortunatley, this is a 'spare time' project and we have to work on it when we have breaks in our main work for customsers. As such we cannot define any release schedule or anything like that. Despite this, I hope to get chance to take a look at this at some point over the next few weeks.

Populating the values for non-default metadata fields is something we've been thinking about a lot as it is not really possible to automate this as part of the scan job since we do not know what type of data we are getting and where it is coming from. In the current version (1.2) the only option is to manually maintain these fields directly through the site listing list. However we are considering several options, including:

  • Using this site listing data webpart and providing a link to eth edit from for teh site listing
  • A 'pester block' of some sort which pops up if teh site listing is incomplete (a slightly differnet take on the site listing data webpart)
  • Incorprating a site creation aspect so that the addition of a site listing (including non-default metadata) actually creates the site for you.

Any suggestions are welcome

Martin Kearn

Apr 23, 2010 at 2:21 PM

Hi Martin,

a few weeks seems promising enough for me to wait a bit :) In the meantime I think I'm gonna look into the Silverlight webpart and if it turns out to be something usefull, I'll share the code. With the new REST services it should be pretty easy getting the data into there.

As for the metadata, I've been struggling with that myself. Roughly there are two approaches; setting (lots of) custom strings into the property bag. Pretty ugly if you ask me, but it works. I've now changes my approach and I'm saving a class serialized as XML into one of the propertybag entries. It's easier to check since you only have to inspect if the property exists and then cast it to your custom class defintion. Once casted, everythings typed again which is nice of course. Perhaps you could use a similar method. The property bag of a site is the only place to store custom metadata, so you'd need some sort of mapping to sitelisting columns. Perhaps you could check the collection for entries which start with 'sitecollection_' followed by the column name. If a column with that name (or perhaps ID?) exists; insert the value and otherwise: too bad.

Apr 23, 2010 at 2:26 PM
Edited Apr 23, 2010 at 2:27 PM

This is an interesting approach and we did consider that, but we were really keen to leave the sites and site creation process exactly as it is out of the box in order to keep the footprint of the solution small. Also we are keen for administrators to be able to add fields without having to re-code.

Our approach will be to store the non-default fields in the site listings list only (as columns in the content type) and provide a range of UI options (site data webpart, pester block, site settings page etc) to help surface and 'fill out' those properties.

The first of these UI options (the site listing data webpart) is the top of the list.

Apr 23, 2010 at 2:31 PM

Ok. I'll manage with filling in the extra properties in code, no prob. The only think I'm worried about is possible changes in the sites metadata. At the moment I'm not quite sure wether I would store that data in a) the sitelisting b) the sites property bag or c) both. All of them have up and downsides, so both would probably be the best bet. But storing data in multiple locations seems... hmm... ugly. Also, I need the metadata in the sites, so that would make more sence. I don't want all of my users to be able to see all sites (especially not the ones they don't even have access to) so permissions would also be an issue. But for navigation, it's far quicker to store a sitelisting as opposed to querying the actual sites each time the navigation webpart is loaded...

Apr 23, 2010 at 2:36 PM

For us, it absolutely has to be the listing because we want administrators to easily add/remove fields and set their values, we also want to make use of the managed metadata service.

If the data is in the listing, it also makes the data searchable.

Funny you should mention permissions.... Site > Site Listing permission mapping is also on our radar. We are looking to replicate the site's read and edit ACLs onto the site listing.

Apr 23, 2010 at 2:38 PM

Great! I think I'll use the SiteListings purely for navigation. The other metadata which I don't need for navigation won't get in there but will stay in the site property bag where I can reach it more easily.

I'm looking forward for new releases, thanks for now!