There should be an option to export all modern site pages.
Only the home page is exported.
Time and time again people need to create templates off of modern sites containing modern pages. The expectation is always that pages are part of the template. People are puzzled if not and I fully understand that.
Here https://github.com/SharePoint/PnP-Sites-Core/issues/1623#issuecomment-369199036 @jansenbe expressed that this was a conscious decision. Here https://github.com/SharePoint/PnP-Sites-Core/issues/1623#issuecomment-373408010 he expresses that you might rethink this.
The code also contains a comment from 2017 stating that it is impossible to return all files of a site. Is this really the case? What was the reason to not export them? https://github.com/SharePoint/PnP-Sites-Core/blob/a794db71c8ea954250c5ec3a506ee04dad3b9186/Core/OfficeDevPnP.Core/Framework/Provisioning/ObjectHandlers/ObjectClientSidePages.cs#L522
SharePoint PnP aims to be self-explaining and to meet certain expectations. @erwinvanhunen over here https://github.com/SharePoint/PnP-PowerShell/pull/1933#issuecomment-468921421 stated
the majority of people using PnP PowerShell are not coders, and do not necessarily have an understanding of the APIs and object models behind the scenes.
Building an extensibility handler from GitHub does not meet these expectations in my opinion.
Please rethink this. Please allow integrating this.
I use a workaround for getting all the pages.
The concept of I do is:
For each page found on the site pages
{
}
Hope this can help to have an idea
@PedroMordeP Yes there are currently two workarounds being advertised/used:
Get-PnPProvisioningTemplateBut this shouldn't be necessary. If everybody is forced to do - and subsequently does - such things this should just be integrated into the core templating engine.
The PnP engine exports all pages from a classic publishing site (or did the last time I checked), so I think it's reasonable to assume it would do the same for modern.
Kind of applies to #349 as well
PLEEEAAASSEEE allow this...
Using extensibility handlers is not simple - I tried using the referenced handler but wasted a whole day troubleshooting errors first in getting the handler ready and then using it - still not successful (I am a 10+yr exp developer FYI, think about others). By the way - If anyone has been able to use the handler successfully please document exact steps.
Would save enormous amount of time for tons of people using PNP templates, many as their daily job if this was somehow supported by Get-PnpProvisioningTemplate cmdlet itself, even if 1 page at a time or via page names sepaarted by commas or something.
We are not intending to use this as a migration at all. In fact we are just attempting to script the whole SharePoint deployment. We have a new SharePoint solution being developed (of course will have a few SitePages), during the dev process we are using Get and Apply PNP Templates as a method of providing 100% deployable code from DEV to Staging to PROD which is in a comprehensive, automated, idempotent, repeatable and orchestrated manner. That is one of the industry best practices. What is wrong with expecting the templating mechanism to help us achieve this, this is NOT about data migration, even simplest SharePoint solutions WILL have a handful SitePages - these are NOT data.
Regards,
Sukesh.
I got the extension handler running fine but are currently on vacation. I'll try to find some time afterwards to document this. _Unless_ this isn't necessary anymore because it will be included in the core framework by then? 馃憖 @jansenbe ?
Can this be closed? https://github.com/SharePoint/PnP-PowerShell/commit/c4074736a7218ad21701e703ca94765833be2c93#diff-3ad1ac8a798a39070e4807edcfb695baR127 indicates it's now built-in.
Most helpful comment
@PedroMordeP Yes there are currently two workarounds being advertised/used:
Get-PnPProvisioningTemplateBut this shouldn't be necessary. If everybody is forced to do - and subsequently does - such things this should just be integrated into the core templating engine.