Recently our Custom Actions stopped working in modern document libraries in Office 365. We were surprised at this, because as far as we were aware we weren’t doing anything that went against “new” guidance for working with modern team sites and modern document libraries. Since the beginning of modern doc libs, Custom Actions which use ScriptSrc or ScriptBlock have not been supported (same with JSLink customizations). But we weren’t doing any of these things – our specific details were:
- A Custom Action using a URL-based action which opened a modal dialog (pop-up) – in our case, to show a custom options page to the user
- Use of “EditControlBlock” as the location, so our menu item appears on the context menu for each document
- Registered on our “base document” content type which is used in our document libraries
And for a while everything was great - as expected, our menu item showed up in both the classic and modern document library experience. However, in early December (2016) our menu item disappeared from the modern experience, across all our tenancies (eventually). These images show our menu item (named “Actions”) visible in the classic view but not modern:
New rules for Custom Actions
Essentially, Microsoft have made changes in exactly what is supported with Custom Actions. I guess you could say this doesn’t align 100% with previous guidance on the topic – or at least, some low-level details were ambiguous or open to interpretation. For example, the Update on Modern Document Libraries and Extensibility blog post says this:
“We’ve already made some good progress here. Theming, global navigation links, and URL-based custom actions that extend the ribbon and context menus are already supported in the modern document library experience. This ensures that customers and partners taking advantage of these features can use the modern document library experience without compromising their customizations.”
Additionally, targeting by content type no longer works – the only option currently is to target by list template type, for example: 100 – custom list 101 – document library ..and so on
UPDATE – targeting by content type now works again. So you can once again target by content type or list template type..
I appreciated the help from folks in the product group who helped me understand what their code is currently doing, and where things might head in the future – thanks guys.
Could any of these changes affect you? If so, you’ve probably noticed already – but either way, it’s definitely worth SharePoint developers becoming clear on the latest developments in this space. Overall, there is a longer list of these kind of things which are no longer supported on modern lists and libraries, including:
- Custom master pages
- JSLink (field and view types)
On the bright side, there is now some official documentation in the form of MSDN articles which provide more detail than I’m including here. I highly recommend going through these:
- Customizing "modern" lists and libraries (most relevant to this article)
- Customizing "modern" team sites
- Customizing "modern" site pages
Using the classic experience as a workaround
Remember of course that these changes don’t affect the classic experience. You have the choice of continuing to use that (e.g. by setting it at the tenant level) if you’re happy with that. We weren’t unfortunately, because we want our uses to have the benefits of the new document library UX (better mobile experience, improved metadata editing, new summary panel, sorting/filtering enhancements and so on).
Microsoft have noted in several places that new mechanisms will come to SharePoint Online to match many of the previous capabilities. They may not take exactly the same form as the previous mechanisms, but it should be possible to achieve the same overall result. These include:
- Custom master pages --> some other “deep branding” controls (which may or may not provide the ability to control the full HTML)
- JSLink --> some other mechanisms to control the rendering of list views and fields