Reorder, move, and delete pages

What this covers

The three operations that change the shape of the page tree:

  • Reorder: change the position of a page among its siblings.
  • Move: change a page's parent so it lives under a different branch.
  • Delete: remove a page along with its children and their attached files.

Reorder and move are routine; delete is irreversible without a backup. Each gets its own walkthrough below.

Walkthrough

Reorder pages within the same parent

The page tree on the left of the Pages module is drag-and-drop sortable.

  1. Click and hold the drag handle on the row you want to move (the small grip icon at the left edge of each row).
  2. Drag the row up or down past its siblings.
  3. Release.

The new order is sent to the server as soon as you release; you do not need to click Save. A small confirmation appears at the top of the tree.

The order is shared across all editors. Anyone who reloads the Pages module after your reorder sees the new order. The order also drives navigation: a theme that calls findActiveByParent visits pages in this sequence.

Move a page to a different parent

Two ways. Both work; pick the one that matches the distance of the move.

Small move (drop the page onto a different parent in the tree):

  1. Click and hold the drag handle on the row.
  2. Drag the row onto the row of the new parent. The new parent's row highlights when the drop will land there.
  3. Release.

The page is now a child of the new parent. Its URL changes from old-parent/this-page/ to new-parent/this-page/.

Long move (use the Parent dropdown in the form):

  1. Click the page in the tree to open its form.
  2. Change the Parent Page dropdown to the new parent.
  3. Click Save.

The form reloads with the new parent applied; the tree on the left updates. Use this when the new parent is too far away to drag comfortably, or when you want to make sure the move is the only change you commit.

Delete a page

  1. Open the page in the Pages module.
  2. Find the delete control (a button or a small icon next to Save, depending on the editor theme).
  3. Click delete. A confirmation dialog appears.
  4. Confirm.

The page is removed from the tree. Its children are removed with it (the deletion cascades down the subtree). Each removed page's attached files (everything under public/uploads/<categoryId>.<fieldId>.<itemId>/ for that page's id) is deleted alongside, including thumbnails.

The frontend returns 404 for every URL the deleted subtree used to serve. Anyone with cached navigation HTML or a bookmarked link gets the 404.

What to check after

  • After a reorder: the tree on the left shows the page at the position you dropped it.
  • After a move: the page form's Parent Page dropdown shows the new parent; the page's URL on the frontend reflects the new parent slug.
  • After a delete: the page no longer appears in the tree; visiting its old URL on the frontend returns 404; the public/uploads/<categoryId>.<fieldId>.<itemId>/ directory for that page is gone.

Troubleshooting

Drag-drop reorder seems to work, but reloads back to the old order

The reorder request failed to persist. Two common causes:

  1. CSRF token expired. A page-tree session that has been open for a long time may have a stale token. Reload the Pages module to get a fresh token, then reorder again.
  2. data/ directory not writable. The page order is persisted to the SQLite database under data/imanager.db; that file (and its WAL companion) need to be writable by the web server's user. chmod u+w data/imanager.db and the WAL files, then retry.

A page I moved still resolves at its old URL

Browser cache, or a reverse-proxy cache in front of your site. Hard-reload (Ctrl-Shift-R / Cmd-Shift-R); flush the proxy cache for the URL if you have one. The Scriptor side does not retain the old URL; once the move saves, the old URL is gone.

If you need both URLs to keep working (the moved page should also respond at its old path), set up a 301 redirect from the old URL to the new one using the Replace 404 with a fallback handler cookbook recipe.

I deleted the wrong page; how do I get it back?

There is no undo. Two options:

  1. Restore from backup. If you have a recent backup (see Backup and restore), restore data/imanager.db and public/uploads/ from it.
  2. Recreate the page by hand. If the backup is too old or you do not have one, recreate the page from memory: create a new page with the same name, slug, parent, and template; paste the content back in if you have it elsewhere (browser history, the cached version on a CDN, an email draft); re-upload the images.

The cascade rule (deleting a page deletes its children) makes this worse: a wrong delete on a top-level page can take dozens of descendants with it. Always confirm twice before deleting a page that has children.

Cannot delete a page; the delete button is missing

Two possible reasons:

  1. Permission. Editors with restricted roles may not have delete permission. Check with whoever set up the account, or see Users and access for the role basics.
  2. The page is referenced by config. A page hard-coded into scriptor-config.php as a special page (e.g. an error page) may have delete disabled to prevent breaking the site. Edit the config to remove the reference, then reload and try again.

See also