Well, since the nodes get locked for editing while an editor does changes to it, it shouldn't be a big deal to use the same locking mechanism during a frontpaging and vice versa.
That is, as soon as the frontpage button is clicked, lock it for editing, and if the author is on an editing page, disable frontpaging (with a notification of why, so the would-be frontpager takes an extra look before committing fp on the nex text).
There might of course be some timing issues still where both hit the submit buttons at the same time, but it can either be secured by double-checking the lock, or ignored as a very minor risk. Up to the implementor, really. :)
You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue. | [reply] |
I think you've made a really good point there about front paging nodes and nodes that may be edited at the same concurrent time. Possibly an answer to that would be to allow the submitter to edit the node until they are sure that they no longer wish to edit it...and check it off that it's okay to be front paged. If a node is never checked off, it'll never be on the front page. Just a suggestion - may not be a good one. :)
- Moon | [reply] |
Thats what the preview button is for. You *do* use the preview button don't you ;-)
---If it doesn't fit use a bigger hammer
| [reply] |
Of course.. although there are times.. when it happens.. a typo escapes you!! Or does to me.. at times. But, who knows.. it maybe just me. I can admit that you're a better typer and proofreader than I ...especially when I am in a hurry! :)
- Moon - who is using smiley faces way too often today.
| [reply] |
Unfortunately, the preview button does not act as a copy editor.
The truth is we all make mistakes that we won't notice on
review, but that others will pick up on in seconds. Or is your
preview button significantly more magical than mine?
| [reply] |