Community announcement

Week Nine Site Updates

Myth-Weavers · posted by Eric · September 27, 2026

There have been 169 changes since the last update.

Of these changes, 21 bugs were triaged and fixed, with most of them being reported by community members. Keep up the good work! The rest of the work has gone into infrastructure changes and behind-the-scenes work to keep the transition to Idunn rolling. And while progress continues on that front, we’d like to take a good chunk of this update to talk about how we handle feature requests, the process behind them, and what we can do better.

Feature Requests Are Getting A Dedicated Lane

As of this announcement, there are 124 open feature requests. We love seeing the feature requests come in as they show your involvement and desire to improve the site. The downside is that the requests have been arriving faster than we’ve been closing them, making it seem we’ve been ignoring your requests as they linger.

Before the move to Idunn, we had a more active approach in resolving feature requests. Every request we could reasonably implement was slotted into development and finished prior to the final cutover. Comparing this to September alone, we received 31 feature requests but were only able to implement 4 of them. We didn’t anticipate the sheer volume of requests, which resulted in a good number of them hanging out in “development limbo” with no clear path to completion.

To help understand the issue, here’s a little peek behind the curtain. We deliberately only work on three “projects” at a time. This gives us a hard limit of development “slots” to focus on so that things get finished instead of everything moving slowly (Kanban, for those of you in the project management world). Since cutover, the items that were prioritized were drawn from the “keep the site operating on stable financial footing” list. Bug reports and support questions got worked on as they arrived without waiting for a project slot. The obvious downside is this left features (new capabilities you’ve asked for) as the last rung on the ladder to be completed on an “as available” basis, causing them to accumulate solely by nature of not having a dedicated time slot for them.

What we have decided to do going forward is to dedicate one of our three project slots to work on a “theme” of feature requests. This will leave the other two “slots” for our infrastructure work to compete over and leave a third of our dedicated development time to implementing your requested features! (As the infrastructure work draws down, we aim to flip this to 2-to-1 for features, but that’s another story for another day.)

We have grouped similar feature requests into “themes” to knock multiple requests out as one, more coherent update. This allows us to work on them as batches instead of scheduling a single request against hundreds of others. The “slot” for this just opened up as we completed a project Friday that allows us to start working on our first “Feature Theme” right away!

The first targeted feature theme is “Notifications and Unread state”, with the following goals:

Unread state showing up where you actually look for it and it updating without you reloading the page
The notification bell will list all of your notifications instead of stopping at 20.
Notifications will give you enough to distinguish between two similarly-named topics
You’ll be able to mark everything read in one action

These features will address six open requests while benefitting everyone using the site.

To be transparent, we will be filtering what requested features are included in a theme update. Some requests require more time to complete, or wouldn’t fit with the other parts being updated. As an example, take the feature request: “Who’s currently posting in this game”. This request notionally sounds like notifications; however, it requires us to add live presence tracking, making it plausibly a bigger piece of work than the other items put together. Including it would have meant the theme update couldn’t be rolled out until the largest item was completed.

Similarly, we moved two other related requests to themes that fit them better: one is more of a staff work queue rather than a notification; and the other is about triggering notifications from a character mentions rather than just seeing post notifications or direct user mentions.

We can’t put dates on these feature themes will complete, but we will always tell you which theme is active, and which one we’re thinking of doing next. You also can influence our thinking by using the upvote buttons on the theme “epics” themselves in the Issue Tracker.

While we work through this backlog of feature requests and introduce our new workflow, we don’t require any action from the community for older requests. We will continue to slot them in as time and complexity allows. Bug reports will be unaffected by our new processes: they’re still worked as they arrive, ahead of any new infrastructure.

Bugs, Fixed

Tables and the editor

A floating table you saved stopped letting text wrap around it
Text wrapped correctly while you were editing, and then didn’t wrap once saved, which is a genuinely confusing thing to report. The saved version wrapped each table in a container that claimed the full width of the container, even though the table inside it was half the size. This left no room for the text to move into. Left- and right-aligned tables wrap again.
Editing a table could break the editor
Certain table edits threw an internal error that left the editor unresponsive with your post still in it. Two separate causes that have been corrected: a stale column-resize handle surviving a structural change; and a failed paste vanishing silently instead of reporting itself.
Closing an OOC or Spoiler dialog (or a wide variety of other modal dialogs) yanked you to the top of the post
On a long post you lost your place every single time. Fourteen editor dialogs shared the fault; all fourteen are fixed.
A Box’s (formerly fieldset) title prompted you for “hidden text”
It asked for the wrong thing entirely and now says what the field is actually for.
We now record what a paste landed in, not just what was pasted.
This is for our benefit rather than yours, as it means the next paste bug someone reports is one that lets us actually see where the paste was meant to go. Visual editors are complex beasts, and this goes along with many other diagnostic patches we’ve made to give us insight into how you interact with them and where things break down.

Character sheets

Number fields threw away what you typed
Put a sheet field into a post, edit it to something that isn’t purely a number like “12 (+1)” and your text was silently discarded. The field’s declared type was being treated as a rule about what you’re allowed to write. This has been fixed and what you type is kept.
3.5e: Grapple’s BAB never received the mirrored value.
One number stored in three places, and one of the three wasn’t being updated.
Star Wars Saga: the Fort Defense box stayed empty.
The Saga sheet draws a Fort Defense box that was never filled, so it sat at zero while the real value lived elsewhere on the sheet. It now fills itself when empty, and deliberately never overwrites a number you put there yourself. A fix that overwrote hand-entered values would have been worse than the bug.
“Error message when filling in stats”
Fixed, along with a fault in how sheets reported the failure at all.
And the first edition of a user guide page for the sheets system, which has never existed in 20 years.

Games and recruitment

A recruitment advertisement offered you a setting the server would then overwrite. You could choose who may read the game’s forums, save, and find it silently changed to something narrower — because the wider option was never actually available for that forum. Options that can’t apply are now visibly unavailable, and if we do have to narrow your choice (for example, you tightened read access and write access needs to adjust to be consistent), we tell you which setting we changed and what to.
Resources were unavailable to applicants
A Game intending resources to be readable by everyone still had them hidden. Now “readable by anyone” opens its resources to anyone who’s logged in, and being able to find a resource is no longer the same thing as being able to read it.
Community staff couldn’t manage a game without joining it
Player View previewed the wrong viewer
A GM checking what a prospective player sees wouldn’t have that view displayed correctly.
A blind roll could show its result to the person who rolled it.
Blind means blind.
Savage Worlds damage can mix die sizes
savagedmg now accepts a full damage expression or a single die size, at your option.
The dice roller had no timeout.
One wedged roll could park every roll on the site indefinitely, with nothing to show why. Calls to it are now bounded.

Storage

Your bug report screenshots no longer count against your storage quota.
This came out of a question on a bug report. After having confirmed their bug was fixed, the community member asked how to delete the screenshots they’d attached, not wanting to “clog up the storage”. The honest answer was that deleting them would remove evidence we needed for the bug in question; even though we’d fixed it, we keep that information around in case we find (or cause!) a related bug in the same area. Using your space for reporting bugs would penalize behaviour we want. So, images used only in the issue tracker are no longer metered. An image that’s also in a post still counts, as it is genuinely your content. We also exclude issue-related images from your Reuse tab in the post editor, so you don’t reach for a portrait and find a screenshot.
Storage claims image in use, but isn’t.
Whether a file was in use was decided by who uploaded it rather than where it appears. An image someone else had posted read as unused to them and as untouchable to you. In use now means in use, whoever put it there.
You’re asked about a duplicate before it’s attached, rather than after
Uploading a file you already have used to attach it first and ask afterwards, which is the wrong order. Worse, one of the two upload paths it never asked at all.

Things that returned an error page

Five of these, all found by watching our own error logs rather than reported: saving a map overlay (which also no longer discards your work when it does have a complaint); a page’s revision history; saving an advertisement; viewing a renamed member’s old profile URL; and a single-post fetch that had been timing out for ten specific people.

The Image Rescue Is Finished — Early

In the last update we said about 22,000 image rescues had failed for temporary reasons, had never been retried, and would work through by the end of the month. It finished on Thursday.

5,372 images came back
Pictures that had been written off as lost and now sit on our own storage, where they’ll stay. The rest got a real verdict instead of a status nothing could act on: the host is gone and the link is dead. That’s disappointing, but a definite “gone” is more useful than an indefinite “maybe”.

Under The Floorboards

The Pathfinder sheet rebuild continues.
Class and level handling has a proper workspace now, carrying capacity accounts for temporary Strength, a shield counts toward AC, and the calculation engine was ported and then tested field-by-field against the old one which turned up four cases where the old behaviour was the wrong one. None of it is switched on for anyone yet. Pathfinder is the most complex transformation, because we had two entirely different sheet templates trying to manage the same set of data differently. Once we have Pathfinder done, the remaining work will be simpler.
New sheets are born with their template’s skill table already filled in
Previously, sheets with auto-filled skill lists had that data populated on first open of the sheet, so it could get lost or broken. Additionally, the Fill/Clear buttons that some sheets were drawing hadn’t been wired up; they now work.
We can detect infrastructure changing underneath us.
The site’s infrastructure is now checked against what it’s supposed to be on every deploy including things being added by hand, which is the case the previous check structurally could not see. This helps us make sure pushing an update won’t accidentally break the whole site.
Our deploy process gained five layers of guards.
Two people working at once could previously fold each other’s unfinished work into a release. That is now impossible rather than merely discouraged.
Rate limiting for anonymous traffic was reworked twice.
The first attempt reported success and silently didn’t take effect. After we caught that we made that particular kind of hidden failure impossible.
A background job that reported deploy-killed runs as dead workers now tells the two apart. This helps the admin team quickly respond to any reported issues.

Every Site Update So Far

What’s Next

Tell us if the feature-request change is moving in the wrong direction.
In brief, a third of our development slots with batches of features in themes worked through in one update. If you have ideas for how we can continue to improve, or if you want to weigh in on the next theme using the upvote buttons, this is the week to do it.
If a table stopped wrapping text after you saved it, go and look at it again. Nothing to re-save.
If you’ve been keeping bug report screenshots out of your storage, stop worrying about it. They don’t fill up your storage anymore.
Eight of these fixes are waiting on you to confirm them. If you reported one, we’ve replied to your report and marked it fixed-pending-your-check. If we got it wrong or if the fix didn’t correct your issue, reopen the report! It’s the only reason a couple of these are actually fixed now.

Keep on weaving those myths!

Open on Myth-Weavers Join the discussion Log in