Content Editor Webpart changes visible despite page being checkout (SharePoint 2016)

Question

So I have an issue with Publishing Enabled Pages on SharePoint 2016. The admin of a site before editing a page always checks out the page, makes changes, and than checks in and publishes the pages when page is ready to be seen by the employee population. However, simply saving page (not checking it in or publishing) allows users to see the changes.

I immediately thought this was a permissions issue, but checked and saw the standard users only have read permissions and nothing higher than that. I than noticed while doing some tests that the if I checkout the page, edit it, save it, and than discard the checkout, my changes are still there. Discard checkout should remove any changes made since the checkout but that is not the case.

UPDATE (August 13 2018):

It seems that the issue only occurs with CONTENT EDITOR WEBPARTS. Other webparts or rich HTML publishing fields behave as expected. So the focus is why do content editor webparts show their changes despite being checkedout.

The versioning settings are as follows:

Require content approval for submitted items? YES

Create a version each time you edit a file in this document library? CREATE MAJOR VERSIONS

Who should see draft items in this document library? Only users who can approve items (and the author of the item)

Require documents to be checked out before they can be edited? YES

Has anyone else encountered this issue before? Any help would be greatly appreciated. Thank you!

Answer 1

Do you have SuperUser and SuperReader cache accounts configured on your web application?

What do you get when you check:

$wa = Get-SPWebApplication -Identity "<WebApplicationURL>"
$wa.Properties["portalsuperuseraccount"]
$wa.Properties["portalsuperreaderaccount"]

If these accounts are missing or incorrectly configured, there will be caching issues that lead to shared content or seemingly incorrect permissions.

Answer 2

Thank you raredesign for the response. Before I could check that out we found out the cause of the issue.

We are currently using a third party solution called Pointfire that handles multilingualism. Using the 2017 October update, we noticed that on sites where pointfire has never been activated, the issue does not occur. Once we activate pointfire, the issue occurs. We were able to replicate this on several test sites.

We will be raising a ticket to Pointfire on this. They have since come out with another version so its entirely possible they may have already resolved this issue.