Delete a space without destroying the conversation

When you delete a space in Jetonomy, the default is not to delete it. The space is archived and handed to a successor, and every topic and reply stays exactly where it was, readable and linkable. Permanent deletion exists, but it is a separate action that you have to choose on purpose, and on most communities only a site administrator can reach it.

Everything else in this post follows from that default. Spaces are not the owner’s property in the way a draft is. They are a pile of other people’s questions, answers and arguments, and some of it is probably still being found through search. Removing the container removes all of that, and nobody asked the people who wrote it.

Below is how the two paths work, who is allowed to use each, what happens on a very large space, and a short routine for retiring a space without regret. Everything here is in the free plugin.

Why the default is archive, not delete

Think about the spaces that tend to outlive their usefulness. A beta group closes. Product lines get retired. Seasonal events end. After two years, the volunteer who ran a space steps away and nobody wants to take the keys. In every one of those cases the space is finished, but the conversation inside it is not worthless.

Support threads from a retired product still answer questions for the people who bought it. Year-old event discussions are a record of what worked. Once the space goes, those links return an error and the knowledge goes with them.

So Jetonomy treats a delete request as a request to park the space. The owner clicks the button, the space is archived, ownership moves to someone who can look after it, and the owner stays on in a lesser role. Nothing a member wrote is touched.

What archiving actually does

Be precise about this, because the word “transfer” suggests more than it does. Archiving does not move topics anywhere. There is no destination space, and no content is copied or relocated. Topics and replies stay in the space they were written in.

Two things change:

• The space’s status becomes Archived. Members can still read it and follow links into it, but new topics and replies are refused. A member who tries to post is told the space is archived or locked and no longer accepts new content.
• Ownership passes to a successor. Demoted to moderator of that space, the former owner keeps some standing but no longer holds the top role.

An archived public space stays public. To get it out of sight as well as closed to new posts, change its visibility separately. Archiving is about stopping activity, not about hiding history. The space status documentation covers how Active, Archived and Locked compare.

Keeping the two apart is useful: archive a space today and decide next quarter whether it should also go private. Neither step is a one-way door.

Who inherits the space

Ownership has to land on someone, and Jetonomy picks the person with a fixed rule rather than guessing.

First in line is a surviving admin of that space: the one who joined earliest, with the lower user ID breaking a tie. They already hold the admin role, so the space keeps working with no extra setup. With no other admin in the space, the fallback is the site administrator with the lowest user ID. Anyone who is banned from the site or from that space is skipped, and so is the owner who is leaving.

When nobody qualifies, the transfer is refused with a conflict error. The message says that no one else can take over the space and that an administrator must delete it permanently instead. Refusing here is a feature: Jetonomy will not archive a space into the hands of nobody.

On the front end the logic goes one step further. The Archive and hand over button only appears when a successor exists, because a button that can only fail is worse than no button. Underneath, the description even names the member who would take over, so the owner sees who is getting the space before they confirm.

Only the space’s owner or a site administrator can start a hand-over. Other space admins cannot. It is deliberate, because without it ownership could bounce between several admins of the same space.

Who can do what, and where

You can reach the same two actions in three places, and the rules are identical in each because they all go through the same code.

• On the front end, the Edit space page ends with a Danger zone, kept outside the form so a stray Enter key in a text field can never trigger it.
• In wp-admin, the Spaces list has an Archive link and a separate Delete permanently link on each row.
• Through the REST API, DELETE /spaces/{id} takes a mode parameter that is either transfer or purge. If you leave it out, it is transfer.

Hand-over needs the owner or a site administrator, as above. Permanent deletion is stricter than it first looks. Site administrators can always do it. A space admin can do it only if the site owner has switched on a setting, and that setting is off by default.

You will find it under Jetonomy, Settings, Permissions, in a row labelled Deleting spaces. The checkbox reads “Let space admins permanently delete their space and everything in it”. Beside it, a description gives the reasoning in the plugin’s own words: a space holds topics and replies written by other members, so destroying it destroys their contributions too.

Enforcement sits in the API, not only in the interface. A space admin who sends mode=purge directly to the route without permission gets a 403, whatever the screen did or did not show. And the front-end Danger zone only draws the permanent delete button for people who would actually be allowed to use it.

Running a community with volunteer space leads? Leave that setting off. They can still retire their own space by archiving it, which is nearly always what they wanted anyway.

When you really do mean delete

There are good reasons to remove a space for good. It might be a test space nobody needs, a duplicate created by mistake, or a space full of spam that you have no wish to keep. For those, permanent delete is the right tool and Jetonomy does not get in your way beyond making you ask for it.

On the front end you have to type the space’s title to confirm. There is no dialog to click past. The button is styled as a destructive action and sits in its own row below the hand-over option, so the two never look like equivalent choices.

What it removes is everything the space owns: its topics and replies, its memberships and join requests, and the votes, flags, attachments and subscriptions that hang off them. The plugin keeps a single declared map of how a space is referenced across its tables, and the purge, the orphan check and the report of what a purge would remove all read from that one map. It matters because a hand-kept list is exactly how rows get left behind.

After a purge, the post and reply totals for members who had content in that space are recounted, so profiles and leaderboards do not keep crediting people for topics that no longer exist.

One honest limit: it cannot be undone. There is no trash and no restore. When in doubt, archive first. You can come back and purge a space that is already archived, and a few weeks of waiting costs you nothing.

What happens to a very large space

Fifty thousand topics cannot be deleted inside one web request, and Jetonomy does not pretend otherwise.

Simple rule: if the space has up to 500 topics, the whole thing is deleted before the response is sent, so the next page you load shows the truth. Larger than that, the plugin locks the space first so members stop posting into something that is being removed, deletes the first batch in the same request, and queues the rest with Action Scheduler. REST answers 202 instead of 200 to tell you the job has been accepted and is still running.

Two design choices make this safe to interrupt:

• Deleting the space row comes last. Everything inside it goes first, and the space itself disappears only when it is empty. If the job stops halfway, because a server restarts or a database call fails, the space is still there to be found and finished.
• A failed batch retries a minute later. A database error stops that pass with the space intact, so a bad read cannot leave replies pointing at a space that no longer exists.

On a host that never runs Action Scheduler jobs, the first batch still runs inline, so progress is made regardless. And if you ever find rows left over from an old purge, WP-CLI has a command for that: wp jetonomy space purge-orphans, with a --dry-run option to see what it would remove first.

For you as the owner, the practical advice is easy. Do not delete a huge space at the start of a busy day, and expect it to show as locked for a while. Check back after the queue has run.

The same choice from WP-CLI

From the terminal, the command is wp jetonomy space delete <id>, and it takes the same --mode flag with the same default.

• wp jetonomy space delete 5 archives space 5 and hands it over, keeping every topic and reply.
• wp jetonomy space delete 5 --mode=purge permanently destroys it, and asks you to confirm first. Add --yes to skip the prompt in a script.

Keep that prompt in anything you run by hand. The WP-CLI reference lists the other space commands, and the front-end editing guide walks through the Danger zone screen by screen.

A routine for retiring a space

To close a space, this order keeps your options open for as long as possible.

1. Say it is closing. Post a pinned announcement in the space with the date and the reason. Members like a goodbye more than a disappearance.
2. Check there is a successor. Make sure another member is an admin of that space, or accept that the lowest-numbered site administrator will inherit it.
3. Archive and hand over. This is the step that stops new posts and moves ownership. The former owner stays on as moderator.
4. Decide about visibility. If the content should stay findable, leave the space public. If it should not, change its visibility as well.
5. Wait. Give it a month. Watch whether anyone still lands on it from search or from a link in an old email.
6. Only then consider a purge, and only if the content is genuinely worthless or must go.

Changed your mind after step 3? The new owner can unarchive from the Danger zone, and a site administrator can reopen the space from the Spaces screen in wp-admin. Only an archive as the first move makes that safety net possible.

Where this fits in a community you plan to keep

Communities change shape. Spaces that made sense at launch are not always the ones you need two years in, and a clean way to retire them is part of running one for the long haul. While you are still planning your structure, the guide on choosing a space type is a good place to start, and the spaces and categories feature page shows what you can build.

When your members mostly follow along by email, the earlier post on reply by email, a digest and push covers how they hear about activity in the spaces that remain.

The short version is this. Archive and hand over is the default because it costs nothing and loses nothing. Permanent delete is there for the rare case where the content has to go, and you have to ask for it twice: once in a setting, and once by typing the name. It is the right amount of friction for a button that removes other people’s words.