Forum Discussion
Solved
Migrating HTML to Modern Pages - Looks great until page is edited, then content is lost
We are migrating HTML to modern pages using code like: var page = context.Web.AddClientSidePage(pageName, true); page.PageTitle = "some title"; string htmlContent = "<some html content from ano...
The easiest way to understand what's valid HTML is to create a piece of text using all the layout and formatting options you need. Once you've that you can grab the page list item and look at the canvascontent1 field to obtain the generated HTML. You'll see that only a limited number of styles are supported and fixed set of classes for color and size information. Anything else you use can be initially displayed but will be lost during edit.
Thanks, that helps. This will be tedious.
This is an older thread, but if anyone is still here, there seems to be a bug in SharePoint Modern Pages where table content is added through the UI. We added a small table of content to a page, saved it, published it, then when we went back to edit the content disappeared.
In other words, it might not just be a valid/invalid HTML thing. There might be a bigger issue here.
- My experience (now over 3 years more experience from my original post) is that HTML copied into a Text web part works but that if you edit/save the web part, styling at a minimum is lost (font family, font color, and more). The Text web part is a moving target as features change (3 years ago you couldn't add images to the Text web part, but now you can).
I am getting the similar issue with SharePoint Online - migrated HTML content is lost while editing and saving the page. I can roll back to the previous version and get to the content. I think some security feature is blocking the content which is migrated programmatically through a script.
It appears to be a bug in the product or a security feature that sanitize the content after each edit and save but interestingly this is not an issue at first when the page is getting created programmatically and MS SPO is allowing the paged to be saved and published. Very Strange.
It is like I have ticket I can board the train first time but I can get-off and but can not board the same train again 🙂 Microsoft is really up to something with no or very little information available to diagnose the issue.
Please do contribute in case anyone is facing the similar issue on Microsoft SharePoint Online and have any suggestions.
Thanks in Advance. Happy to chat further.
Ugh, I was not able to reproduce this on a brand new page, so perhaps it's a combination of the web parts that are already on the page or perhaps it's the combination of styles that I chose at the time. Pure speculation: maybe selecting multiple table cells and choosing a font size somehow caused bad HTML to be generated or something.
I copied the rendered content (not the code) from published page using ctrl+c, then used ctrl+v to paste the content back into the text webpart. I am now able to successfully edit the page. Weird.
Not quite reproduction steps, but additional info:
- the page is an intranet homepage, so it has a powerapp part, a yammer part, some links and text parts, etc.
- the text content I was struggling with was a Heading, a 4x4 HTML table, and some paragraph text. The 4x4 HTML table had some font formatting all done through the UI, but I remember struggling with the interface to get the colors to stick. For example, I would select some text, change it to Red, then select some OTHER text and was not able to change the color to Green until I clicked outside the editor box and let the page auto-save.
- I was able to reproduce the "disappearing content" bug consistently by restoring the version of the page
Thanks for the input in this thread! I agree I should open a support case.
I agree that it is a bug. You clearly said it was added through the UI, but I was missed that before.
- BertJansen
Microsoft
This looks like a bug, tables created using the editor should always stay editable by the editor. Can you open a support case for this? Alternative describe a repro in here and I'll get the right folks to see it.
Thanks for the reply! We are editing the content using the WYSIWYG editor, not through HTML, so adding an additional div is not relevant in this particular case. Whatever HTML is being generated by the OOTB editor is not able to be rendered in edit mode. As a result, switching to edit mode and saving the page with no changes will result in lost content.
If you are using a "<table>" element, then you need to add wrap it with additional divs that have "canvasRteResponsiveTable" and "tableWrapper" classes. See my comment further above for more details.
