Yes, you can find this almost everywhere (even within sites that talk about food or cars :-)), but anyway, I’m writingt here just for reference.
Here’s some line of PowerShell code that set how the Developer Dashboard is displayed:
Add-PSSnapin microsoft.sharepoint.powershell -ErrorAction SilentlyContinue
$DevDashboardSettings = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.DeveloperDashboardSettings;
$DevDashboardSettings.DisplayLevel = ‘***’;
As a final note, remember that:
- These settings are farm-wide
- Having the Developer Dashboard “on demand” causes, at least in OOTB master pages, a small control to appear on the right upper corner of your pages. Which is fine (how would you launch the dashboard without some visual aid?) but sometimes can be painful: if you do not take care about this control beinig possibly there, you may end-up with a broken layout (imagine you have developed some custom master pages in an environment where the dashboard wasa off, then move everything into another environent where it is on-demand, and suddenly portions of your markup overflow… believe me, this may happen!!)
Just a couple of lines of code, so no need to explain too much here!
$w = Get-SPweb http://yoursharepointsite
$u = $w.EnsureUser(“yourusername”)
$u.IsSiteAdmin = $true
A very complete explanation can be found here, with a lot of details and step-by-step instructions about the core SharePoint configuration, as well as about external applications integration (SQL-AS, etc) and special considerations for SharePoint Service applications.
Incredibly useful for studying and for troubleshooting!
You probably know that one of the cool new features of the Content Query Web Part in SharePoint Server 2010 is the support to QueryString and PageField filters.
This was achievable also in MOSS 2007, but you had to rely on Parameter Bindings applied to the CQWP control, which made it a little more complicated since it requires some more knowledge about the “DataView family”.
Just a small note, though: if you keep using the QueryOverride mechanism (i.e., you specify a custom CAML query overwriting the default CQWP behavior), you completely lose the new filters functionality.
More generally, any time you apply some override (Query, View, etc…) the CQWP skips its automatic CAML query/filter/projection generation, and all of the plumbing it’s up to you.
With great power comes a great reponsibility!!
Well, this is a tipical situation when you may say “it’s easy”.
And it is, indeed, but you have to be aware of a couple of “small” issues.
First of all, you know that the SPListItemCollection class exposes a count property, you invoke it and voila, you get the total numebr of items contained within a SharePoint list.
But… be careful, because you are fetching *all* items, possibly causing a hige load on the server (SharePoint and SQL Server).
A better approach would be using the ItemCount property of the SPList class.
Which is what I would suggest, with a little gotcha: ItemCount returns exactlt what the name suggests, i.e. the count of all list items, and doing so it *does not* apply any sort of security trimming. In other words, if the code is run within the context of a user who has the rights to view only 5 out of a total of 10 list items, this property returns 10.
Pay a lot attention when you are looping or indexing an SPListItemCollection this way!