Duplicate draft created when using page.create:after hook (Kirby 5.3.x)

[gbdesign2023]

I am using the following hook in my config.php to automatically set newly created pages (for specific templates) to listed:

use Kirby\Cms\Page;

return [
  'hooks' => [
    'page.create:after' => function (Page $page) {

      $allowed = [
        'news-item',
        'stats-item',
        'shop-item',
      ];

      $template = $page->intendedTemplate()->name();

      if (in_array($template, $allowed, true) === false) {
        return;
      }

      if ($page->isDraft() === false) {
        return;
      }

      $page->changeStatus('listed');
    }
  ]
];

The issue also occurs with this simplified version:

'hooks' => [
    'page.create:after' => function ($page) {
        $page->changeStatus('listed');
    }
]

Since updating to Kirby 5.3.0 (also reproducible in 5.3.1), the following issue occurs:

1. When creating a new page in the Panel, the page is correctly set to listed.
2. At the same time, an additional draft with the same slug is created.
3. This extra draft contains only a .txt file with a uuid field — no other content.
4. The draft and the listed page have different UUIDs.

If I attempt to delete the draft in the Panel:

• The listed (original) page gets deleted instead.
• The draft remains.
• The remaining draft cannot be deleted anymore.

This behavior did not occur before version 5.3.0.

It appears that changing the status inside the page.create:after hook may interfere with draft handling or UUID generation in Kirby 5.3.x.

20260217-091708-ScreenShot.mp4

[afbora]

When changeStatus() is called inside the page.create:after hook, the draft directory is moved to the published location, but the $page object returned from commit('create') still points to the old draft path — causing uuid()?->populate() to recreate the draft directory with only a UUID field, as it cannot read the original content and generates a new UUID via storeId().

[afbora]

@gbdesign2023 Since ->changeStatus() creates a new object and ->uuid()->populate() in core is done through a new object when you don't return it in the hook, as a temporary suggestion, return the $page object with return in the hook.

return $page->changeStatus('listed');

[afbora]

Causing related PR #7809

[distantnative]

@gbdesign2023 I would recommend to return the new $page object (returned from $page->changeStatus() at the end of the hook - both as current workaround but also longterm this will be the better practice, no matter whether we add a patch here or not.

[gbdesign2023]

@distantnative Thanks for your suggested solution. The error is now fixed.
I have also integrated page.duplicate:after so that duplicate pages are also published directly.