A customer filed a ticket on April 12 reporting that a mobile reorder option on their custom page would not stick. They set it, hit save, reloaded the page, and the field was back to its default.
My first read: mobile UI bug. The field was rendering correctly. The save button was wired to a JavaScript handler. The page refreshed on submit. I started tracing the frontend.
That was wrong.
the field was saving, just not what it looked like
The symptom was real. The diagnosis was off. mobileOrder was making it to the server. The POST was landing. The problem was what the backend did with it depending on whether the record already existed.
HomeTeamsONLINE has a pattern I see throughout its custom-page module code: one handler for ADD, one for UPDATE. They were written years apart by different hands, and they had drifted into different shapes.
The ADD path was writing the full payload. Settings, styles, title, mobileOrder, the works. The UPDATE path was writing parent and cellIx. Two fields.
Every time a user edited an existing custom page and saved, the UPDATE branch fired and silently dropped everything else. The field appeared to save because the page reloaded. It looked like a confirmation. It was just a stale render from the prior value.
The bug had been there long enough that nobody had traced it to the save path. They had been filing tickets about the UI.
proof before trust
Legacy systems have a credibility problem. You find a bug, you write a fix, you deploy it, and you cannot be sure the fix actually applied to the right path. The codebase is old enough that there are sometimes two versions of the same handler in different include files, and the wrong one might be winning.
I built a small diagnostic page to verify the fix before closing the ticket. It reads the current saved value for a given record and displays the raw field alongside the rendered value, so you can confirm what the database actually holds after a save operation. Not clever. Just proof.
That page earned its existence immediately. Without it I would have tested the fix by eyeballing a form reload, which is exactly how the bug hid for this long in the first place.
the fix was symmetry
Once the shape mismatch was clear, the fix was not complicated. I updated the frontend payload builder to include the full field set on both the ADD case and the UPDATE case. Then I updated the UPDATE branch on the backend to accept and persist those fields the same way ADD did.
The session touched the backend save handler, the JavaScript payload constructor, and a small diagnostic page for verification. The commit went to ITEM-6802. The customer confirmed the field held on their next test.
the question the fix left open
The HTO custom-page module is not the only place in the codebase where ADD and UPDATE were written at different times by different people. The same drift exists in other module types. Some of them probably have fields that look saved but are quietly dropping on UPDATE. Those bugs have not been reported because they require a specific combination: an editable field, an UPDATE path that predates that field, and a user who noticed the revert.
Most users do not notice. They reload the page, see something reasonable, and move on. This ticket arrived because the customer was configuring a mobile layout and the missing value was visually obvious on a small screen.
The right fix for the broader problem is a single payload contract that both ADD and UPDATE share, built once and enforced at the serialization layer. That is a refactor, not a patch, and it belongs on its own ticket.
For now, the ITEM-6802 path is clean. The others are waiting for the next customer who notices.
When a UI setting will not stick, the bug is usually not in the UI. Two parallel write paths have drifted, one of them is quietly dropping the field, and the fake frontend symptom is a tell for split-brain persistence. The field reports save because the page reloads. The save never happened.