[5.x]: Issue with “Last Edited By” column in Multi-Country Setup

[karthikkstar]

What happened?

Description

We’re experiencing an issue with how the “Last Edited By” column display in our multi-country Craft CMS setup.

• Our site uses a template duplicated across multiple countries.
• In the entry list view, the “Last Edited By” column shows the last editor globally, regardless of which country’s entry is being managed.
• This is causing confusion among our agents, since edits made in one country appear under other countries’ entries.
• As a temporary measure, we have disabled the “Last Edited By” columns, but ideally, we would like to display the correct, context-specific information instead of removing these column.

Questions:

• Is this expected behavior in Craft CMS when working with duplicated entries across multiple countries?
• Is there a way to filter or scope “Last Edited By” so they reflect only the relevant editors within that country/section?
• If not, is there any workaround or upcoming fix planned to address this?

We’d appreciate your guidance on how best to resolve this, as our team finds this information useful but currently misleading.

Steps to reproduce

Expected behavior

Actual behavior

Craft CMS version

Craft Pro 5.8.17

PHP version

8.2.27

Operating system and version

Linux 5.4.0-208-generic

Database type and version

MySQL 31

Image driver and version

GD 8.2.27

Installed plugins and versions

No response

[linear[bot]]

CMS-1594 [5.x]: Issue with “Last Edited By” column in Multi-Country Setup

[brandonkelly]

This is working as expected. The Last Edited By column shows whoever created the latest revision for the entry, and entry revisions are global, not site-specific. That’s the case for two reasons:

• Drafts are multi-site, so authors can make changes to multiple sites’ content within the same draft, and apply all sites’ changes together.
• Even if only one site is being edited, any non-translatable field values will get copied over to the other sites.

That said, this isn’t the first time there has been confusion around this behavior, so we’ll discuss internally and see if there’s any room for improvement.

[karthikkstar]

Thanks for the response.

I have a section called ‘Page’ where the propagation method is set to ‘Save entries to all sites enabled for this section.’ The last revision was saved on the ES site entry by the ES admin, but it is being displayed on the UK site’s page listing as ‘Last Edited by ES admin.

If the last revision is for an ES site entry, it will be displayed in the ES site entry listing and not in the UK site entry listing. Similarly, if the last revision is for a UK site entry, it will be displayed in the UK site entry listing and not in the ES site entry listing

Thank you in advance.

[brandonkelly]

@karthikkstar Yeah as I explained in my last comment, that is working as intended right now. Drafts and revisions are not site-specific, and don’t track which site was selected when the edits were made. We will look into whether it makes sense to improve the behavior though.

[bramnijssen]

Just to add our case to this discussion — we’re also experiencing this issue and are looking forward to seeing if anything will be done to address it. Thanks!

We’re running into a similar issue in our multi-site (franchise-based) Craft CMS setup where users update entries that were initially saved to all sites (each site containing its own localized content).

Each entry is configured with “Let each entry choose which sites it should be saved to.” Users only have access to their own site and can edit localized (translatable) fields for that site.

The problem is that in the Revisions view, users see revisions made by other users from other sites, even though those edits didn’t affect their site’s content at all. This creates confusion — for example, User A might see “User B updated this entry” even though that change only applied to another site’s localized version.

From a user’s perspective, it would make more sense if revisions were scoped to the current site, showing only changes that actually affected that site’s content (including 'admin edits' to non-translatable/global fields).

It sounds related to the current global handling of revisions, but it would be great if site-specific revisions could be considered — especially for multi-site setups where localized content is independently managed.