Extension:EditConflict

Purpose
Some of not so large wikis are used in educational environments as CMS / collaboration tool. Often they have much less "number of pages to number of active users ratio" comparing to large wikis. Thus, edit conflicts occur more often at such wikis. Moreover, such wikis sometimes have highly experienced / professional users whose edits are much more valuable than other's edits (especially the anonymous ones). One may create (or use an existing) user group for such experienced users, then install this extension to make edits of professional users to have less probability of conflicting to other's edits.

Usage
Make sure that extension is installed and properly configured (see installation) first. A member of lower weight usergroup won't be able to edit the wiki page which is already being edited by the member of higher weight usergroup. Members of higher weight usergroups should make sure that Javascript and XMLHttpRequest are active in their browsers (which is typical for any recent browser). This is because the AJAX loop is used by default to check, whether the page is still being edited. Otherwise, there will be a large (by default 3 hours long) timeout which temporarily protects the page from being edited by members of lower weight group.

Special:Currentedits
Special:Currentedits special page, available to users with the administrative rights, provides information about current edit sessions on the wiki. Title of edited page, user name and his group weight, editing time is being displayed. When you know that the user finished his/her editing session, but the entry hasn't been removed from the list, be patient: it's just AJAX loop check has not been timed out yet (value of 'EC_AJAX_EXPIRE_TIME'). (※) link can be used to virtually (not really, because the editing is performed at client-side) close the editing session (simply to allow members of lower weight groups to edit in parallel). Listing can be ordered by page title, user name, editing time.

Installation
require_once( "$IP/extensions/EditConflict/EditConflict.php" ); EditConflict::$groupWeights[ ] = ;
 * Download the latest available version and extract it to your wiki /extensions directory.
 * Place the following line to the "extensions section" of LocalSettings.php
 * By default, the extension is pre-initialized with it's own default settings, which define the following weights of usergroups (from the lowest to the highest): anonymous (1), registered users(2), bureaucrats(3), sysops(4). You may customize / add weight of any available user group by setting key / value pair of EditConflict::$groupWeights[] array (after the require_once string):
 * Key is the wiki internal name of user group ('*' is anonymous, 'user' is for registered users)
 * Value  is the weight of group the user belongs to. In case user belongs to more than one group, the highest value will be used.
 * Definition of '*' (anonymous) user group weight is mandatory (otherwise the extension will throw an error).
 * Any group which key / value pair is not defined in the EditConflict::$groupWeights[] array will behave as lowest defined users group.
 * Check out Special:Version page to verify the installation (EditConflict should be in the list of installed extensions)
 * Login as the user with administrative rights, then go to Special:Currentedits page. Database tables will be set up.

Extra settings in LocalSettings.php
Use EditConflict::$alwaysEditClickEvent = true; to always attach AJAX check via DOM object event to edit link (button). This makes less possibility to member of lower height group to get standard 'access denied' message instead of JS popup.

Place the following line to LocalSettings.php: EditConflict::$groupWeights['*'] = 0; to set anonymous group weight = 0.

Zero is special lowest possible value of weight that disables AJAX watching loop for editing sessions, which makes such edits to be invisible in Special:CurrentEdits page. However, such edits are not blocking another edits of the same page, and may reduce the server load (no AJAX / DB calls).

Optional patch of includes/EditPage.php
The extension is currently deployed at patched core 1.11.1 and 1.15.1 of MediaWiki sites. However, it also was adapted to work with non-patched versions of MediaWiki (tested with 1.15.1 and 1.16 alpha), albeit with limited functionality.

To enable additional functionality, one may add 'EditPageMergeChanges' hook to 'includes/EditPage.php ' by finding and replacing the following text if ( $this->mergeChangesInto( $text ) ) { to if ( $this->mergeChangesInto( $text ) || wfRunHooks( 'EditPageMergeChanges', array( $this, $text ) ) ) { Then, place the following line in LocalSettings.php EditConflict::$useEditPageMergeChangesHook = true; after require_once( "$IP/extensions/EditConflict/EditConflict.php" ); line.

This will enable copying of the conflicting revision of the member of lower group to the subpage of his userpage. Eg, if user "UserA" of lower group had edited "Page1" title, and that edit caused an conflict with edit of higher group member, first revision will be copied into the "User:UserA/Page1" subpage and the edit conflict will be suppressed. "UserA" will recieve warnings about his copied edit at the top of the wiki page.

Technical notes
Tracking of page edits is not a trivial task, because the power outage or hardware freeze can happen any time, so the code which is supposed to detect end of edit session may never run at client side. Luckily, server side usually is much more reliable, and by using AJAX loop with reasonable timeout (let's say a minute, to not load the server too much), we can use edit time update to time out the session. Termination of AJAX loop causes stop of edit time updating which causes edit session timeout ('EC_AJAX_EXPIRE_TIME' in EditConflict.php). So, client's hardware problems will look to server exactly like usual end of session via Submit button or browser's Back button. Clients, which do not support Javascript and AJAX impose a stronger problem. However, such clients are discouraged to use only by members of higher weight groups, who should be guided to use a modern browser and to do not disable Javascript. Lower weight clients without XMLHttpRequest will recieve their action='edit' deny anyway, albeit with less pretty way (standard "action denied" message instead of AJAX-generated popup warning).

In the worst case, when privileged user's client has no JS and/or XMLHttpRequest, the AJAX loop simply won't work but nothing will break: just the privileged users will get page editing conflicts more often. But, even in such rare case they will be protected from lower weight users by "total edit time" timeout, which is customized by 'EC_EDIT_EXPIRE_TIME' constant in EditConflict.php. Default value is three hours, which is more than enough for most of edits. Unfortunately, lower level users will not be able to edit this page for that whole time, that's why it's important to guide priviledged users to use modern browsers.

Localization
Additional languages can be added into EditConflict_i18n.php file. If you have translated the messages, please mail me, so I'll update the archive. Until an extension will be added to http://translatewiki.net/ (I hope so).

Download
To extract tgz archive in Windows, free 7zip program can be used.

Troubleshooting

 * In case there are any problems, make sure you've followed every installation step and MediaWiki version is compatible with the extension. Please report the bugs at the talk page. Also you may try using previous version (when available).