Page Path History entry is added when using page copy/clone

[adrianbj]

Short description of the issue

When you copy/clone a page, an entry is added in the PagePathHistory DB table after the page is renamed.

Expected behavior

Copy/cloning shouldn't result in an entry because it's just clogging it up for no reason.

[ryancramerdesign]

I can't duplicate this one. I've tried various different types of clones on pages with/without children, including children in clone vs. not, specified vs. auto-generated name... but none are resulting in any additional entries in my page_path_history DB table. Can you describe the process you are using that results in DB entries being added?

[adrianbj]

Ryan - thanks for looking into it.

1. Create page titled: AAA
2. Clone that page
3. Wait 2 minutes
4. Rename the cloned /aaa-1/ to /bbb/

Entry redirecting /aaa-1/ will be added to the PPH DB table.

I don't know if this comes back to the other issues recently posted and whether entries should only be added if the page was previously published with the old name? Maybe, not sure.

[adrianbj]

@ryancramerdesign - any chance of revisiting this please - I have a site where the client starts every page by cloning another one of that type, so I am getting a huge page_path_history table with all these:

/old-page-name-1 entries in the path field. This obviously being the automatic temporary name of the cloned page until they rename it.

[matjazpotocnik]

@adrian, this is stil an issue, right? How do you manage it? I asked AI on possible fix, but got this response from GPT-6 Astra:

Findings from source review and isolated tests

I investigated this against my local ProcessWire source. The reported behavior is still present: renaming an unpublished clone after the default 120-second minimum age causes PagePathHistory to record its previous, automatically generated path.

The entry is created during the subsequent rename, not during cloning. PagePathHistory::hookPageMoved() already skips active cloning operations, but after the age threshold it does not distinguish temporary draft paths from previously published paths. This also affects ordinary unpublished pages, not only clones.

Compatibility considerations

Suppressing history for every clone would be unsafe: a published clone may have a valid public URL that needs a redirect after renaming.

I also checked three possible guards:

Proposed guard	Problem
Skip pages without a publication timestamp	A freshly cloned object can retain its source's timestamp in memory. Conversely, saving a publication updates the database timestamp without immediately updating that property on the object.
Skip currently unpublished pages	This also skips previously published pages that are temporarily unpublished. Their old URLs may still need redirects.
Skip only unpublished pages without a publication timestamp	This still misses the inherited-timestamp case and cannot reliably distinguish never-published pages from older pages with missing publication information.

The migration that introduced the published column populated it only for pages published at migration time. A missing timestamp therefore does not universally prove that a page was never published.

Validation

I ran 29 database-free characterization checks using source-extracted methods with dependency doubles. These covered history recording, clone initialization, generated save SQL, publication transitions, and counterexamples to the guards above. These were isolated source-level tests, not a full browser/database reproduction.

Suggested direction

The unwanted history for temporary clone names is understandable, but I could not identify a safe one-line fix using the existing status and publication timestamp alone.

A possible approach would be explicit tracking of newly created unpublished clones until first publication, while preserving current behavior for existing pages and retaining history for published clones. That would need further design and integration testing.

As an existing workaround, the full clone form allows entering the final page name before cloning, avoiding the temporary name in that workflow.

[adrianbj]

@matjazpotocnik - I haven't been managing it honestly - I have a couple of thousand entries for -1 paths.

[matjazpotocnik]

Can you ask your agent on how to solve that? My agents suggest this:

Prevent new entries through the existing clone workflow
ProcessPageClone has an “Always use full clone form?” setting, available since 3.0.238. Enable it and have editors enter the final page name, not just the title, before submitting the clone form. That avoids saving /old-page-name-1/ as the clone’s initial URL. Enabling the setting alone is insufficient if editors still accept the generated name and rename it later.

He also prepared a script (with instructions) that:

• Lists candidate history paths ending in -1, alongside their destination page and history creation date.
• Exports those records as a backup and review list.
• Deletes only the selected records after the owner confirms they are disposable temporary paths.

foradrian.zip

[adrianbj]

I dug into this again with current dev. The entry isn't created during the clone — hookPageMoved() already skips while $pages->cloning is active — it's created at the later rename, because the only other guard is the 120s minimumAge, and _clone() sets the copy's created to clone time. So any rename 2+ minutes after cloning records the temporary /aaa-1/ path.

The fix I'd propose is more general, per my earlier comment: only record history for pages that have been published, since an unpublished page's path was never publicly viewable and there is nothing to redirect from. The native published column is a reliable signal here:

• PagesEditor sets published=NOW() only when a page is actually published, and the ajax quick-copy (the PageList "copy" action) always saves the clone unpublished, so a clone's published stays NULL until it's published.
• A previously-published page that is temporarily unpublished keeps its published date, so its redirects are unaffected.
• SystemUpdate12 backfilled published=created for all pages published at upgrade time.

One subtlety: when a page is renamed and published in the same save (the typical "rename the draft and hit Publish" flow), published=NOW() is written to the DB but not back to the in-memory Page that the renamed hook receives, so the guard also checks statusPrevious — consistent with how PagesEditor itself decides to set published=NOW().

In PagePathHistory::hookPageMoved(), after the existing minimumAge guard:

$age = time() - $page->created;
if($page->template->name === 'admin' || $this->wire()->pages->cloning || $age < $this->minimumAge) return;

// do not save paths for pages that have never been published, since an unpublished
// page has never had a publicly viewable URL, so there is nothing to redirect from
// (i.e. renamed page copies like /page-name-1/ or renamed unpublished drafts)
if(!$page->published) {
	// page is still unpublished
	if($page->isUnpublished()) return;
	// page was unpublished when loaded and is being published in this same save, in
	// which case the DB 'published' date is set but not yet in $page->published
	if($page->statusPrevious && ($page->statusPrevious & Page::statusUnpublished)) return;
}

I verified this against a stock 3.0.271 install with a real DB:

Scenario	Before	After
Unpublished clone aaa-1 renamed after 120s (this issue)	/aaa-1 recorded	nothing recorded
Published page renamed	recorded	recorded
Never-published clone renamed + published in one save	junk path recorded	nothing recorded
Previously-published page, temporarily unpublished, then renamed	recorded	recorded

The only edge case I can find: a page that was unpublished at the time SystemUpdate12 ran has published=NULL even if it was once live, so renaming it while still unpublished won't record its old path. That seems like an acceptable trade-off given how narrow it is (and publishing it again populates published, restoring normal behavior).

@matjazpotocnik for cleaning up existing junk entries, the same logic gives a safer criterion than matching -1 suffixes — delete history rows whose target page has never been published:

DELETE h FROM page_path_history h
JOIN pages p ON p.id=h.pages_id
WHERE p.published IS NULL;

[matjazpotocnik]

This is a useful partial fix for the normal UI workflow, but the “only edge case” claim is incomplete. I would also reject the blanket cleanup SQL.

The reported real-database tests support those four scenarios. My additional isolated checks against the local source expose two more:

• Publish, then rename in a separate save on the same Page object. The object can retain both published=0 and statusPrevious=unpublished. The proposed guard skips the later rename even though the previous path was published. statusPrevious does not prove that publication belongs to the current save.
• Rename an unpublished clone without reloading its Page object. It can still carry the original page’s publication timestamp, so the guard records the temporary path. This matters for API workflows once the minimum-age threshold is reached.

The acknowledged migration case is also a compatibility change. Maintainers could consciously accept that trade-off, but we should not describe it as backward compatible.

The cleanup query does not address the main accumulated-junk scenario:

Clone /aaa-1/ → rename /bbb/ → publish /bbb/

Once /bbb/ has been published, its database published value is non-NULL. The query therefore keeps the unwanted /aaa-1/ history. Meanwhile, it deletes all history for NULL-timestamp targets, including potentially legitimate legacy paths—not just clone-generated names.

My recommendation:

1. Present this guard as a partial fix, with the two additional API cases documented.
2. Add regression tests for those cases before proposing it as a general core solution.
3. Keep the reviewed cleanup script for existing entries; do not substitute the blanket DELETE.

[adrianbj]

Thanks @matjazpotocnik — I tested both of your API cases against a real 3.0.271 install and can confirm them, with one important wrinkle on the second.

Case 1 (publish, then rename, separate saves on the same object): confirmed. statusPrevious is only cleared in the Page constructor so it survives the publishing save, and published is never written back to the in-memory page — so the guard's second branch skips that rename. It's fixable precisely: Pages::saved fires immediately before renamed/moved and is the only hook handed this save's $changes array (the page's own change tracking is already reset by that point), so the module can require that status actually changed in the same save. Updated code below.

Case 2 (renaming a stale unpublished clone object): confirmed — but it's not a regression introduced by the guard. I ran that exact flow on stock, unpatched core: it already records a junk entry today, and a worse one than the temporary path. Because trackChange() sets namePrevious during the clone operation itself (to the source page's name), renaming a held clone object records the source page's live path against the clone's ID (/aaa → clone). The root cause is that _clone() leaves the in-memory copy claiming the source's published date while the copy's own DB row is NULL. One line in PagesEditor::_clone() fixes both the inconsistency and this case:

$copy->setQuietly('created', time());
$copy->setQuietly('modified', time());
$copy->setQuietly('published', 0); // copy has not itself been published yet

Updated guard in PagePathHistory, with the saved-hook addition:

// in init():
$this->pages->addHook('saved', $this, 'hookPageSaved');

/**
 * ID of page whose most recent save included a 'status' change, or 0 if none
 */
protected $statusChangedInSave = 0;

public function hookPageSaved(HookEvent $event) {
	$page = $event->arguments(0);
	$changes = $event->arguments(1);
	$this->statusChangedInSave = is_array($changes) && in_array('status', $changes) ? $page->id : 0;
}

// in hookPageMoved(), after the existing minimumAge guard:
if(!$page->published) {
	// page is still unpublished: its path has never been publicly viewable
	if($page->isUnpublished()) return;
	// page was unpublished and is being published by this same save, in which case
	// the DB 'published' date is now set but not yet reflected in $page->published
	if($this->statusChangedInSave === $page->id
		&& $page->statusPrevious && ($page->statusPrevious & Page::statusUnpublished)) return;
}

Re-verified all six scenarios on 3.0.271:

Scenario	Stock core	With v2 fix
Unpublished clone renamed after 120s (this issue)	junk /aaa-1 recorded	nothing recorded
Published page renamed	recorded	recorded
Never-published page renamed + published in one save	junk recorded	nothing recorded
Previously-published, temporarily unpublished, renamed	recorded	recorded
Your case 1: publish then rename, separate saves, same object	recorded	recorded
Your case 2: stale clone object renamed after 120s	junk recorded (source's live path!)	nothing recorded

On the cleanup SQL: agreed — it only removes rows whose target is still never published, so it doesn't touch the accumulated -1 junk for pages that were published afterwards, and a reviewed script is the right tool for existing data. One clarification though: the rows it does delete are inert, not "potentially legitimate" — the 404 hook only redirects when the target is viewable(), so history rows pointing at never-published pages produce no redirect today. They'd only ever matter if such a page were published later.

And agreed the SystemUpdate12 edge (pages unpublished at upgrade time keep published=NULL) is a behavior change worth a line in the release notes, even if the practical impact is close to nil.

[matjazpotocnik]

V2 fixes the separate-save case, but two problems remain. Separating the stale clone state into #2338 is appropriate.

1. The single $statusChangedInSave property can be overwritten by another page’s save.

   The sequence can be:

   Page A: saved hook sets the marker for first publication
   Another saved/savedPageOrField hook saves page B
   Page B: saved hook overwrites the marker
   Page A: renamed hook now records the temporary path
   

   saved precedes renamed, but other hooks and saves can run between them. Save-specific information cannot safely be represented by “the last page saved.”

2. Resetting the clone’s published property requires handling published clones too.

   API cloning can create a published copy. With the proposed reset, its database timestamp becomes populated while its in-memory value remains zero.

   If that same object is subsequently unpublished and renamed, the new guard skips history even though the copy previously had a published URL. The reset removes the source’s stale value, but does not ensure the returned object reflects the copy’s own persisted state.

I verified both counterexamples in isolated fixtures using the local source; these are not additional real-database tests.

The practical next step should be to fix #2338’s object consistency first: make the returned clone reflect its own publication state and resolve its inherited namePrevious. Resetting only published does not fix both properties.

Then #1024 can use publication information from before the particular save, associated with that page/save rather than a single module-wide marker. This avoids accumulating more exceptions around stale properties.

On cleanup, I agree that a never-published target normally produces no guest redirect today. But “inactive today” does not mean “safe to delete”: legitimate historical links can become useful again after republication, especially in the acknowledged legacy case. The reviewed cleanup remains the right approach.

Test harness: v2-guard.php. No core files or site data changed.