Here’s what i started with–you can tell that the site actions menu (with its Out-Of-The-Box style) wasn’t going to work for me:

I wanted something simpler that matches the “welcome” screen! So for starters, i removed the background from the container div:

.ms-siteactionsmenu div div div{      background:transparent !important; }

Notice the “!important”.  This is so that I can override the inline styles on the control (get ready for a few more of them).  Next I remove the border from this same div:

.ms-siteactionsmenu div div div{                 background:transparent !important;      border:1px solid transparent !important; }

So–Getting Better!

Note that I leave the 1 pixel ‘transparent’ border so that when I show a border on hover I don’t get a funky “resize” behavior.  So, on that note–let’s add the “hover” behavior:

.ms-siteactionsmenu div div div.ms-siteactionsmenuhover{

     background: green !important;

     border:1px solid white !important;

}

On hover now looks like this:

Simple and clean! To finish it off, I similarly set the Welcome to the same hover style:

.ms-siteactionsmenu div div div.ms-siteactionsmenuhover, .ms-SpLinkButtonActive{

     background: green !important;

     border:1px solid white !important;

}

Snap-In Loader

Add this little bit to load all the Snap-ins you regularly use.  It will only try to install one’s that are installed, so if you have different sets available on each machine there won’t be any error messages.

$snapins = “PowerGadgets”,”PowerPad”, “ZachsCmdlets”

$snapins | ForEach-Object {  if ( Get-PSSnapin -Registered $_ -ErrorAction SilentlyContinue ) {  Add-PSSnapin $_  -ErrorAction SilentlyContinue }  }

BootStrap Folder

I wanted to have a folder that I could organize all my “Random Functions” into that would still get loaded into the PowerShell session (the Profile document gets too large to manage otherwise!). 

The File location:

$myscripts = “C:/somelocation/scripts/bootstrap/”

ls $myscripts |% { &”$myscripts /$_” }

*Important NOTE:  Inside the bootstrap files, any function or variable you want available in the session needs to be declared using the “global” moniker:

E.g.:  $global:myvar

E.g.:  global:myFunction(){ return “foo” }

Recursive Lookup

Want to filter files recursively?  Use this FF function (it’s sort of my own shout-out to my previous favorite bash):

function global:ff ([string] $glob) { get-childitem -recurse -include $glob }

Also, I recommend pairing this with the Sysinternals tool ZoomIt to allow for zooming and underlining elements on the screen.  This is a free tool available from the Sysinternals website: http://technet.microsoft.com/en-us/sysinternals/default.aspx

• SPWeb: These are referred to in SharePoint UI as a “Site”. SPWeb’s are a collection of user data (lists, library, docs, pages, etc.) in a database. An SPWeb belongs to one, and only one, SPSite.
• SPSite: These are referred to in SharePoint UI as a “Site Collection”. SPSites are a grouping of SPWebs that all share the same root URL. The SPWeb that lives at the root url of an SPSite is called the “Root Web”. SPSites have settings, but do not contain user data.

SPSites have one very important feature—all SPWebs in an SPSite must be stored in the same Content Database. This is key to how we figure out what database user data is stored in.

Now, on to managed paths! When user types in a URL into their browser—the root domain is directed through DNS to a SharePoint Server (this is the easy part!). Once SharePoint gets a URL, how does it now what data to look up?! Let’s take the following url: http://www.foo.com/sites/foo/bar/foobar. The first thing to note is that we know that the user’s data (provided he typed a valid URL in) is in an SPWeb somewhere… But where? First we need to figure out the ‘containing’ SPSite so we know what database to look at—but which part of the URL gives us the address of the SPSite? /sites? /? /sites/foo/bar? This is where Managed Paths play their role.

SPSites are limited to being created only where a managed path is defined! For example, “(root)” is one of the default managed paths you see when creating a new web application in SharePoint (visit Central Administration -> Application Management -> Define Managed Paths). This means you can create one site collection at the root of the web app—in our example, this means you can have a site collection at http://foo.com. This is an explicit managed path as it means you can create only one site collection at the exact location specified.

Another default managed path you see is “sites”—which is a wildcard managed path. This allows for unlimited number of site collections to be created directly under the provided path (it is important to note that a site collection, and thus an SPWeb, cannot be created at this explicit url). This means I can create site collection (and only SPSites, not SPWebs) directly under this url (http://foo/sites/foo). This means that any additional path in the given URL is an spweb (created from the root web of this spsite). So in our example, we can split the incoming URL into four pieces to quickly look up the information:

“http://ww.foo.com” + “/Sites” + “/Foo” + “/bar/foobar” (Web Application) + (managed path) + (SPSite) + (Web/SubWeb)

Whenever a URL is ‘received’ by SharePoint, the site collection is determined by looking at the list of managed paths for a given Web Application. This means SharePoint has to look at every managed path so try to limit the number of managed paths (<20 is highly recommended). SharePoint always matches the longest pattern possible—we’ll look at a more complicated example to explain the reason. Using the following managed paths:

• 10 (explicit)
• 10/teams (wildcard)
• 10/howto (explicit)
• 10/howto/misc (wildcard)

How do we map out URLs? Site Collections (SPSites) urls are highlighted in Bold:

• http://foo.com/10/teams/sites/bar
• http://foo.com/10/myteam/sites/bar
• http://foo.com/10/howto/team1/foo
• http://foo.com/10/howto/misc/team1/foo/bar
• http://foo.com/10/howto/misc/team2/foo

The key item to note is in the last three example URLs—notice that the longest managed path (10/howto/misc) takes precedence over the shorter (10/howto). Hopefully this clears up Managed Paths! I’ll end by summarizing:

• Managed Paths allow SharePoint to determine what portion of a given URL corresponds to the “site collection URL”.
• Managed Paths can be defined per web application (and cannot be defined for host header site collections)
• Managed Paths can be “Explicit” or “Wildcard”
• Explicit Managed Paths allow a single spsite to be created at exactly the given url
• Wildcard Manage Paths allow unlimited spsites to be created under the given url – no spsite can be created at exactly that URL.
• Limit your managed paths to <20 per web application