#3702 closed enhancement (fixed)
Add a site-wide open/closed forums status
| Reported by: | johnjamesjacoby | Owned by: | johnjamesjacoby |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.6.20 |
| Component: | API - Settings/Options | Version: | |
| Severity: | normal | Keywords: | |
| Cc: |
Description (last modified by )
Edit: after thinking about this more, this should be a site-wide open/closed forums status, not a temporary pause switch. Users should see that posting is closed, without any suggestion that the state is temporary or that reopening is promised.
bbPress already has open/closed states for individual forums and topics. Introduce a separate _bbp_forums_status option with open and closed as its initial values, defaulting to open for compatibility. This is an explicit site-wide policy: do not infer it from the statuses of individual forums, and do not write closed to every forum's or topic's stored status.
When the site-wide status is closed, reuse the existing closed-forum and closed-topic notices where appropriate, and reject new topic and reply submissions server-side. Form-access checks alone are insufficient. Cover every supported creation path, including front-end forms and direct requests, WordPress admin, REST, XML-RPC, and topics without a forum. The site-wide check must not depend on a forum ID being present, and must not be bypassed by posting capabilities that normally allow content in an individually closed forum. When the status is open, existing per-forum, per-topic, and capability rules continue to apply.
Keep forum creation and existing forum relationships independent of this posting status. In particular, BuddyPress should continue creating and associating group forums while site-wide posting is closed, so those forums already exist if the status later changes to open. Existing content should remain intact. Whether editing existing topics and replies belongs to a broader read-only policy is a separate decision.
Acceptance criteria:
- The default
openvalue preserves current behavior. closedprevents new topics and replies through every supported user-submission path, for anonymous and logged-in users, including forum-less topics and BuddyPress group forums. A custom theme rendering a form cannot bypass the check.- User-facing templates show an appropriate existing closed notice without changing the literal stored status of any forum or topic.
- Forum creation and BuddyPress group-forum provisioning still work; no existing content or per-object status is changed.
- Returning to
openrestores posting only where existing object-level and capability checks permit it. - Add focused regression tests across submission paths, no-forum topics, and BuddyPress provisioning.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
I think the site-wide
closedstate should preserve the capability exceptions that already apply to individually closed forums and topics. Keymasters and appropriately scoped moderators can still post; a forum moderator's exception applies only to forums they moderate. The current description's statement that posting capabilities must not bypassclosed, and its blanket prohibition for all logged-in users, are too strict.I propose adding
frozennow as a third value of_bbp_forums_status:open,closed, andfrozen. Unlikeclosed,frozenwould be a hard stop on creating new forums, topics, or replies regardless of role or entry point, including BuddyPress Group Forum provisioning. Front-end submissions, WordPress admin, REST, XML-RPC, and other supported creation paths should agree. This could be useful on our own multisite forums. The state should not rewrite individual forum or topic statuses or remove existing content.The Settings description should make the distinction explicit:
closedrestricts ordinary posting while retaining moderator and Keymaster exceptions and allowing group forums to be created;frozenprevents all new forum content, including new BuddyPress Group Forums. Whetherfrozenalso prevents edits to existing content should be decided explicitly before implementation.