A few things will be fixed in this release around page locking.
The first thing, if someone from the same IP address (but different user name) was attempting to edit the same page, an and statement was being checked which should have been an or statement. This caused SetLock() to call RefreshLock() when it shouldn't have. I have corrected this. Unfortunately, if two users from the same (external) IP address (think a school or business network) were modifying the same page at the same time, and neither one was authenticated, then they would clobber each others' edits. The only way around this would be to introduce a session ID or something to that effect. I suppose I'll have to look at this sometime down the road.
The other fix was the fact that DoPostingEditing() wasn't checking the page lock. Since the edit form shouldn't show a submit button if the page was locked, initially I didn't see this as a problem (I guess?). However, if you wait for the lock to expire and refresh the edit form, you will then have a submit button. But even without that, you could still manually submit the form via other means (I'm looking at you, spambots!). So we'll now check for locks before a new edit can be saved.
In furtherance of that, perhaps DoPostingEditing() should check to be sure that the page wasn't modified before your edits are submitted. Example: You begin working on Page A, but you're busy doing other things at the same time. So you take a couple of hours to make your edits. Meanwhile, your lock has expired, and somebody else came along and made some edits. If your edits go through when you finally get around to submitting them, you will clobber previous edits. The way I see it, there are two options around this:
-- AaronGraves Thu Apr 2 14:33:05 UTC 2015 (184.108.40.206)
The session ID is going to have to be required. Even if the same user is editing a page, if they change the name field at all, it will then deny their edit.
-- AaronGraves Sun Apr 5 20:17:44 UTC 2015 (220.127.116.11)