Pros Blog Duplicate Posts

• 62 draft posts were created under the shared Axelerant author account (WordPress user ID 199) as an unintended by-product of content inspection.
• These surfaced as duplicate posts and were reported as causing B2B blog errors on the Pros blog.
• One published post was also present under the account; since the PADI engineering team holds the Author role only and cannot publish, that item did not originate from our side, and we are happy to help trace it.
• No legitimate published content was lost or altered — the impact is limited to surplus draft records that need to be removed.
• No site outage or availability impact; the Pros blog remained live throughout.

• ChainWhat led to this?
  The team needed to inspect field values and revision history on Pros-blog posts it does not have edit rights to. With Author-level access, the only way to view that data was WordPress's "Copy to New Draft" action.
• FailureWhat went wrong?
  WordPress persists a draft in the background as soon as "Copy to New Draft" is invoked, regardless of whether it is saved — contrary to the team's Drupal-based assumption. Inspecting ~10–15 posts silently created ~62 draft copies.
• AttributionWhy are they under the Axelerant account?
  The team shares a single Axelerant author account (WP user ID 199), so all activity traces to one ID. The one published post could not be ours, as the Author role cannot publish.
• ResolutionHow is it being fixed?
  The affected posts have been isolated by filtering on the author account (?author=199). The filtered list has been shared with the site admin to move the drafts to trash; alternatively we can complete cleanup directly if granted temporary admin access.
• PreventionWhat are we doing now?
  The team will no longer use "Copy to New Draft" on the live site; inspection moves to a local/staging copy. The behaviour is documented, and the issue class disappears once the Pros blog is migrated to Drupal.

• ~13 Jul — During author-landing-page investigation, the team uses "Copy to New Draft" on roughly 10–15 Pros-blog posts to inspect field values and revisions; WordPress creates background drafts (most affected drafts carry a 13 Jul last-modified date).
• 28 Jul — A further draft entry appears under the same account (~08:20 IST last-modified).
• 29 Jul — Sarah Morlock reports "Urgent: Duplicate Posts Causing B2B Blog Errors"; the email is forwarded and flagged in the team channel.
• 29 Jul — The team investigates; a database query finds 62 drafts and 1 published post under WordPress user ID 199.
• 29 Jul — Root cause confirmed as the "Copy to New Draft" background-draft behaviour; the author-filter workaround (?author=199) is identified to isolate the affected posts.
• Pending — Filtered list shared with the site admin to move the drafts to trash, or temporary admin access granted so the team can complete cleanup.

Dates are reconstructed from the investigation notes and post last-modified timestamps; exact times to be confirmed.

• Platform behaviour differed from the team's expectation: WordPress created drafts where Drupal would not.
• A content-mutating action was used for what was intended as read-only inspection on a live site.
• Least-privilege (Author-only) access left no non-mutating way to inspect the required data.
• The shared author account concentrated all activity — and the resulting drafts — under one ID.

• WorkedRoot cause was identified quickly once reported, and the affected posts were isolated cleanly via the author filter without touching legitimate content.
• WorkedNo legitimate published content was lost, and the single published item was correctly traced as not originating from the team.
• GapWordPress's background-draft behaviour was not known before the inspection was carried out on the live site.
• GapA shared author account and Author-only access complicated both attribution and self-service cleanup.

• CompletedIdentified the root cause and isolated the affected drafts using the author filter (?author=199).
• AgreedThe team will no longer use "Copy to New Draft" on the live client site; field and revision inspection moves to a local or staging copy.
• PlannedWhere inspection on production is unavoidable, request temporary read access to the specific data rather than duplicating content.
• PlannedComplete cleanup of the 62 drafts via the site admin, or with temporary admin access granted to the team.
• CompletedDocumented the WordPress background-draft behaviour in the Pros-blog working notes so the team does not repeat it.
• StructuralThe issue class is removed once the Pros blog is migrated off WordPress into Drupal, where duplication behaves as expected — migration is in progress.

• Platform behaviour differs: WordPress "Copy to New Draft" persists immediately — do not assume Drupal semantics on a WordPress site.
• Avoid content-mutating actions for read-only inspection on a live client site; use a local or staging copy instead.
• Shared accounts combined with least-privilege access complicate both attribution and cleanup — worth revisiting how the team accesses the Pros blog until migration.