This is a public Forum  publicRSS


    Anthony Smith
    18A - Answer Editor Issues
    Topic posted March 13, 2018 by Anthony SmithApprentice, last edited Yesterday 
    25 Views, 1 Comment
    18A - Answer Editor Issues

    Anyone that is considering switching to 18A, as awesome as this release is because of the versioning and a bunch of other stuff however there is one thing that isnt included in the release notes, and looks like the documentation for 18A is still showing earlier version screenshots and not the current ones.

    The HTML editor is no longer colour coded, if your content editors are spending most of their time editing HTML (such as the ones in our team), then this will cause a bit of an issue.

    I escalated this as an SR and it looks unclear whether this feature will become available, here is part of the reply:

    "We had reached out to our development team about this same issue when we upgraded our own site and we were told that this was an expected change with the new answer editor so that it could better integrate with the Browser User Interface.

    I am going to re-ask our development team to scope this issue.
    If a defect is identified, the development team will scope a fix, schedule the work, and determine the target release(s) for the fix. The target release depends on the severity of the defect and the significance of the necessary code changes.  We are unable to provide you a date on which you can expect a fix but we will update this service request again in the future when the solution has been delivered within a maintenance pack or new release available for immediate upgrade.
    If the defect is not verified and found to be working as originally designed, we will update this service request with further information at that time."

    So if you rely heavily on working in source, you may want to keep this in mind before upgrading.


    Edit (March 19)

    We've since identified a few more faults that have been introduced as part of 18A. I've listed them in the Idea Lab ( but I'm hoping that'll be sorted in the next release as I can see many organisations struggling with this.

    • WYSIWYG gets two vertical scrollbars when the content gets to a certain size (roughly 30-60 lines, we haven't counted but it's nothing out of the ordinary). Also as an additional annoyance, if you scroll the "outer" scrollbar, then alt-tab to another page and come back, the scrollbar defaults back up to the top so you have to scroll down to the right area again.
    • Tool bar scrolls out of view - then one of theh vertical scrollbars is scrolled down, the toolbar (which is no longer pinned to the left but is now at the top) scrolls out of view.
    • Using "Paste as text" feature now adds <div> tags to every line instead of <p>, etc. This prevents editors from being able to complete certain actions in the WYSIWYG without editing the source e.g. changing bulletpoint level, etc.

    As a workaround we are now making most our edits in Notepad++ and then pasting the source back into the WYSIWYG as it seems to be a bit quicker and less frustrating for our content team.




    • eleep

      Thank you for taking the time to share this change with the community, Anthony! We appreciate you taking the time to share this key difference here. Just wanted to let you know that I have also notified Documentation of this, so they can look into what updates would be appropriate.


      Erica, Oracle Service Cloud