Take a look at this article: http://www.windowsitpro.com/article/sharepoint/Watch-Out-for-Unmanaged-Accounts.aspx
Apparently, MS didn’t make every account managed. I just ran into an issue today where the default content access account automatically reset it’s password and it didn’t get updated in the search service. As a result, all crawls started to fail.
Remember having to create features that deploy custom content types in MOSS 2007? How painful it was? How you just really didn’t want to do it?
In SharePoint 2010, it is super easy. Just see here.
Came across a good post here about dealing with dialog boxes when branding a SharePoint 2010 site: http://www.heatherwaterman.com/blog/Lists/Posts/Post.aspx?ID=21.
Adding .ms-dialog in front of some additional styles allowed me to remove my page background image and remove the fixed width in my container div. Good deal.
If you are deploying custom page layouts using a feature, DO NOT OPEN THEM IN SHAREPOINT DESIGNER! Not even once. Not just to “take a look”. Not for giggles.
Why? Because once you open that page layout in SharePoint Designer, it gets un-ghosted. This does two things. First, it means that you have to make changes in SharePoint Designer. The .aspx file in the feature directory is no longer used when rendering pages based on that page layout. Second, if you’ve attached a code-behind to the page, you’ll get a error indicating that type is not registered as safe. This occurs because SharePoint uses a type-safe parser on all un-ghosted content.
If you’ve come accross this post because you already did open the page layout in SPD, have no fear. To remedy your error, simply go to Site Actions…Site Settings…Reset to Site Definition. Once you do that, re-deploy your feature containing the page layout. Now, your page layout is ghosted.
Update: Well, I ran into an issue where “Reset to Site Definition” just didn’t work. So, I tried the stsadm command here (with -force): http://stsadm.blogspot.com/2007/09/re-ghosting-pages.html and now we’re back to un-ghosted. Very frustrating.
This issue has been bugging me for months. On several sites that I’ve branded, I’ve add a DOCTYPE to the masterpage that indicates to the browser to render the pages in standards mode. An unfortunate side effect of this occurs when you try to move webparts on a page: the little bar that pops up that you drag to a new webpart zone is way off. Like 200px off. Fortunately, I found a solution from this website. (which actually deals with a different issue, but it works for this too)
Just put this code in your masterpage or external .js file. Make sure the code or link reference is the last thing in the
tag.function MSOLayout_GetRealOffset(StartingObject, OffsetType, EndParent)
{
var realValue=0;
if (!EndParent) EndParent=document.body;
for (var currentObject=StartingObject; currentObject && currentObject !=EndParent
&& currentObject != document.body; currentObject=currentObject.offsetParent)
{
var offset = eval('currentObject.offset'+OffsetType);
if (offset) realValue+=offset;
}
return realValue;
}
Today, all of the sudden the tab and escape keys stopped working in Virtual PC. Had never happened before. I reinstalled VM Additions, restarted the VM, nothing worked. I then found the solution in a form post:
“If you are running into this issue on Vista and Windows 7 you can get the TAB key back by creating a software allow policy. Go to administrative tools, local security policy, Software Restriction Policies, Additional Rules. Create a new rule for %appdata%\microsoft\vritual pc\vpckeyboard.dll and set it to Unrestricted. Restart Virtual PC. If the variable doesn’t work, try using an explicit path i.e. c:\users\username\appdata\roaming\microsoft\virtualpc\vpckeyboard.dll”
Did that and it started working. Note in the post that this applies to Vista and Windows 7 only. I’m running Windows 7 x64.
In a client project I’m working on, the design calls for dividers in between each navigation link. No problem. Here’s the CSS:
.ms-topnav a
{
border-left-style:solid !important;
border-left-color:#fff !important;
border-left-width:1px !important;
padding: 0 10px 0 10px;
}
However, this leaves the border on the first element of the navigation, which we don’t want. There’s no way to select that element using just CSS, so JQuery to the rescue:
$(document).ready(function(){
$(".ms-topNavContainer").each(function() {
var links = $(this).find("a");
if (links.length > 0) {
var link = links[0];
$(link).addClass("navLast");
}
});
});
The CSS for “navLast”:
a.navLast
{
border-left-style:none !important;
}
The interesting thing here is that it has to be “a.navLast”. For some reason, “.navLast” doesn’t work. Also, you can’t use “border-left” to add the dividers. You have to use the individual styles (most likely because of the inline styles on the element).