Download the PHP package edwilde/silverstripe-legacy-versioned-repair without Composer

Legacy Versioned Repair

Repairs SilverStripe 3/4-era folders that SilverStripe CMS 6 misclassifies as "archived", which blocks creating files and sub-folders inside them for every user, including administrators. In practice this means users cannot upload new files or create sub-folders inside an affected folder, even as an administrator: the "Create folder" button briefly shows a spinner and then reverts with no error message, and new uploads never complete. Replacing an existing file still works, which is often the tell that a site is hitting this.

Related upstream issue: silverstripe/silverstripe-asset-admin#1689.

The problem

Folders migrated from SilverStripe 3 or 4 can have File.Version = 0 and no File_Live row. CMS 5 never consulted versioning state when creating files, but CMS 6 does: Hierarchy::canCreate() calls $parent->canAddChildren(), which calls Versioned::isArchived(). isArchived() reads isOnDraft(), and isOnDraft() treats the stage row's Version number as a boolean. A row with Version = 0 therefore reads as "not on draft", and with no live row the folder is deemed archived, so adding children is refused.

The folder looks normal but cannot have files or sub-folders created inside it. Because the check runs before the usual admin permission bypass, even administrators are blocked.

Requirements

• SilverStripe CMS 6 (silverstripe/framework ^6.1, silverstripe/assets ^3.1, silverstripe/versioned ^3.1)
• symbiote/silverstripe-queuedjobs ^6.1

Installation

Usage

The task is a dry run by default and only reports how many folders are affected.

Dry run:

Alternatively, open the task URL while signed in as an administrator:

To queue the repair, pass --confirm (CLI) or ?confirm=1 (HTTP):

This queues a single RepairLegacyFolderVersionsJob on the normal queue, which every install processes. The job repairs a small chunk of folders on each process() call and resumes itself until none remain, so it is safe for large sites: it parks as Waiting between chunks rather than exhausting worker memory. Watch progress in the Jobs admin at /admin/queuedjobs. Re-running the dry run afterwards should report zero.

The task is idempotent and safe to run more than once. Clicking confirm again while a job is queued or running does not create a duplicate.

How the repair works

Each affected folder is force-written with no field changes. The write is performed on the live stage: Versioned::augmentWrite() writes both the draft and live rows, bumping the version off zero and creating the live row, which un-archives the folder. Folder::updateChildFilesystem() early-returns on the live stage, so the recursive child-write cascade never fires. A draft write would recurse into every descendant file and folder, which on a near-root folder can exhaust worker memory and needlessly republish child files.

Only folders are repaired. Plain files inherit their permission and versioning behaviour differently and are not affected by this issue.

Configuration

The job runs on the normal queue by default. On a large site that runs a dedicated large-queue processor, move it to that queue so the long repair does not tie up the normal-queue worker:

This is one-shot tooling. Once the repair has run you can disable both the task and the job, which removes the task from /dev/tasks and makes any queued job a no-op:

Licence

BSD-3-Clause. See LICENSE.