More elegant handling of site 'archive' options for MultiSite

[Ipstenu]

Right now you have a few options with MultiSite blogs

1) Spam
2) Deactivate
3) Archive
4) Delete

Spam is easy to understand, and should be marking the admin and site as spam. Delete ditto, hi.

Deactivate and Archive are weird though and almost seem backwards. Deactivate means to turn OFF (like deactivating a plugin). Archive implies that you're making a site read-only.

Right now, if you change a site to 'deactivated' it actually shows up as DELETED and the front end has the message "This user has elected to delete their account and the content is no longer available." Clearly the verbage on the network/sites.php page needs to be updated (and perhaps the front end to 'This site has been deactivated.' to be consistant).

If you 'Archive' a site it kicks it to a paler pink in the sites.php page (though the 'Archived' text is white and nigh impossible for me to read) and the front end says "This site has been archived or suspended."

It's rather illogical there. Archive SOUNDS like it should be making things read-only (and turning off commenting and posting if possible). Otherwise it should just be 'Suspend', and at that point, why have two options that pretty much do the same thing from the front-end perspective?

[duck_]

Related #15801.

Basically a dupe on delete/deactivate trouble, but not archive.

[scribu]

+1 on merging Deactivate and Archive.

[Ipstenu]

Either merge or make distinctly separate functionally.

Having a way to flag a site as 'archived' where it's there, but read only, is probably plugin territory, but I can see as useful. Deactivate/mark as spam/archive is just all overkill for the same effect right now.

[archonic]

Hope this gets approved! Would ultimately like "public" in the sites context to be renamed to something more descriptive like "crawl-able". Agree on archiving keeping the site visible by the public but lock the backend to all but the super-admin.

[jazbek]

+1 for ipstenu's suggestion for Archive functionality. Would be awesome to be able to make an old/inactive site read-only. Statically caching it somehow would be amazing, though not sure that is core territory, so an archive hook would be useful (there may be one already, didn't check).

[Kent Brockman]

Will this ticket bring attention of some dev? any possibility to upgrade version number to 3.8? or is 3.1 the version when request was first noticed?

[Ipstenu]

Version number is for when the problem first arose, not for what version we fix it in :) Milestone will be set to a version if we get there.

[leedman]

Additions to Site Management

Bulk Actions - Add Activate and other options so multiple blogs can be selected and qeued and processed.

Filters - Allow the user to view only the Active sites, Inactive Sites, etc., via Filter box option.

Sort - During an overview, Sorting on Blog Status would also be useful.

[melchoyce]

@jeremyfelt @flixos90 @johnjamesjacoby @spacedmonkey Curious what your thoughts are as component maintainers. I don't have a lot of multisite experience, but @Ipstenu's suggestions make sense to me.

[flixos90]

I agree that at least the verbiage should be changed. Related ticket is #39158 (though it is more about a bug in the functionality).

Adjusting the behavior of what archiving vs deactivating does, I'm not sure that can be changed due to previous expectations that might exist. But we should certainly consider it and investigate possibilities.

[johnjamesjacoby]

In my opinion, also related are #36492, #12706.

---

For this ticket specifically, should be update the verbiage? Probably, yes. Though it'll be difficult to change their functionalities because of how deeply these are integrated into WordPress.com, Jetpack, and other open multisite networks.

---

For WordPress in general, deeper scrutiny should be considered. See my comment here: https://core.trac.wordpress.org/ticket/12706#comment:211

These links currently map to several unique columns in the wp_blogs global database table:

public, archived, mature, spam, deleted

My preference would be to consolidate these columns down to 1 status column, with an API to help define what those statuses are and what they mean within the system.

Then these row-action links can be driven by their defined statuses rather than the literal database schema. The added cardinality of an indexed, string-based status column should improve query performance over the multiple numerical columns, too.

[boemedia]

We discussed this ticket in today's design triage. We agree with @johnjamesjacoby that a separate status column would work. This way it's possible to filter and for instance, only see active sites or sites that are archived.

Besides that, the colour status seems a bit much, maybe we can work with icons in the status column instead?

We also think the different statuses could benefit from more clarification. What's the difference between deactivating and archiving a site? We think of clarifying on 2 levels: possible an info button next to the status column and extra info after changing a status. See attached screenshots as well.

[boemedia]

Separate status column in multisite dashboard

[boemedia]

Extra info could be added to the screen that shows before final confirmation

[boemedia]

More guidance before changing status multisite would give a better UX

[richardkrone]

I had placed a ticket https://core.trac.wordpress.org/ticket/56076 about the same issue. Recently, someone directed me to this ticket.

I hope that updates to the UI and the text semantics becomes a reality, as the multisite functionally feels like the ugly stepchild sometimes.