SharePointers

For smaller changes to your Editform.aspx you may want to avoid doing a solution deployment that contains a custom content type feature with a custom EditForm.aspx.  This is a quick workaround.  It's pretty much the same as we used to to in MOSS with only minor changes to the way you get to the form. I did this in IE, but it's probably similar in other browsers: Place an html document containing some JavaScript/Jquery into a document library on your list's site.  (Try just putting this for initial testing: <script type="text/javascript">alert('hello world');</script>) Navigate to the list whose editform.aspx you want to change Right click on any item's link to it's display form and choose 'open in new tab' Go to the newly opened tab and click the 'Edit Item' button  to open the item in the editform.aspx append &ToolPageView=2 to the url Add a Content Editor Web Part and point it to your document from step 1...

I've found a lot of bad info on how to do this and it's not well documented so hopefully this helps someone: first create a JavaScript function so that your links aren't super long: <script type="text/javascript">             function OpenForm(absSiteUrl, siteRelFormUrl, siteRelSaveUrl)             {                         var formUrl = absSiteUrl + siteRelFormUrl;                         var saveUrl = absSiteUrl + siteRelSaveUrl;                         var formSvcUrl = absSiteUrl + "_layouts/FormServer.aspx?XsnLocation=" + formUrl;    ...

If you have MySites and a Search Center running in your farm, you may have overlooked a not-so-obvious configuration setting. When setting up MySites for a User Profile service application, your Search Center URL must point to the "Pages" folder where the Search Center publishing pages are located instead of the Search Center web URL. Otherwise, a People Search from a MySite will forward the request to to http://[searchcenter]/PeopleResults.aspx?k=searchquery (which doesn't exist) instead of http://[searchcenter]/PeopleResults.aspx?k=searchquery which is where the PeopleResults.aspx page is actually located. TLDR: Use http://[searchcenter] /Pages/ for your Search Center url in UPA MySite Settings.

I've been struggling lately with the proposed solutions for including the javascript for CommandUIHandler's CommandAction and EnabledScript attributes.  Thus far I have only seen the following examples: JavaScript directly into the attributes (messy), Including a ScriptLink command action (bad because then the script file is included in every page where the feature is activated causing bloated pages) Creating a page component (overcomplicated) Instead of all this, I created a pattern which loads the js file on the fly with javascript and keeps your ribbon development more compact (note I have JQuery loaded in the master page, if you don't have this then you'll have to either load jquery dynamically or reference the elements without JQuery): <commanduihandler    CommandAction="javascript:                              ...

This is a command that will quickly let you know which w3wp.exe you should be debugging on Server 2008 (IIS7, since the App Pool isn't listed in Visual Studio's 'attach to process' dialog). go to \Windows\System32\inetsrv and run "appcmd list wp" and you'll get a list that associates App Pool and PID

If you want to use the SPWeb.Files.Add() method that allows you to pass in a HashTable of metadata for the document, you will need to use the internal name of the metadata field, not the display name.   Here's a PowerShell script to get that for you quickly: $web = Get-SPWeb http://intranet.sharepointdev.com $list = $web.Lists["Shared Documents"] foreach($item in $list.Items) {     $file = $item.File     #output all the SPFile property names     foreach($key in $file.Properties.Keys)     {         write-host("File Key: " + $key)     }         #output the associated item's fields     foreach($field in $item.Fields)     {         write-host("Item Field: " + $field.InternalName)     }     break; }

There are several components/processes that are involved in the execution of sandboxed solutions.    For a developer, it's critical to understand how coding/debugging various types of solutions changes based on the type of solution.  Here's how the execution goes in a nutshell: When the sandboxed code is called, the Execution Manager (running in the w3wp.exe) makes a call to an application server running the User Code Service (SPUCHostService.exe).  The User Code Service then tells the Worker Service  (SPUCWorkerProcess.exe) to load the sandbox code.  The code is then verified to ensure only calls to the subset of the API allowed by the Sandbox API are called.  The worker process then executes the code against the Worker Proxy (SPUCWorkerProcessProxy.exe) which has full access to the SharePoint API (but the sandboxed code has already been disallowed from using the non-subset portion of the API by the Worker Service). When debugging sandboxed solution...