Removing reusable SPD workflows completely

Recently I have been working on a set of different custom SharePoint Designer workflows for different customers. Sometimes the process is not so straightforward that you get things right on the first try and sometimes the errors result in the need to actually remove some trial workflows from the system. 

Reusable workflows are slightly more tricky to remove from the SharePoint UI than the list workflows. In SharePoint Designer, the main way of managing workflows is in the Workflows section. This may well tempt you to remove the workflow simply from that list and be done with it. This, however, will not remove it from the SharePoint UI, and thus an old depracated workflow is still available for users. 

The right place to remove the workflow from is to open the All files section, find the Workflows directory there and delete the whole workflow directory. 

But what if you already deleted the workflow in the Workflows list and now you have no directory for it anymore but it still shows up in the SP UI? This is what I was researching this morning. The place to go in that case is - surprise surprise! - the _catalogs directory. There you will find a folder named wfpub. And in that wfpub folder, you still have the directories for even those workflows that were deleted from the Workflows section listing. Delete these directories with all their contents and you're good.

Broken Blog Post Filtering in SharePoint 2013

Some time last spring I created two blog sites to a customer SharePoint 2013 intranet. I set them up quite similarily, the only difference being that I added some custom fields to the other one. This should, in my logic, not affect anything in the different blog views - such as archives and category views - since I didn't touch any of the OOB fields. Whatever the reason, the end result was however, that last week the customer noticed (hmm, not very active blogging then ;) ) that on the other blog site the category and archive pages were broken. They did not filter the posts anymore as they should.

I banged my head against the wall for a while, googled, googled some more and tried this and that. Nothing seemed to help. One workaround I tried was this most commonly mentioned solution of adding a URL filter web part and setting it up as instructed eg. in this post here.

This, however, did not work for me, or this customer site. Be it due to the language pack (Finnish site) or something else, but it did not work. So I needed something else. This is what I did:

1) I created a new blog in the test environment. Really it doesn't matter where, just as long as you can access it in SharePoint Designer.

2) I opened both the new non-broken blog site and the old broken one in SharePoint Designer. I know. I sighed deep when I realized I really needed to go that far. But unfortunately the problem seems to reside in the corrupted query of the posts web part and in order to fix that, yes, SPD is required.

3) The two pages that are not working properly when categories and archive are not filtering posts, are Categories.aspx and Date.aspx. These are not in the Site Pages library of the blog site; you need to dig them out from the All files directory. 

All files > Lists > Categories > Category.aspx

All files > Lists > Posts > Date.aspx

Open both files on both your broken site and the new one created.

4) No, copying all code from one to the other will not work because of the GUIDs. As stated earlier, the broken part is the CAML query of the Posts web part. So the first thing to do is to locate the Posts web part. Since you are working in code view only, look for the main place holder with the blog-MainArea to find the correct web part.

5) Focus on the line starting <View Name="{...

6) Scroll horizontally (or set your page to wrap lines) until you find the <query> tag. This begins the CAML query for the web part. On the borken page it was missing parts. So I copied the query (everything between the <query> and </query> tags) from my new site category and date pages to the broken corresponding ones, replacing the broken queries.

7) I saved my files and tested them. The initial refresh filtered posts nicely, but the blog navigation (the categories list and the blog archive) links were broken, for the Blog tools web part was broken. It seems that any time you open a blog page into SharePoint Designer, this web part breaks.

8) So, I edited both pages in the browser, deleting the broken Blog tools part and adding it back in place and yes, things started functioning again! 

Hope this helps someone else save some time. Boy, there's never a boring day with SharePoint!

Design and Development in SharePoint Online vs. On-premises

And a little bit about planning the mobile sites as well. That was what I had a session about at the TechNet Helsinki 2011. You can find the presentation slides (.pdf) on the TechNet site (in Finnish) and the presentation video in Channel9 (also Finnish of course).

The important things to remember about SharePoint Online in sense of customizations, design, development, are that 1) there is no Farm Administrator role for the SP Online customer, only the SharePoint Online Administator, and 2) the things you can do with your SP Online site depend partly on the lisence you pay. So what it means, is that you are not able to install anything on the SharePoint server, nor change any server settings in SharePoint or IIS, and also that the license really does matter. Whereas of course, if you host your own SharePoint server, there are no such limitations. (See more about SharePoint Online licensing)

Customizations compared, in the browser your possibilities are equal with these two - and in a sense here lies the true power for SharePoint Online development: utilizing the power of the client! You can use e.g. JavaScript, including jQuery etc. in the browser, in Content Editor Web Part for example, but the real power comes with VisualStudio and the client object model.

With SharePoint Designer you can do a lot in both (including harm), but there already are some limitations to this in SP Online. The SP Online adminitrator has the most permissions to SPD, as well as the permission to grant or restrict the use of SPD (fortunately, by default, the admin is the only one who is allowed to use SPD). 

With VisualStudio (i.e. development tools and possibilities), you run into the most limitations. But don't let them fool you. There's a lot that can be done developmentwise with SharePoint Online too.

1. The Sandbox model. It is a subset of the complete SharePoint develpment toolset. I doesn't allow you to deploy anything in the GAC, and it doesn't allow you to access any services. It can use a basic set of objects within the Site Collection. You can make your own web parts, access lists, handle events etc.
   Update (Dec. 8, 2011): As of this autumn, Business Connectivity Services (BCS) are available for developers in SharePoint Online (see more about SPO update and BCS & SPO)
2. The client object model. This, since it is run on the client side, in many cases can pretty much cover the shortcomings of the Sandbox model when it comes to e.g. accessing external data and using web services. It includes .NET Framework Managed, JavaScript and Silverlight. 

So as a conclusion, combining both development models, you can have your SharePoint Online site customized pretty effectively. As for the SharePoint Designer, I generally don't recommend it as a tool for the things that can better be done in a controlled and managed way with development tools in SP Online anymore than on-premises. But it can be used by advanced power users for customizing list views, creating workflows, creating list templates in a more lightweight manner, possibly on top or in addition to what has been done by development tools, globally. And the latest addition to this is that from autumn 2011 on, Business Connectivity Services are available in SharePoint Online, and you can set them up in SPD unlike before.

For more information on both and the whole picture, see the TechNet Library article on SharePoint Online development.

So how to fit the mobile view into all this? What should you know and take into consideration when planning the mobile usage of your SharePoint site, whether it be Online or on-premises? There is a very good blog post on this subject by Mike Hacker, I won't go into as much detail here. But a couple thought on that subject here too.

First of all, you might want to evaluate the most probable mobile usage for your site. If it is all about team sites and document management, it is probably enough to enable mobile views in your SharePoint environment (enabled by default in SP Online) and make sure that all of the newly created list get mobile view activated as well (the default ones have this feature enabled by default but new ones don't).

If we are talking about a publishing site, or sites, the question of the mobile view, or mobile site, gets whole new angles. Should we force the complete web site to mobile users too (needs some adjustments on the server, so this is not supported in SP Online)? Or should we then create another css stylesheet for mobile users (which is probably the easiest way to make changes for the mobile users in terms of detecting the device, but then again doesn't give the mobile user a choice)? Or make a completely different set of masterpages? And what about our web parts? Are they mobile compatible?

Make it this way or that, my personal opinion is: give the users a choice. Don't force a mobile view on mobile users, thinking that you're doing them a favor by making browsing easier. Not all mobile users like mobile views. And even more so, there's a whole lot of mobile devices with approx 10" displays which is quite enough for a full scale web experience.  

With SharePoint Online - on on-premises with the default mobile view settings enabled - it depends a bit on the device which way it will show the site by deafult. As the user with the device, you can switch them either way by changing the ?Mobile= -parameter in the URL string. The zero is the full view, one is the mobile view. So e.g. http://url/?Mobile=1 would be the forces mobile version for the site, whereas http://url/?Mobile=0 would be the forced full version of the site.

Hmph. SharePoint Designer failed me (again) and the photographer was there to document the moment.