This project has moved. For the latest updates, please go here.

Migrated Rich Text Fields

Apr 14, 2016 at 7:33 PM
Joe,

I'm loving SPEasyForms 2015.01 and am ensuring all of our sites are using this version as we work to migrate one of our networks from SP2010 to SP2013. Getting it tested and approved on the AFPL for my organization last year was quite an accomplishment so thank you for creating a reliable product.

That being said, I just ran across an issue with a migrated list. Migrated rich text fields seem to use the old construct and do not render properly on SPEasyForms. Here are my observations:
  1. The contents display properly on forms in any container.
  2. On New/Edit forms, the field is displayed in the Default Form and doesn't contain the field's content. Adding something to the field will overwrite whatever is stored there.
  3. Newly created multi-line rich texts fields do not have any issues.
Thanks for all you do.

Casey
Coordinator
Apr 14, 2016 at 9:16 PM
Hi Casey,

I have seen something like this a long time ago with the old rich text fields, but only when they were on one of my containers. That's part of the reason I gave up and stopped putting them on containers regardless of the configuration (that's a documented limitation at this point). But I don't recall ever seeing it on a rich text field that was still on the default form. Just out of curiosity, have you tried changing one of them to an enhanced rich text field? ERTE fields generally play better with SPEasyForms. Its not really a solution I realize, as I know you have a whole bunch of site collections.

This one's going to be a little hard for me to reproduce because I don't do a lot of migrations. I've got infrastructure people for that ;). And I'm pretty swamped right now, but I'll do what I can. I assume you migrated by detaching and reattached the content databases?

Great to hear that you got it approved. I know what an ordeal that can be.

Joe
Apr 15, 2016 at 1:50 PM
I've discovered the field properties that fix this which I'll implement locally via PowerShell but not sure if there's anything that can be done client-side.

Updating the RichTextMode property to "FullHTML" from "Compatible" and changing the same property within the SchemaXml for the field fixes this.

I'll let you know if I find any other issues with "Compatible" fields.

Casey
Jun 2, 2016 at 4:36 PM
Joe,

We've just discovered that this is a near-critical issue across our enterprise and had to disable SPEasyForms completely. I thought this was only for migrated fields but it's reproducable via the GUI in SharePoint 2013 so it's no longer a migration/compatibility issue.

When someone edits an item with Rich Text fields, SPEasyForms completely clears the values from these fields so when the items get saved, they get saved with blank values. In addition to this, we've noticed behavior where you cannot get true focus on a field until you click elsewhere on the page (white space)--only then does it allow typing in other fields. This only seems to be happening on the pages with these Rich Text fields. The issue is with the Rich Text field as opposed to the Enhanced Rich Text field. In SharePoint 2013, there is no default option to create a Rich Text multi-line but you are able to edit the field and switch it to standard Rich Text after-the-fact.

To duplicate:
  1. Add a Multi-Line Enhanced Rich text field to a list
  2. Edit the column settings and change to Rich Text
  3. Add an item to the list (with a value in the new field)
  4. Edit the item -- see that SPEasyForms has stripped the value
  5. Save the item without making any changes -- see that the value has been cleared on save
Any thoughts?!

Casey
Coordinator
Jun 2, 2016 at 6:03 PM
Hey Casey,

Unfortunately, I cannot reproduce this, so it's not a general 2013 problem, there is some environmental element involved. Without being able to reproduce it, I can't really fix it either. But rich text fields have always been somewhat problematic. About the best I can do is just say Rich Text fields are not supported at all, and make SPEasyForms abort entirely on any form that contains a Rich Text field (i.e. ignore configuration and don't modify the form at all, forms with enhanced and plain text multi-line fields would continue to work as is). If that is of any interest to you, I can go ahead and implement it and let you test it out (I'll test it out too of course, but since I'm not seeing your problem it won't really prove anything). Let me know.

Joe
Jun 6, 2016 at 1:59 PM
Joe,

The solution of disabling if there is a rich text field would work great. We can put that contingency in for our users who wish to use SPEasyForms ("switch any rich text fields to enhanced rich text to use SPEasy Forms") until we can resolve it across-the-board.

Casey
Coordinator
Jun 6, 2016 at 9:37 PM
Edited Jun 6, 2016 at 9:39 PM
Casey,

I will put this on my backlog and work it as soon as I can.

As far as a permanent solution, I don't believe I'm willing to tackle that at least with regards to fixing the built-in Rich Text editor. That code is thousands of lines of obfuscated/generated code, which means it changes substantially between versions of SharePoint. That's pretty much Microsoft's way of saying don't muck with this or you'll pay a price, and that's an supportability line I'm unwilling to cross. What I mean by that is that fixing it would probably require overriding the functionality of methods with names like $_0, which could easily change to $_3 in the next SharePoint release, and that's just not a viable solution. And for the most part, I can think of no good reason not to use the rich text editor pretty much all the time. It's better than the old Rich Text editor in all respects including that it works in browsers other than IE.

There is one possible work around, but it's pretty invasive and scary. I did write a plugin for 2014.01 that replaced all Microsoft Rich Text editors with my own. Because of timing issues, this is an all or nothing thing. I either replace them all or none of them, there is no option to replace them only on forms where SPEasyForms is installed. I made every effort to make my Rich Text editor look and act exactly as the OOB Rich Text editor, but there are some slight difference for instances the drop downs like font looked a little different. And the generated HTML is definitely different and in fact browser specific because it uses the browsers native Rich Text editor. One advantage though is that my Rich Text editor doesn't degrade on alternate browser (i.e. works on chrome and firefox just fine). I never released it though, because it is invasive and I didn't feel like I'd ever be able to do enough testing to be sure it worked well in all versions/environments. If I did release it, it would definitely be as a plugin and caveat emptor ;), but it actually worked pretty well.

Joe
Coordinator
Jun 7, 2016 at 3:42 PM
Edited Jun 7, 2016 at 9:49 PM
I've been looking at this a bit and I'm doing so little now if the list is not configured to use SPEasyForms, that I'm not sure what I could be doing that is conflicting with Rich Text fields, or how I could do much less before being able to determine that there are Rich Text fields. I'll keep looking of course, but I'm a bit confused at the moment ;)

Joe
Coordinator
Jun 7, 2016 at 9:58 PM
Ok, I was look at this wrong. I can tell there are rich text fields just by looking at the DOM, so if I see any I should be able to abort before I've made any changes to the DOM and before I've made any web service calls. That really should be enough to ensure that I don't step on Rich Text editors in any way. I should get a chance to work this on this coming weekend. I'll let you know when I have something for you to test.

Joe
Coordinator
Jun 13, 2016 at 12:01 AM
Hi Casey,

If you get a chance, please try this download and let me know if you still have the same problems with the old-style rich text editors. It hasn't been regression tested much, but since I can't reproduce your problem I wanted to get it out and see if it worked for you. Let me know.

Joe
Jun 15, 2016 at 6:48 PM
Joe,

I just downloaded it and should get a chance to try it out by the end of the day Friday. Thanks a ton. I'll let you know how it works.

Casey
Jun 15, 2016 at 7:23 PM
Joe,

This seems to work perfectly. Here were my test cases (that all worked as expected). The list already had an SPEasyForms layout so it was easy to recognize how it was working.

Test 1: With Rich Text
Open up a form with has a Rich Text field - does not trigger SPEasyForms rendering. Rich Text fields display their content as they should (are not cleared out as they have been). It does look odd that the SPEasyForms render on the display form but not on the New/Edit forms but that's for me to find a PowerShell / Training solution.

Test 2: "Repaired" list switched to Enhanced Rich Text
Switch Rich Text fields to Enhanced rich text - SPEasyForms renders properly on the new and edit forms and all is right with the world!


I find it very odd that even our cleanest install (no migrations) of on-premises SP2013 uses the Rich Text field rather than the Enhanced. I just created a fresh calendar and it uses that field type. I'll need to try my SP Online when I get home from work to see how that behaves.

I'll be on the lookout for an update. Thanks for all you do!

Casey
Coordinator
Jun 15, 2016 at 9:19 PM
Edited Jun 16, 2016 at 1:42 PM
Hi Casey,

Excellent. Yes, even SP Online has some lists that have Rich Text fields instead of Enhanced. Contacts is another one. I used contacts all the time for my demos because without any work it already has enough fields to look bad OOB, but the first thing I have to do is change Notes from RTE to ERTE.

I don't love this solution, but it certainly beats loss of data. Scott Shearer has been telling me to do this for years, because RTE fields have always been a PITA for this kind of solution, but I've resisted until the bitter end (which is now, enough is enough ;).

There is one thing that I can do in the final release to alleviate the awkwardness of this solution a little. I can detect that a list has RTE fields in the editor, and present a dialog explaining that you need to change these to ERTE or plain text if you want to use SPEasyForms on this list (and possibly not let you configure it until you do). This doesn't solve all problems though, because you can still configure the list with SPEasyForms and then later change a field to RTE, but it would help some.

I could even be a tad evil, and remove RTE as an option on the field edit page if the current list has an SPEasyForms configuration, but this still wouldn't solve all problems since it could be a site column pushing down all changes in which case there is no current list, so I wouldn't go this far.

I still have to regression test this release, I'm waiting to hear back from someone else on another bug I tried to fix in this release, and of course I'm still pretty busy, so it could be a couple of weeks before I can get this out as a stable release.

Joe
Coordinator
Jun 25, 2016 at 8:52 PM
Added Issue 49 - Old Rich Text fields lose data (sometimes?), fixed the issue, and released in 2015.01.03

Joe
Marked as answer by mcsheaj on 6/25/2016 at 1:52 PM