search

pnp / modernization

All modernization tooling and guidance
http://aka.ms/sppnp-modernize
MIT License
156 stars 86 forks source link

When Modernizing Publishing pages with Links, the links on the modern page point back to pages on the classic site #132

Closed russgove closed 5 years ago

russgove commented 5 years ago

Category

[x ] Bug [ ] Enhancement

Problem Area

[ ] Page Transformation: Error during the setup/use of the Page Transformation UI solution (did you check our troubleshooting guide?) [ ] Page Transformation: Error during the use of page transformation from PnP PowerShell [ ] Page Transformation: Error during the use of page transformation from .Net [x] Page Transformation: Page is not looking correct after transformation [ ] Modernization Scanner: something went wrong...

Hi, I'm migrating/modernizing an on-prem publishing site. I am using sharegate to copy all the publishing pages to a temporary site (tronetau-temp with publishing enabled) and copy all content to the final destination site (tronetAU without publishing enabled). Being as publishing is not enabled on tronetau, the publishing pages do not get copied.

Many of the publishing pages have links to other pages and documents in the site. When I use the migration tool to copy/modernize the pages from tronetau-temp to tronetau, the links on the pages point back to the pages on tronetau-temp. The links should be pointing to the corresponding page on tronetau.

jansenbe commented 5 years ago

I've been thinking about this previously...there's a need for some URL rewrite/mapping feature. Can I assume that content to link lives in the same location in the target site collection? Meaning if there's a doc lib mydoclib with folder ABC and in there a file B.docx...do you then have the same doc lib, folder and file available upfront of transforming the page? We could do a basic replacement of web server relative url's if we see a link, but there's a risk that results in broken links.

For links to pages the story is more complex as we can't guarantee all the modern pages are already available. Modern web parts (e.g.QuickLinks) do require the uniqueID of the item in the target site collection, so we can't simply assume the target file url. For url's in html content this obviously is possible.

Will need to do some thinking on this feature...not sure if I can deliver a solution for the May release.

russgove commented 5 years ago

So a bit of backgound, I'm migrating from an onprem 2010 publishing site to O365 using sharegate. I first migrate just the publishing pages to a tempsite (tronetau-temp with publishing enabled) and then migrate everything else to the final destination (tronetau with no publishing). I then use the modernization tool to copy/modernize the pages from tronetau-temp to tronetau.

So I can assure that the content to link lives in the same location in the target site collection by migrating EVERTHING to tronetau-temp rather than just the publishing content.

You mentioned that "Modern web parts (e.g.QuickLinks) do require the uniqueID ". I was unaware if that. If I user the -SummaryLinksToHtml do i avoid that issue?

My tentative fallback plan is to create a script to spin through all the SitePages and replace https://tenant.sharepoint.com/sites/tronetau-temp with https://tenant.sharepoint.com/sites/tronetau. I'm thinking this should fix most of the broken links to documents /pages/images -- apart from the quicklinks issue you noted above.

Also, you mentioned ".not sure if I can deliver a solution for the May release". I fully expect to be running on a dev build when i go live in mid May (for reasons out of my control). So if you have any pr's that need testing done on this after the May release i will be available. Is the dev branch frozen while you push out the May release?

Thanks once a gain for all the work you put into this. I realize its not your primary job.

On Tue, Apr 23, 2019 at 1:52 PM Bert Jansen notifications@github.com wrote:

I've been thinking about this previously...there's a need for some URL rewrite/mapping feature. Can I assume that content to link lives in the same location in the target site collection? Meaning if there's a doc lib mydoclib with folder ABC and in there a file B.docx...do you then have the same doc lib, folder and file available upfront of transforming the page? We could do a basic replacement of web server relative url's if we see a link, but there's a risk that results in broken links.

For links to pages the story is more complex as we can't guarantee all the modern pages are already available. Modern web parts (e.g.QuickLinks) do require the uniqueID of the item in the target site collection, so we can't simply assume the target file url. For url's in html content this obviously is possible.

Will need to do some thinking on this feature...not sure if I can deliver a solution for the May release.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SharePoint/sp-dev-modernization/issues/132#issuecomment-485907730, or mute the thread https://github.com/notifications/unsubscribe-auth/AASNDHDCBQ3JJAR23TFOGILPR5EFZANCNFSM4HH4QSRA .

jansenbe commented 5 years ago

I'll get a basic version in for the next release...might require some finetuning for more complex scenarios but should help you in your scenario.

jansenbe commented 5 years ago

@russgove : Added a simple option in (see https://github.com/SharePoint/sp-dev-modernization/commit/a12e5e14041c97ea01dc97cab6b4eda2df1980a0). URL rewriting will be on by default for publishing pages, but you can turn it off via the SkipUrlRewrite flag. Will add this flag as well to PS later today/tomorrow. Feel free to test :-)

Note: only Text content is rewritten, other web parts (e.g. summary links) still have to be added

@pkbullock : guess this is also useful in your scenario.

pkbullock commented 5 years ago

@jansenbe yeap, this is an awesome feature to build.

jansenbe commented 5 years ago

@russgove / @pkbullock : basic implementation is done for text content and for summarylinks content + a parameter has been added in PS to allow folks to skip URL rewriting.

Rewrite will try to:

I'll close this issue but create a new one to track some improvement ideas.