social-groups v2.4.4

Improvement

• Fully translatable. Every user-facing string now goes through the translator — 48 new locale keys covering the share modal, reaction labels, upload/save errors, and every backend error message (invites, polls, media, join requests, member roles, sharing). Translation packs can now localize the extension completely; nothing is hardcoded English anymore.

No behavior changes. Update:

php flarum cache:clear```

**Full Changelog**: https://github.com/ernestdefoe/social-groups/compare/v2.4.3...v2.4.4

[View release on GitHub](https://github.com/ernestdefoe/social-groups/releases/tag/v2.4.4)

social-groups v2.4.5

Fixed

• User-card Controls menu unreadable on the default Flarum theme. The extension globally aliased core's --text-color CSS variable to --body-color, a variable that only exists in certain themes. On stock Flarum this made every core color: var(--text-color) invalid, so the profile-page Controls dropdown inherited the hero's white text — white on a white menu. The alias is removed; the menu (and anything else that reads --text-color) renders correctly on every theme. Thanks to the user who reported this with screenshots.
• Guests on login-restricted forums no longer see public group names/descriptions they can't actually open: the groups listing now honors the same viewForum gate as the rest of the extension.
• Friendlier permission errors in the group feed. A denied feed load now shows a lock panel (with a Log In button for guests) instead of a raw "You do not have permission" toast.
• Two stray hardcoded English strings (user-card "Groups" label, feed search empty-state) now go through the translator.

Update

php flarum cache:clear```

[View release on GitHub](https://github.com/ernestdefoe/social-groups/releases/tag/v2.4.5)

social-groups v2.4.6

Fixed

Follow-up to v2.4.5 for forums on the default Flarum theme:

• Profile Group Badge tiles were unreadable — the tiles have an opaque light background but inherited the user-card hero's white text color. Tile labels now always use the theme's text color.
• The selected tile went see-through, letting the hero color bleed through it. It now stays opaque under its blue highlight tint.
• "GROUPS", the help text, and the empty/saving states rendered in muted gray directly on the colored hero. They now inherit the hero's contrast color, so they're legible over any profile color, light or dark.

Update

php flarum cache:clear```

[View release on GitHub](https://github.com/ernestdefoe/social-groups/releases/tag/v2.4.6)

social-groups v2.4.7

Fixed

Regular members and group creators got a 403 ("You do not have permission to perform this action") when starting a new discussion in a group — only site administrators could create them. Replies to existing threads were unaffected.

Root cause: the discussion Create endpoint carried a ->can('create') gate, but at create time there is no model for Flarum's gate to hand to the extension's policy — the check ran against nothing, skipped the policy entirely, and fell back to core's admins-only default. The endpoint now relies on the extension's real authorization (the member / owner / moderator check that runs during creation and always has), which is the same pattern the reply endpoint uses.

No admin configuration is needed — group members and creators have always been intended to have this permission by default; the gate ordering just made the check unreachable. Verified both ways: a plain member of a group can create a discussion (201), a non-member still cannot (403).

Update

php flarum cache:clear```

[View release on GitHub](https://github.com/ernestdefoe/social-groups/releases/tag/v2.4.7)

social-groups v2.4.8

Fixed

• Group notifications never actually delivered — now they do. Flarum 2's alert driver only handles notification blueprints that implement AlertableInterface; ours didn't, so the new-post and new-reply notifications silently reached no one. All notification types now deliver.
• Rejoin after leaving an approval-gated group works properly. Leaving a group now clears your join-request history, and a stale approved/denied request no longer swallows a new one — previously the UI said "pending review" while no request (and no notification) ever reached the group's managers. Thanks to the user who reported this.

New

• Join-request alerts — the group's creator and moderators get a notification (with a per-user toggle in notification settings) whenever someone asks to join an approval-gated group.
• Mute members — group creators and moderators can mute a member from the member list: they stay in the group and can read everything, but can't post or reply until unmuted. The composer is replaced with a clear notice for muted members (nothing errors on submit), and a Muted badge shows managers who's restricted.
• Primary group on posts — forums running fof/badges now show the author's primary social-group image chip in post headers, linking to the group. Private groups stay hidden from non-members; the data rides on the existing user payload, so there are no extra requests.
• Groups on profiles — a new Groups item in the profile sidebar lists every group a member created or joined (/u/{username}/groups).
• Group discovery — directory cards now tease each group's two most recently active discussions, so visitors see real conversations without opening every group.

Update

php flarum migrate
php flarum cache:clear```

[View release on GitHub](https://github.com/ernestdefoe/social-groups/releases/tag/v2.4.8)

social-groups v2.4.9

Fixed

Hotfix for two v2.4.8 issues — update straight past v2.4.8 if you haven't already:

• The notification dropdown rendered empty when a Social Groups notification was present. Flarum 2 requires notification components to implement excerpt(); ours didn't, which crashed the list render. All three notification types display correctly now, and they also appear in Settings → Notifications with per-user toggles.
• Raw translation keys showed in group pages (tab labels, member-list messages, the RSS link) — a locale-file nesting mistake in v2.4.8. All strings render again.

Update

php flarum cache:clear```

[View release on GitHub](https://github.com/ernestdefoe/social-groups/releases/tag/v2.4.9)

social-groups v2.4.11

Performance & conventions audit batch — no behaviour change, all query hygiene.

Fixed

• Post-header primary-group chip no longer N+1s. sgPrimaryGroup moved into an injected UserResourceFields class and its relations are eager-loaded on the User/Post/Discussion endpoints (mirroring core's user.groups), so a 20-author page no longer fires ~60 correlated lookups.
• Group directory teasers batch-load. recentDiscussions reads an eager-loaded relation instead of one LIMIT query per group card.
• Member list canRemove/canMute memoized. The per-(actor, group) moderator lookup runs once per page instead of 40 correlated subqueries; endpoint policies are unchanged.
• Poll voting eager-loads the discussion's group (one fewer SELECT).
• Migrations 000003/000020 now document why the raw closure form is intentional.

Update: composer update ernestdefoe/social-groups then php flarum cache:clear.

View release on GitHub

Logged. Here's a consolidated tracker of the Social Groups issues reported by @flavour1 (latest against v2.3.67 / Flarum 2.0.0-rc.3), so nothing gets lost:

Permissions / visibility

1. Guests could read group discussions despite members-only permissions — reported fixed in v2.3.67 (restricted access now works as expected).
2. Opening a /groups/… URL as a guest now shows "Failed to load group." plus a "The requested resource was not found." error modal. Behavior is correct, but the modal is noisy and should be suppressed for the not-authorized/not-found case.

Posting & replies

3. Replying to a group post fails: 403 on social-group-posts with "You do not have permission to do that." — even though the admin Permissions table only exposes Create Social Groups and Edit & delete any social group, with no per-group "reply" permission surfaced. Standard discussion replies work fine.
4. Editing posts as an admin fails (Failed to save edit. / "You do not have permission to do that."); only whole-discussion deletion is available.

Composer / editor

5. No TextEditor formatting controls render in the group composer footer — only third-party buttons (fof/upload, fof/polls) appear.
6. The SGFeed composer area isn't auto-sizing: pasting enough content to fill the box makes it uneditable.

Content rendering

7. Links/image URLs that should embed don't render on submit — a full page reload is required to display them.
8. Images uploaded via fof/upload don't appear in the SGMedia tab.
9. SGMedia lightbox author link opens an auto-generated gallery discussion; inside it the edit textarea sizes dynamically, but editing/replying fail with "Failed to save edit." / "You do not have permission to do that."

@ernestdefoe already flagged he'll dig into these this weekend, and is looking at whether embed support can be added. @flavour1 — if you can share the exact fof/upload and fof/polls versions alongside Social Groups v2.3.67, that'll help isolate the composer-controls and 403 reply issues.