With this PnP Framework being SPO only and Microsoft investing heavily in Modern sites like communication and team sites, the classic sites (like publishing sites, enterprise wiki, classic team site etc.) even though not deprecated will not be actively receiving new features and investment from Microsoft.
It would now make sense that we too as a community move towards the new Modern direction.
Would like to propose that, we start by removing classic features (list below) used in these classic sites from the provisioning engine. This will make it easier for us concentrate on enhancing and adding new capabilities without getting bogged down by "legacy/classic" stuff. It will make the engine better, smaller and faster.
List of features , I would propose that we remove from the engine:
1) Provision classic workflows.
2) Provision publishing/wiki/webpart pages (classic pages).
3) Provision Image renditions , not needed in modern sites.
4) Provision composed looks , not needed in modern sites.
5) Provision property bag, not supported in modern sites.
Some reasons :
2010 classic workflows are already deprecated, 2013 workflows also based on legacy tech. Microsoft is heavily investing in PowerAutomate and PowerApps and the low-code platform. So, would make sense to add support for them in the engine whenever there are APIs available for that.
For Publishing/Wiki/Webpart pages, we have the excellent PnP Modernization tooling which helps you move the classic pages to modern pages.
Image renditions, property bag are not supported in the modern sites. Yes, you can provision property bag but for that you need to modify site collection property and then make the change. Similar thing for Composed looks, it is now replaced by the new Fluent UI based themes, we already support them via the engine
Would love to hear your feedback and comments on this. The above list is not exhaustive, there are also certain extensions we looked at which are using the classic capabilities which simply wont work in the modern sites.
If folks agree on this, happy to pick this task up.
The library is in preview and not supported for production use, so breaking changes are easier to accomplish now before this goes GA , so really appreciate any inputs on this.
Thanks for the detailed analysis @gautamdsheth , we indeed need to remove classic features which folks should not use anymore on SPO. Looking at your list I agree for the most part with it, but would like to still keep support for some parts, mainly to enable folks that use PnP Sites Core today to switch to PnP Framework, even if they're not yet fully on modern:
From a removal approach we should remove the handlers from the list of possible handlers and for now just comment out the relevant code.
Adding @PaoloPia , @erwinvanhunen and @VesaJuvonen for feedback.
@jansenbe Has there been any changes to the support for property bag entries that has not been documented? The current documentation that I know of states that it is supported to modify the property bag for a modern site if the site has NoScript disabled which is also supported to have on modern sites. If this is still the case then this feature is needed for all types of modern sites.
In Customizing "modern" team sites it says the following:
Because "modern" team sites also have scripting capabilities disabled (it's a so called NoScript site), numerous areas cannot be customized. The impact of NoScript is the same for "modern" or "classic" sites. "Modern" sites have NoScript enabled by default, meaning that scripting capabilities are not available. However, it is possible and supported to disable NoScript settings in both "modern" and "classic" sites to further enable some capabilities.
-Ability to access or update site property bag entries.
and
You can use the PnP provisioning engine with "modern" team sites. The PnP provisioning engine automatically detects if a site is a "modern" team site and adjusts its behavior based on the supported capabilities. The process is exactly the same as using the PnP provisioning engine with "classic" sites where the scripting capabilities are not disabled.
The following elements are ignored when a remote template is applied to a "modern" team site or a site that has NoScript enabled:
-Adding or updating property bag entries to the site property bag
So if this documentation is still valid it is supported to have a modern site with NoScript disabled and if that is disabled it is supported to modify the web property bag. Also if NoScript is disabled for a site the provisioning engine should support modifying the web property bag on all types of modern sites as well as classic sites.
I agree with you @patrikhellgren , we should not yet take away property bag support from the provisioning engine. There are sites like sts#3 that allow property bag updates by design, other modern sites you can use it after disabling noscript. Disabling noscript is not something I would recommend, but it's a supported scenario.
Thanks @jansenbe - makes sense to keep supporting property bag.
Any reason for keeping wiki/webpart page provisioning ?
They can use Modernization tooling for transforming to modern pages.
If they want to provision wiki/webpart pages, then they can keep using the PnP Sites core.
This way we can encourage folks to modernize not just the tooling but also the classic stuff itself.
It can indeed be an incentive to modernize. Let's then follow your suggestion...if folks are really blocked by this change we can always include support for wiki pages again (hence my ask to for now comment out code instead of completely wiping it).
@gautamdsheth : this one can be closed per our IM discussion we had in the PnP Core SDK chat
Most helpful comment
I agree with you @patrikhellgren , we should not yet take away property bag support from the provisioning engine. There are sites like sts#3 that allow property bag updates by design, other modern sites you can use it after disabling noscript. Disabling noscript is not something I would recommend, but it's a supported scenario.