After you post a reply in the forum, it sometimes takes about a minute to show up in the thread. This is somewhat frustrating for contributors, and is confusing for users (who sometimes will post their question over again).
Let's add a message that asks contributors to be patient and wait for their posting to show up.
Assignee: nobody → bkrausz
Remember it's not just people posting in a thread, it's people starting a new thread as well. I think when it happens when you start a new thread, you get put back to the "post new question" screen.
The easiest fix will be to add a note next to the Submit button in all of these places warning of this. Adding a message post-submit seems pretty difficult, specially since things redirect around it seems. Anyone have any objections/suggested wordings?
As long as you do some reasonable action for people posting new threads (give them the thread listing), that's better than nothing. I'd still prefer a real fix though.
Do we know what's causing this issue? I think it blocks bug 446203 (unless it doesn't) but I think the implementation I proposed in bug 446203 would at least partially address the concern here unless it's blocked. Does that even make sense? Basically if the issue is that the forum listing is cached and needs some time to update, implementing a patch for bug 446203 will be a better solution than adding text to the submit form. If the issue is that the posting doesn't get written to the database for a block of time, bug 446203 is unpatchable until that's fixed and so we should go with the text solution. English is not my first language on Saturday mornings.
The problem is DB replication delay, the only solution to this is to use the master DB when showing them the post, but since we have to redirect them to the post this is very tricky to do...we'd need to set a "master" cookie or GET parameter which would probably be a security issue, etc.
Can we give them a link to their thread that they can bookmark? How long is this delay? (Can we have a 10-minute countdown?)
As per bug triage, we're going to set a "master" session var that will have the user read from the master for a minute. Will implement today.
Created attachment 330871 [details] [diff] [review] Proposed patch I have no idea how to test this before production, but seems to work (sets and expires $_SESSION var appropriately).
Attachment #330871 - Flags: review?(laura)
Comment on attachment 330871 [details] [diff] [review] Proposed patch Good, except can you please turn the 30 into sensibly named constant.
Attachment #330871 - Flags: review?(laura) → review+
Also, does this patch force master right away? It does not look like it to me. If not, it might be a good idea to do so right away in addition to setting the timer, to solve one of the problems described in bug 438768. startMasterTimer should call forceMaster?
Done, r17365, r17366. Laura: constant is at the top of tikidblib, since there's no better place for it :-/ Nelson: Added, good suggestion. It wouldn't matter for comments since they redirect after setting the var, but I can see it being needed in the future.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.