Content created manually show incorrect date and author on revision record for initial creation

[yorkshire-pudding]

Description of the bug

If content is created in a content type where revisions are disabled, then if revisions are later enabled, the first revision (i.e. node created) is shown as being 0 (i.e. 01/01/1970 00:00 - timezone adjusted) with an author of Anonymous).

If content is created in a content type where revisions are already enabled then this also applied.

If content is generated (e.g. Devel Node Generate or Feeds), then the correct date and author are shown.

Steps To Reproduce

To reproduce the behavior:
Content type initially revisions disabled

1. Set a content type so revisions are NOT enabled
2. Create a node of that content type
3. Enable revisions on the content type
4. Edit the node and save a revision
5. View the revisions overview table (node/%/revisions)

Content type with revisions enabled

1. Create a node of that content type
2. Edit the node and save a revision
3. View the revisions overview table (node/%/revisions)

Actual behavior

First revision has message:

01/01/1970 - 1:00am by Anonymous (not verified)

NOTE (BST so UTC+01:00)

Expected behavior

First revision has node author and node created date

Additional information

Add any other information that could help, such as:

• Backdrop CMS version: 1.35.x-dev (though this has probably been around since the beginning)
• Web server and its version: n/a
• PHP version: n/a
• Database sever (MySQL or MariaDB?) and its version: n/a
• Operating System and its version: n/a
• Browser(s) and their versions: n/a

---

PR: backdrop/backdrop#5312

[yorkshire-pudding]

I've added a PR at backdrop/backdrop#5312 which fixes the problem for new nodes and adds an update hook that corrects this for existing nodes.

The update hook makes an assumption that the current owner (uid) of the node is the author who created the node which most of the time will be correct. We don't have any information to know if it is not correct so this seems a reasonable assumption. It also checks to see if there is another revision record with a uid (i.e. content was created when revisions disabled, then revisions enabled and at least 1 revision added) and uses that rather than the current owner if so.

It uses batch processing so should be able to handle large numbers of nodes. I tested it locally with ~50,000 nodes (used Devel Generate to generate, then sql query to set uid and timestamp to 0 in the node_revision table, as code generated nodes have a uid and timestamp)

SQL

UPDATE `node_revision`
SET `uid` = 0, `timestamp` = 0

Note: unrelated cspell test fail ('readmore') - intermittent - not on every commit

[avpaderno]

In the live preview for this issue, I disabled revisions for the Page content type, create a node of that content type, re-enabled revisions, and edited that node. Looking at the revisions page, I see the author and the creation date are correctly set.

In my case, the created time for the first revision is correct (for UTC time, used by the live preview).

[avpaderno]

The update hook makes an assumption that the current owner (uid) of the node is the author who created the node

I had to read that phrase twice to understand it: In the case the owner is changed before the update hook is invoked, the update hook will assume the last owner is the original owner.
I think that is the correct action to take (given that there is no track of the ownership change): If I had to change the node owner before revisions are enabled, I would not want the previous owner to appear in the revisions list. I am not sure there are sites where showing the first owner is wanted; if that is the case for some sites, those sites should enable revisions for the content type before people are able to add content.

[yorkshire-pudding]

The update hook makes an assumption that the current owner (uid) of the node is the author who created the node

I had to read that phrase twice to understand it: In the case the owner is changed before the update hook is invoked, the update hook will assume the last owner is the original owner.

That is correct, assuming that also revisions weren't enabled and a revision created before the owner changed.
If revisions were enabled and a revision took place before the owner was changed, then in that case, it is likely to be more accurate that the author of the first revision was the creator of the content.
If no revision has happened then we won't have that information so we have to rely on the current owner.

[indigoxela]

The timestamp part works great! 👍

A bit of concern: this would be the first time in core that a batch job is run inside and update hook. Usually those have been avoided by setting a flag (a state or so) and running the batch after the update, triggered by admins.

[avpaderno]

I did another test. I disabled revisions for Post content types and created a new account (editor) with the editor role. I then created a new Post node, setting the owner to editor. I then enabled revisions for Post nodes, and created a new revision (using the admin account).
The node itself showed Mon, 03/08/2026 - 12:09pm by editor, but the revision showed the first revision was done using the admin account.

The revision is correct, since effectively the first revision was done using the admin account.
For me, seeing admin as account used to create the first revision is expected, but there could be cases where the account set as node owner should appear as account used to create the first revision.

[yorkshire-pudding]

A bit of concern: this would be the first time in core that a batch job is run inside and update hook. Usually those have been avoided by setting a flag (a state or so) and running the batch after the update, triggered by admins.

Is there any example you can point me to? I've tested it a number of times with large datasets and it works well, but if running it here is not best practice, I'll happily try to follow what is best practice