Explore support for a “Retired” site status in Multisite networks

[lloc]

Inspired by Trac ticket #63378, I’d like to open a discussion on whether MultiSyde should experiment with or prototype support for a “Retired” site status within WordPress Multisite networks.

The proposed “Retired” status refers to sites that:

• Should remain publicly accessible
• Should not allow new posts, pages, uploads, or comments (except possibly by admins)
• Might display a banner or indicator in both front-end and admin views
• Might show up differently in the Network Admin site list
• Could trigger optimizations like reduced cron jobs

While WordPress core already includes flags like archived, deleted, and mature, the proposed “retired” status is conceptually different. The mature flag is rarely surfaced in the UI and is typically used to flag inappropriate content. Using it to mean “read-only and inactive” may be misleading.

Some possible next steps:

• Experiment with custom site meta to simulate a “retired” flag
• Explore conditional UI changes in MultiSyde’s interface (e.g. badges, filters)
• Discuss whether this concept fits within the scope of MultiSyde
• Evaluate if this could be part of the plugin or upstream proposal

Questions for discussion:

• Should MultiSyde implement a “Retired” site flag (using wp_blogmeta)?
• What would be a minimal but useful implementation (e.g. just a UI indicator)?
• Are there existing filters or hooks where this could be surfaced?

Let’s gather thoughts before moving forward with any implementation. Happy to hear your opinions!

[Zodiac1978]

The mature flag is rarely surfaced in the UI and is typically used to flag inappropriate content.

No and yes. It is meant to flag inappropriate content for non adults. This status is there for filtering for it, so you can hide adult content from public lists. This is the idea behind this flag on WordPress.COM where this idea originates.

[lloc]

I just implemented the first part of this feature, which focuses on the UX for the Network Admin.

A few lessons learned along the way:

• The site attributes (spam, archived, mature, deleted) are fixed in the form. Since there’s no filter available in that section, the retired state had to be implemented separately, as shown here:

• On the other hand, the implementation for the Sites list table is much more straightforward. It integrates nicely with the existing UI and seems to work well:

Next steps / Discussion

For a “Retired” site status to be truly useful, it should also change behavior across the network. Some open questions to discuss:

• Read-only mode: How strict should it be?
  • Block post/page edits and publishing
  • Disable media uploads
  • Prevent plugin/theme changes
  • Lock down options/settings
  • REST API: allow only safe methods (GET/HEAD/OPTIONS)
  • Comment submissions (front end)
  • Scheduled tasks: Should cron be disabled or short-circuited for retired sites?
  • Visibility: Should retired sites show a front-end banner or message (for logged-in users) indicating the status?

[InpsydeNiklas]

Restricting all non-Super Admin capabilities would cover most, but not all of the discussion points mentioned above.
Here's a breakdown on what could be limited only by restricting the capabilities for users interacting with the site: https://wordpress.org/documentation/article/roles-and-capabilities/#administrator

Basically, what could be covered by removing/restricting capabilities:

• Block post/page edits and publishing
• Disable media uploads
• Prevent plugin/theme changes
• Lock down options/settings

What would not be covered by removing capabilities:

• REST API: allow only safe methods (GET/HEAD/OPTIONS)
• Comment submissions (front end)
• Scheduled tasks: Should cron be disabled or short-circuited for retired sites?

Additional considerations that might also want to be handled:

• Form submissions (Contact Form 7, Gravity Forms, etc.)
• WooCommerce orders/cart functionality
• Custom post type capabilities
• Third-party plugin actions that bypass standard capabilities

Removing capabilities could act as a foundation, but additional filters/actions would still be needed for a complete "read-only mode", especially for REST API, comments, cron, and other third-party extensions.

Visibility: Should retired sites show a front-end banner or message (for logged-in users) indicating the status?

I would prefer not to have retired sites introduce any new frontend components by default. If they add an unwanted banner, then there would also need to be ways (i.e. admin UI) to get rid of it. If somebody wanted to display some permanent information, it should be a rather trivial effort to, e.g., add a CSS-only banner before retiring the site.