Has anybody had "Switching to WYSIWYG may corrupt some of your data. Confirm?" actually happen?

Is this warning necessary? Has anybody reported or experienced data being corrupted by switching to WYSIWYG. I think this is an alarming way of saying something that should not be so alarming. If sometimes data is corrupted, perhaps we could come up with a gentler way of informing users. For clients who have recently converted over it seems like an error or a bug.

If this warning is necessary, I’m not sure I have the best language for this but something along the lines of "Saving in WYSIWYG mode may alter… " I’m not sure what it will alter. “Saving in WYSIWYG mode may change page appearance. Proceed?”

I’m sure somebody in the community has a better way of saying this. Any suggestions?

5 Likes

Totally agree - have never seen any problems/errors, so it do seem a bit too much with this warning. For me personally I would rather it was not there at all and IF anything where to happen at some point I would just explain it to the client. But if it is left there it would be great with a less alarming text as mentioned :slight_smile:

– In general it is just annoying :slight_smile:

3 Likes

Totally agree. The warning leaves users confused/concerned about switching between WYSIWYG and Code views and gives the impression that the CMS is fragile. I’ve not seen any issues occur when switching views so I don’t think the warning needs to be displayed. (Or, if there is a prevalent issue that I’m yet to encounter then perhaps the warning should link to more info.)

Same here. Never had problems. Would look better without the warning.

I was switching between the 2 and noticed I had a second page get created with the same URL but with a “-1” added to the URL … if not caused by switching between the layouts does anyone know what is causing this and how to avoid?

Yeah, that’s a seperate issue @JFK and I think you need to contact support for them to fix.

Hello everybody.
We’ve added this warning message because if you use complex liquid implementation on the page and switch from editor to WYSIWYG, then your implementation may be broken. If you use light implementation you won’t encounter such issues.

We want all users to be notified of this problem, so we can add some less noticeable notification, such as an exclamation mark next to the mode switcher.

1 Like

Thanks @Eugene for the info. Exclamation mark would be fine for us. IMHO it should be part of best practice on the development side not to use complex liquid on the page level in a way that it can break when switching the editor - as long as the editor is being used by a client and not exclusively by the dev.
That being said, it would be interesting to learn what “complex liquid” exactly means in this context, so we can avoid it in such scenarios. Everything beyond module calls (because that works fine as far as I can see) or can we still use loops and conditionals?
And what about putting complex liquid which would usually break after switching the editor in an include file. Shouldn’t that avoid any problems?

The problem is related to the characters that are used in the implementation (’>’, ‘=’, ‘+’, etc.). WYSIWYG sometimes encodes these characters in the HTML code.

If your implementation is placed in snippets there should be no problems.

Thanks for the clarification @Eugene . It’s also good to know what bug can be caused by this which will help troubleshoot if there are any issues.

Thanks @Eugene. I think that can and should be easily handled on dev side so we can get rid of that pop-up window for our clients. That’s my 2 cent.

The liquid code will stop working and an error will be displayed on the page: http://prntscr.com/qnvp87. You can fix this error only by restoring the encoded characters.

Yes, the only time I have seen this be an actual issue is when I add special characters within an emptyMessage field, for example: emptyMessage="

"

In these rare cases I hide the implementation from clients in an include or something, so nothing is affected on page load.

Should it be optional to disable the warning. That way devs who know can learn about potential issues and then disable intentionally. Thoughts?

It’s highly unlikely that any clients will be writing complex liquid so they don’t need to see the warning. For dev’s, experiencing syntax errors due to special characters being reinterpreted/encoded to html is a familiar experience. If it occured as you’ve outlined I think most devs would quickly see and fix the issue. As I’ve said before, the warning reflects poorly on UX as it makes the CMS seem fragile. I really don’t think it needs to be there.

^^ totally agreed on all points.

I haven’t had any issues either. Totally agree with the softer approach on the message. - :slight_smile: Maybe: In some extreme cases if What you see isn’t what you get you may need to revert to HTML. :wink: