JTZL’s Bulletin for bbPress

Changelog

0.6.6

The change WordPress.org’s plugin review asked for, and testing against bbPress 2.6.19. Readers see the same pages, and one API route is removed.

• Removed: PATCH /me. Bulletin’s API no longer changes anything about a member’s account. An app changes a member’s display name through WordPress’s own POST /wp/v2/users/me, sending name alone, and reads GET /me as before.
• Changed: Bulletin is now tested against bbPress 2.6.19, the current stable release, and needed no change for it. One of bbPress’s own changes shows through: forum search no longer lists a reply whose thread has been deleted. bbPress 2.6.19 also stops WordPress’s embed feature from revealing the title and author of a thread in a private, hidden or password-protected forum, so updating bbPress is worthwhile.

0.6.5

The changes WordPress.org’s plugin review asked for. Readers see the same pages, and one API route gains a permission check.

• Changed: An app can change a member’s display name only if that member may edit their own profile on the website, the same check bbPress’s profile form makes. WordPress gives every member that permission unless a site takes it away, so most sites see no difference. Where it has been taken away, PATCH /me now answers 403 forbidden.
• Changed: Bulletin escapes its markup at the moment it prints it, and bbPress’s moderation and edit links are printed by bbPress itself. The pages are unchanged.
• Changed: Bulletin no longer edits WordPress’s head output to remove a theme’s viewport tag. It prints its own after that output instead, and a browser applies the last one, so screens lay out on a phone exactly as before.
• Changed: The stylesheet’s build settings moved from postcss.config.cjs into package.json, so the plugin package holds only file types WordPress.org accepts.

0.6.4

One fix for the current bbPress, and nothing an app has to change.

• Fixed: On bbPress 2.6.17, replying to a closed thread over the API answered with a generic 400 instead of the documented 403 forbidden. bbPress 2.6.17 checks whether you can read the thread before it checks whether the thread is closed, and a closed thread fails the first check for a member — so its handler reported “cannot read” where the contract promises “closed”. Bulletin now asks the closed rule itself, ahead of bbPress, so the answer is the same on every bbPress version.
• Changed: Bulletin is now tested against bbPress 2.6.17, the current stable release. Two of its changes show through as bbPress’s own rules: a public forum beneath a hidden forum is now closed to members (it always should have been), and bbPress no longer triggers WordPress’s seems_utf8 deprecation notice.

0.6.3

One rule corrected in the API. Nothing about the website changes.

• Changed: A moderator or keymaster can now edit their own topics and replies from an app, the way any member can. Until now the API refused them on every post, their own included, because editing was meant for members and moderation for the website — which left the forum’s own staff as the one group unable to fix a typo from a phone. Editing somebody else’s post is still not something an app can do; that remains a moderation action, and moderation stays on the website. As on the website, bbPress does not close the edit window on a moderator’s own posts.

0.6.2

One field the app team asked for, and a release zip WordPress.org’s own checker passes clean.

• Added: A forum now says whether the member reading it is subscribed to it, the way a thread already did. An app that subscribes a member to a forum can read that state back when it next loads the forum, instead of remembering it. Nothing about the website changes.
• Changed: The release zip passes WordPress.org’s Plugin Check with no errors and no warnings — template variable names, database query annotations and a plugin header that pointed at a folder that never existed. Nothing a reader or an app can see.

0.6.1

Three more things an app can ask for. All of them API-only: nothing about the website changes, and no new information is published that the site did not already publish.

• Added: A member can change their own display name from an app. Nothing else — not their email address, not their password. Those are credentials, and a route that changes them belongs behind a challenge Bulletin has no way to make.
• Added: A reply now knows where it sits in its thread, and a thread’s replies can be asked for around a particular one. An app can open a link to a reply directly on the right page, and say which reply of how many it is showing, instead of paging from the top to find out. An ordinary page of replies costs nothing extra for this.
• Added: A name can be resolved to a member. The search reads display names and profile slugs only — never email addresses, never login names — so it cannot be used to confirm whether an address has an account here. It returns a member’s name, avatar and profile slug, and it requires an account to ask, which is the one read in the API that does so without being about the member asking.

0.6.0

A second way in. Everything a member can do on Bulletin’s screens — read a forum, follow a thread, search it, take part in it — an app can now do over a REST API, under exactly the visibility, status, password and capability rules your website already applies. Nothing about the website itself changes.

• Added: A read API at /wp-json/jtzl-bulletin/v1/, covering one level of the forum tree, a single forum and its threads, a thread and its replies, a single reply, topic tags and a tag’s threads, search across forums, threads and replies together, and a member’s public profile. Collections page, report their true totals, and say plainly when a request falls outside them.
• Added: A member’s own state over the same API — who they are, their favourites, their subscriptions, and the read position behind the unread marks.
• Added: Writing over the API — starting a thread, replying to one, and editing your own post inside bbPress’s edit window. Each write is handed to bbPress’s own form handlers rather than reimplemented, so an app posts through the code path the website posts through: the same validation, the same flood check, the same spam handling, and the same held-for-review outcome, reported as such.
• Added: The API is authentication-agnostic. It reads whichever user WordPress has already resolved, so bearer-token login for an app comes from whichever provider you install; Bulletin issues no tokens and stores no keys of its own.
• Changed: A read position now records which reply it stopped at, not only when. Two replies posted in the same second no longer collapse into one position, so a thread can no longer be marked read past a reply the member has not been shown.

0.5.3

A way out. Opening a form to edit a post now offers the same way to change your mind that writing a new one always has.

• Fixed: The topic and reply edit forms had a Submit and nothing beside it, while the reply composer has always offered Cancel — two forms that look alike behaving differently. Editing now carries a Cancel that returns a member to the post they were editing, and the back control at the top of those screens goes there too, instead of to the forums index.

0.5.2

Two more places a member could not see what had just happened. Both were reachable the moment 0.5.1 made a composer easy to open.

• Fixed: Starting a thread put the cursor in the post body, past the title — the one field the forum will not accept a thread without. A member could write a whole post and be refused for a field they had never been shown. The cursor now starts where each form starts: the title on a new thread, the message on a reply, and the name field for a member posting without an account.
• Fixed: A reply held for review by someone posting without an account left them at the top of the thread, with “Your reply is awaiting review.” out of sight at the foot. Nothing else marks such a reply — no row, no badge, no profile to check — so from their side the post had simply vanished. They now land on the message.

0.5.1

Answering, without having to go looking for the form. Every way a member reaches a composer now puts it on the screen in front of them.

• Fixed: “Start a thread” opened the form at the foot of a long thread list, off the bottom of the screen. The control is fixed to the foot of the viewport and the form is not, so on a busy forum nothing appeared to happen and the button read as broken. Tapping it now moves the screen to the form.
• Fixed: A post the forum refused — an empty reply, a thread with no title — sent the member back to the top of the screen, with the reason and their own unsent draft out of sight at the foot. Both are now where they land.
• Fixed: The fixed “Start a thread” bar no longer sits over a form that is already open, where it offered a second time what the screen was already doing.

0.5.0

Reading, and answering. Bulletin has been somewhere to read a forum; it is now somewhere to take part in one. Replying, starting a thread and editing a post happen on Bulletin’s own screens rather than dropping a member onto your theme mid-sentence — and every list of forums or threads now says what is new since that member last looked.

• Added: Reply from the thread you are reading. The composer rests as a single “Write a reply” control at the foot of the thread and opens on tap, so an unopened form never sits between the last reply and the end of the screen.
• Added: Start a thread from the forum screen, in the same vocabulary as the reply composer, and only where bbPress would actually accept the topic.
• Added: Unread marks on the forums index, a forum’s threads, subscribed forums, and the bbPress screens Bulletin wraps. A thread is unread until that member opens it, and unread again when someone replies. Logged-out visitors see none of it, and nothing is stored for them.
• Added: A member can edit their own post from its byline, for as long as bbPress allows it. There is no mode to turn on first, and no control on a post that is not theirs.
• Added: A reply held for review is shown to its own author, marked as awaiting review, so it does not simply vanish on submission. Nobody else sees it.
• Added: The topic, reply and forum edit forms render inside Bulletin’s chrome instead of dropping to your theme.
• Changed: Amber means unread and nothing else. The notice on wrapped bbPress screens now carries Bulletin’s own caution colour instead of borrowing amber’s.
• Changed: A closed forum or thread says so, in the place the composer would have been.
• Changed: Takeover screens no longer load bbPress scripts they have no use for.
• Fixed: The previous/next bar no longer shows a position count on a pinned thread, where the number contradicted the order the reader had just scrolled past.
• Fixed: The author of a closed thread was offered a reply form that bbPress would then refuse.

0.4.0

One surface for every list. The bbPress screens Bulletin wraps rather than replaces were striping their rows while the reading screens were not, so a list of threads changed appearance one tap apart.

• Changed: List rows on member profiles, the topic archive, tag archives and registered views no longer alternate between two background tints. Every row sits on the same surface, and the divider between rows now reads at full strength on all of them — carrying the boundary the tint was kept for, the way the reading screens already did.
• Fixed: On the five member profile tabs, a row’s background and the divider under it stopped short of both screen edges. They run the full width now, like every other list in the plugin.

0.3.0

The complete forum surface. Bulletin no longer covers only the three reading screens — every bbPress screen a reader can reach now renders inside Bulletin’s chrome, so the forum stops changing character halfway through.

• Added: Search is a Bulletin screen, reachable from a magnifier in the app bar everywhere. Forums, threads and replies are interleaved by date, and each row says which of the three it is.
• Added: Threaded replies. With bbPress threading on, each reply is placed under the one it answers and carries a link back to it — an order, not an indent that runs out of width on a phone.
• Added: Member profiles and their tabs, the topic archive, tag archives and registered views now render inside Bulletin’s chrome instead of dropping to your theme.
• Added: Moderation is a mode on the reading view, off by default — a moderator turns it on, and everyone else never sees the controls.
• Added: A thread’s tags sit with the thread rather than in a separate strip.
• Added: A home button in the app bar, and the way back up is named instead of an unlabelled chevron.
• Added: Password-protected forums and threads keep the reader in Bulletin. WordPress’s own password form renders in place of the content until the password is supplied, and a protected post gives nothing away in a list row.
• Added: “Load more” for forum lists past bbPress’s 50-forum ceiling, for the thread list past its first page, and for the Subscribed Forums profile tab.
• Changed: One type scale across the whole plugin, replacing eighteen ad-hoc font sizes.
• Changed: Every touch target in bbPress’s own markup is at least 24px, meeting WCAG 2.2 target size, without moving a single row.
• Changed: bbPress’s forms — profile edit, moderation, and the login, register and lost-password shortcodes — are dressed to match the rest of Bulletin instead of sitting on browser defaults.
• Changed: The WordPress admin bar is hidden for everyone but administrators, so a logged-in reader gets the whole screen.
• Changed: Thread previous/next seeks the adjacent thread instead of listing every thread in the forum.
• Fixed: Reply and thread paging could duplicate or drop rows when two posts shared a timestamp.
• Fixed: Search could return private or hidden topics, and replies belonging to a topic the reader cannot read.
• Fixed: A closed thread now says it is closed, in search results as well as in lists.
• Fixed: Super stickies sit above forum stickies, and a forum-level sticky is no longer hoisted onto the topic archive.
• Fixed: A long screen title could set the width of the whole app, clipping the right edge of every screen — worst at 200% zoom, where it cut content.
• Fixed: The shell could be pushed out of position by anything that scrolls the page programmatically: a deep link, find-in-page, or assistive technology.
• Fixed: Each reply has its own permalink, on its timestamp, and it survives past the first page.
• Security: AJAX responses no longer let a restricted forum be told apart from one that does not exist.
• Security: Screen headings are escaped, and a continuation request is bounded to the page it answers for.

0.2.0

• Added: reading-view Subscribe control — subscribe to the thread you are reading, matching the native forum-level subscribe. Gated on active subscriptions and a logged-in user.

0.1.0

• Initial release: mobile reading layer for the forums index, single forum, and thread views.