Summer is over, slacking time is over, it's time to get up to speed and learn some new stuff. There's very much to talk about this fall if you're interested in SharePoint. And this fall I will do a couple of conferences as a speaker, which I very much looking forward to.
TechDays 2016, Amsterdam
For the first time I will attend and present at the TechDays 2016 in Amsterdam, the 4th and 5th of October. A local conference hosted by Microsoft. I will present three sessions:
- Introducing the SharePoint Framework
- Deep dive building client-side Web Parts using SharePoint Framework
- SharePoint Futures - Christmas came early this year!
The SharePoint and Office 365 track will be outstanding with where you also can listen to Waldek Mastykarz and Albert-Jan Schot.
SharePoint and Exchange Forum, now SEF Unity Connect
I don't know for how many years I've done this show, SEForum, 26th to 28th of October. It's the best conference for SharePoint, Office 365 and Exchange in Sweden, the Nordics, Scandinavia. And you'll find all the experts here, such as Spencer Harbar, Eric Schupps, Jesper Ståhle just to mention a few. This year I'm honored to do the keynote, together with Dan Holme (Microsoft). It will be a blast! And I will also do the following break-outs:
- Building Modern Solutions with the SharePoint Framework
- SharePoint as an Intranet
If you're planning to attend, please use this code SEFWICW10 to get 10% off!
If you're around, come by and say hi, looking forward to meeting you all out there on the road.
Today is the day many of us have been waiting for since the big SharePoint event at May the 4th. The highly anticipated SharePoint Framework (SPFx) is here and announced in at the SharePointFest, in this blog post, as well as in the new Github repo for SharePoint. Personally I've been waiting for this even longer after being involved by the product team to give early feedback and also attending the first top secret DevKitchen "hackathons" where we could try out very early bits.
The first release of many to come…
This is the initial public preview release, officially christened the SharePoint Framework Developer Preview, is a beta, maybe an alpha, of the SharePoint Framework. This is by no means something you should use or deploy to production. Things will change! Period. There are several known issues at the moment and some of them will likely incur breaking changes. But please, build stuff and give feedback to the product team, use the Issues feature in the Github repo.
This initial release focuses on client-side Web Parts which can, once released, be used in you classic SharePoint sites and pages as well as in the new modern user experience that is slowly being rolled out throughout the suite. As some of you know, I've spent quite some time on Web Parts and written a book on the topic, so this is something that gets me really excited.
How and where to get it!
All you need to do to get your hands on it is to follow the instructions on the Github repo. I'm sure we'll see tens and hundreds of blog posts on how to do it, but I recommend you to follow the one in the repo to start with. And, if you can't follow it, create an issue, make a pull request with an update - make sure we get good official documentation! Heck, I'm pretty sure I will write a couple of posts on the topic, but I will also continue to provide feedback on the framework and the documentation.
You will find samples, documentation and all you need in a set of brand new repositories in Github, also under a brand user/organization called…SharePoint (yes, no more generic Office dev, SharePoint is back!).
- SharePoint organization at Github, the main source for all your SharePoint Framework details - https://github.com/SharePoint
- SharePoint Framework documentation
- SharePoint Framework API documentation
- Office UI Fabric - the React edition
Need to know more?
Keep the conversation going on Twitter, SharePoint Stack Overflow, the new Office 365 Community network and other social media, and do use the #SPFx hashtag. I'll try to hang around at the SharePoint Stack Overflow as much as possible, since that is the best platform of the above mentioned ones.
I've previously written a Q&A on SharePoint Framework and will continue to update that post with details and changes in the current preview release.
Now, go, build something awesome!
Here's one of these real life stories that caused some headache for quite some time but was in the end very easy to resolve. I'll write it down and hopefully some of the search engines pick it up and help some other poor soul out there.
We have a solution that uses publishing pages to manage news articles and information pages in SharePoint Online. These articles and pages have a custom page layout with a custom content type, so they look decent and have proper metadata. They are all deployed using the PnP PowerShell cmdlets.
Creation of pages worked flawless and the rendered nicely. They page layouts use jQuery, some Office Fabric components (including those nasty jQuery scripts for that).
So far so good!
We wanted to roll up this News articles through a custom Web Part based on a search criteria, and also show some of that metadata, such as News category, rollup image and more. But the pages was not indexed. First thought was that well, indexing in SharePoint Online usually takes everything from a couple of minutes to a couple of days, so just wait. Then summer vacation came - I'm not complaining - and when i got back we had index. Ok, good. But then I started adding some custom managed properties to the rollup feature and was waiting for it to pick up the changes. I clicked re-index the libraries, I clicked re-index the site, added new pages and articles, I might even sacrificed the cutest little kitten you can imagine - but nothing. The pages and articles was just not picked up by the crawler. So I started to smell something fishy.
Is there something wrong with my SPO tenant? No, same issue across multiple tenants!
Can it be the page layout? No, it renders perfectly in all browsers!
Can it be the PnP PowerShell cmdlets? No, the same issue if I uploaded page layouts manually!
First of all I added the CrawlTime managed property to see when stuff was actually crawled and that there was nothing wrong with the crawler. I could see how this managed property was populated on other stuff than the pages. So there is obviously something wrong with our pages and not SPO.
Time to get my troubleshooting gloves on and I brought out my checklist for this. Since I can't check trace logs (ULS) in SharePoint Online all I could do was to inspect the crawl logs. And now I could see in plan text that my news articles could not be crawled:
"6074070", "https://contoso.sharepoint.com/news/Pages/xyz.aspx", 755", "Item Error", "The SharePoint item being crawled returned an error when attempting to download the item. ( SearchID = F2A4A5E4-AAAA-AAAA-B034-10C593EF6CCE )", "8/4/2016 7:07 AM", "https://contoso.sharepoint.com/", "Intranet",
So, the crawler can obviously not download my page! I also noticed the following cryptic error message on the site and library levels:
"755", "Container Error", "The SharePoint item being crawled returned an error when attempting to download the item. ( Unknown Error The surrogate pair (0xD8DA, 0x272) is invalid. A high surrogate character (0xD800 - 0xDBFF) must always be paired with a low surrogate character (0xDC00 - 0xDFFF).; SearchID = 00D32C87-7CD9-4350-AFF4-BBF38B8EB712 )",
Hmm, some Unicode errors?
I was out of options and I could not do an IISRESET (Rule #3) - so I called a friend (Rule #4), Doc Hodgkinson. He was almost as clueless as I but asked my to test it on a normal SharePoint 2016 on-premises installation (born in the cloud you know) and see if I could replicate the issue and also then have the option to check for more detailed crawl and trace logs.
And so I did. I ran the installer on a clean SharePoint 2016 install, started creating a page using our custom page layout and BOOM! The browser just went white!!! Nothing! It rendered fine in SharePoint Online (cloud-born innovation!)
Quickly I opened up the trace logs and reloaded the page and found this in the logs:
SharePoint Foundation General ahi1s Medium Cannot find requested file: 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\Template\layouts/https://code.jquery.com/jquery-2.1.4.min.js' SharePoint Foundation Upgrade aq775 Unexpected CannotMakeBrowserCacheSafeLayoutsUrl ArgumentException: 15/0/1033/https://code.jquery.com/jquery-2.1.4.min.js
Aha! The Page Layout contains a ScriptLink control that points to that CDN location.
I quickly changed it to a normal script tag and the page rendered fine in the SharePoint 2016 on-premises instance, and I uploaded it to SharePoint Online where it also rendered fine. And…after just a few minutes all my articles was indexed and queryable and I had my Managed Properties. And all was good!
I find this bug very interesting, SharePoint Online obviously accepts full URLs in the ScriptLink property when rendered through a browser but when the crawler sees it something weird happens (also, I wonder why it gets Unicode errors on the site and library as well). Also, the code for ScriptLink is different for SharePoint Online and SharePoint On-Premises (I have NOT tested all CU's though). Also, it's really weird that it some time during the summer actually indexed the pages.
All in all, actually using an on-premises installation for troubleshooting my SharePoint Online issues was a great idea (big thanks as always Neil) and I'll keep that option as a part of my normal routine from now on.
I have long thought that GUIDS are unique, well GUID actually stands for Globally Unique Identifier. And SharePoint is one unique product using GUIDS everywhere. There are 2^128 possible GUIDs to choose from, so there should be no need to reuse GUIDs as long as I'm alive methinks.
SharePoint uses GUIDs to uniquely identify Site Collections and Sites, and more, and this is for instance exposed through the ID property of the SPSite and SPWeb objects. If you take a look at the documentation for SPWeb.ID it actually says: "The globally unique identifier for the website" - which I interpret as this ID is unique, globally! Period.
When you create a Site Collection in SharePoint you create a new Site Collection (SPSite) and a Root Web (SPWeb). The SPSite will be given a unique identifier, a GUID, and so is the root web as well. Due to the way the API is created you cannot find a web directly using the unique Web Id, you actually need the Site Id. Even so there are multiple applications and services that has only stored the unique Web Id and used that as something unique.
Given (recent) changes and a new feature called Fast Site Collection Creation, used in SharePoint Online and to some extent in SharePoint 2016, this is no longer true and you can no longer trust in the Web Id being unique. When a site collection is created with a root web, specifically the SharePoint Team Site (STS#0), it is copied from a site master. The Site Collection is given a new GUID, but the GUID for the root web is copied from the site master. So, in SharePoint Online all your Site Collections with a root site of type Team Site will have the same id.
There is no workaround for this, you cannot change the Id - your only chance is to use a combination of Site Collection Id and the Web Id. That is a dual GUID combo - can't be more unique than that.
Some of you perhaps already knew this, some not. Hopefully you'll be aware of it now and I wish this would be different and that the Fast Site Collection Creation actually updated the Site identifier property, and since I most likely cannot have that I wish the documentation would be updated with a hint on this.
This is by no means an official support statement from Microsoft, rather an unofficial compilation of official statements.
Last week the SharePoint Online team rolled out the preview of the Modern SharePoint lists. Modern Lists are the new incarnation of ye ole Classic SharePoint lists that we all loved and hated over the last decade or so. The Classic SharePoint lists and libraries has been one amazing and powerful tool and I would say that they have been a big part of the success SharePoint has had. Customizations using XSLT, SharePoint Designer and JSLink has all contributed to its success.
The new Modern Lists (currently in preview, not even in First Release and you need special voodoo tricks to get it to work) does not support these kind of customizations, for now. Over the last week or so I've heard large cries and worried Tweets about all peoples current customizations. Microsoft has not been overly clear on the supportability for classic lists in public writing but rest assured; Classic lists will be here as long as they are used and needed. This is what I've been told by the team and what they are trying to say;
- "We have no plans to remove classic mode anytime soon"
- "We heard your feedback on extensibility and customization in particular, and we’ll have more to share in a future update. We plan to add support for customizing the page using modern techniques. Until then, customized library pages should stay in classic mode."
- "Classic mode supports your customizations today, and tomorrow."
- "In the meantime, it’s important for us to maintain continuity for our existing customers. "
Also I do think it is good that they don't set a date for supportability, which some people request, like they've done with for instance InfoPath. If they do that, they have to support Classic Lists until that date. I think it is better they make great progress in making us move to Modern Lists as soon as possible, and when they see no or minimal usage of Classic Lists, they can remove it. The same as they've done for Sandboxed Solutions - something we known coming for years! [Update] But yes, I do think a notification a little bit more than 30 days prior to shutting it down makes sense, if and when the feature gap is closed.
So, keep calm and continue to use your classic lists - however start planning for a modernization of your XSLT List View Web Parts, your JSLink customizations and more. I know that what's coming to replace these, will be much more interesting and be way more modern.
As many of you have noticed I have not been posting my What's new on the Office Roadmap updates. Well, I've been on a vacation not trying to think of Office 365 to start with, and then also, I'm ending my series of these posts. Sorry.
I have to start with saying that I love the amount of changes we see now in the Office 365 service. The team(s) is/are doing an amazing job with kicking out new features and updates in some areas. Our favorite SharePoint is killing it with features at the moment, and more is to come. And do believe this will continue for the foreseeable future.
Why? Why, do you do this? There's plenty of reasons for me ending this series. It's been going on now since March last year (which is way longer than I expected) and it was exactly 50 posts! So plenty of updates has been going on.
First of all it still takes me humongous amounts of time compiling each post, figuring out what's changed, what each change actually means, filtering out false changes, going back to my old change posts, coping with errors in the changes etc etc.
But most importantly the reason I stop doing this is that the Roadmap does not really reflect the changes going on (yea I know, Roadmap and changes are not the same). Using the Roadmap as a guide on what's to come is not that accurate that I hoped, sorry. And the #1 reason that I started this series was to get the Office 365 team to understand that we need a Roadmap where one can see changes, one that you understand the changes and one that you can trust, otherwise there's no point! There's no point giving you examples, there's to many. After a year and half very little has happened…
I'm going to miss it though. I've had some fantastic online and offline support of these posts and I enjoyed adding some personal touch to my "analysis". Some liked it, and some despised it to the extent that I'm actually persona non grata in some "communities". I'm probably to close to the truth and far to many people have hard to understand irony…
Nevertheless…if you still want to find out what's happening on the Office Roadmap site, the PowerShell script I had scheduled is available as a Gist on Github.
Thanks for all the support!