The issue I can see is if things are to lagged, someone could be replying to an email post and there are already replies, especially if the wait time gets long. So its finding that balance point.
Oh Hey, I've added this after I posted
Hmmm, a session that active sounds like a "live stream" scenario.. Only way I can see that handled somewhat elegantly is for the admin having the option of setting a board (if the whole forum isn't that active), on a board-by-board basis, with no editing or delays (and I don't even want to imagine what coding that would entail, never mind the server requirements).
Otherwise the admin just has to adjust the forum editing (and email notification?) delays to match the temporal user traffic. I favor the idea of the email notification not going out until the edit delay expires. And that does seem to lean toward having a separate pipeline handling mail notification - "quick edit" expiration is the trigger that pushes the current post "version" into the mail queue (and off it goes as the server capabilities allow), while the rest of the forum processing proceeds as if email notifications didn't exist at all.. But, is that "separate pipeline" a coding change I also don't even want to imagine (and hence the email notification delay setting is the structural work-around)?
Last post by Spuds -
I've gone back and forth on just that.
We have the "Courtesy edit wait time" which I think defaults to 10min but could be anything or off. Right now I hard-coded in a 180 second wait time and then the scheduled task currently defaults to 5min. I could tie that 180 to the "Courtesy edit wait time" bounded with some min/max.
The issue I can see is if things are to lagged, someone could be replying to an email post and there are already replies, especially if the wait time gets long. So its finding that balance point.
Quote from: Spuds – in 1.0x-1.1x when you posted the system would process email notifications real-time. This would send the emails immediately or add them to the mail queue (if enabled). ....
In B2 I've moved this to a (optional) scheduled task, so when you post the only thing that happens is the item is added to a queue. There is a 3min minimum wait time before the email is sent and a worst case max 8min. The minimum wait time is intended to allow that last second edit when after you post and see some mistake ... now you can fix it before anything was sent ...
I was surprised to hear mail notifications went out more or less immediately, else I would have suggested it not be 'sent" until after the "quick edit" time expired, so you don't have one version of the post out in Email that could attract a PBM reply that's different than an updated post without an {edited: ..] notation shown on the website. That "Edited:" helps maintain a modicum of sanity across the space-time continuum..
In addition or in lieu of the selectable delay, in B2, I'll offer that suggestion now,
Last post by Spuds -
This will be in B2 and It on this site now.
in 1.0x-1.1x when you posted the system would process email notifications real-time. This would send the emails immediately or add them to the mail queue (if enabled). This worked but could cause a delay to the user that was posting as the system had to complete that work in that single pipeline before returning and showing the post.
In B2 I've moved this to a (optional) scheduled task, so when you post the only thing that happens is the item is added to a queue. There is a 3min minimum wait time before the email is sent and a worst case max 8min. The minimum wait time is intended to allow that last second edit when after you post and see some mistake ... now you can fix it before anything was sent There is also a retry mechanism in that queue so if for some reason the server failed to accept the email it will retry it up to 5 times.
This does require a new table be added to the DB small price to pay for a good feature.
Drastic no ... but a lot of files were updated, some just a couple of lines, others more extensive. Since most custom themes tend to mainly hit MessageIndex.template.php, BoardIndex.template.php and Display.template.php and then fallback to the default templates for everything else, you would just have to post those changes back to your files.
14/27/25 are the number of lines affected for the above mentioned files.
This loads the strings and shows the variable name / current text. Change the text to what you want and hit save. This saves the change in the database and change is loaded/merged with the language file when its called for. This is faster and more portable.
I think this answers that for you. Looks like it saves what you change to the database, not the file.
Last post by Hj Ahmad Rasyid Hj Ismail -
Isn't the problem with default language files are that they will be overwritten when updating to newer version? If it is not update proof, there is no point of editing it. What I think may be best is, if such editor is being used, the string(s) that have been edited shall be put into a custom.language.php and also remember that it had done that in the future, when it is opened again.
...
