<em> tag appears in revision log message when a revision entry is reverted

This is still an issue and is because things like NodeRevisionRevertForm use % placeholders. We get around this with a custom formatter than formats strings as markup. Since the revision_log is a string field, I think the easiest approach here is to just change the placeholder used to remove the markup in the first place?

Tested out and the issue is fixed for newly reverted revisions but for existing revisions they still have em tag. So do we need an upgrade hook to retroactively fix that? Are we okay with a mix of of the 2 on the same screen?

. So do we need an upgrade hook to retroactively fix that

I don't think that's a good idea, that could be tens or hundreds of thousands of revisions.

I’ll leave in review for others but seems odd to have mix and match. Can already see a ticket opened asking why some are italicized and some aren’t

> I don't think that's a good idea, that could be tens or hundreds of thousands of revisions.

Also, I might have some contrib/custom module modifying that message, so we shouldn't touch existing messages at all.

Reviewed the code, checked the test coverage, this looks safe to me.

We still need to cover #6 tho.

IMO #6 should be done in a separate issue, this is tightly scoped to just removing the placeholder markup from automatically generated messages from reverting.

I think we should fix the table to allow html. It means all the existing messages will work.

In this case we need to change the formatter for the revision log message to be able to use basic html. Then we can use it in views. If you look at the revision page after doing a revert the log message is perfectly rendered em tags and all.

The revision log message formatter should allow the same list of tags are we do in \Drupal\node\Controller\NodeController::revisionOverview()

        $column = [
          'data' => [
            '#type' => 'inline_template',
            '#template' => '{% trans %}{{ date }} by {{ username }}{% endtrans %}{% if message %}<p class="revision-log">{{ message }}</p>{% endif %}',
            '#context' => [
              'date' => $link,
              'username' => $this->renderer->renderInIsolation($username),
              'message' => ['#markup' => $revision->revision_log->value, '#allowed_tags' => Xss::getHtmlTagList()],
            ],
          ],
        ];

@alexpott I think that's a much larger task, we'd need to:

1. Add a new formatter
2. Update views
3. Write an upgrade path for any view that has a revision_log field to change the formatter.

Step 3 seems like it could be extremely disruptive.

The revision log is a plain text field, it should not contain HTML.