Page MenuHomePhabricator

Add a wgCurRevisionTimestamp to mw.config
Closed, DeclinedPublic


Please add a wgCurRevisionTimestamp to the mw.config set of variables as it would be more efficient than an API call just for that information and is a fairly frequently used piece of information (when attempting to avoid edit conflict issues.

See Also:
T21276: Add time elapsed next to last modified timestamp, or js variable (wgCurRevisionTimestamp)



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:15 AM
bzimport set Reference to bz54619.
bzimport added a subscriber: Unknown Object (MLST).

It would help if, rather than only presenting a potential solution, you also described your problem (i.e., your use-case). Feel free to paste example code or links to code here.

Are two issues I know of where such a variable would be more efficient, although not for the edit conflict reason.
Having this parameter would also give something to compare the current timestamp from the API with against to help resolve issues like:

brion added a comment.Sep 26 2013, 3:03 PM

I might recommend building a cleaner JS interface for 'currently displayed revision information' rather than just adding more and more globals...

Another solution is bug 32037: detect edit conflicts with the revision id, not with a timestamp

(In reply to comment #4)

Another solution is bug 32037: detect edit conflicts with the revision id,
not with a timestamp

Which still doesn't solve use cases like the first two I mentioned:

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 13 2016, 10:13 AM
Amorymeltzer added a subscriber: Amorymeltzer.

Alongside wgCurRevisionTimestamp, might as well have wgRevisionTimestamp, to parallel wgCurRevisionId and wgRevisionId.

Krinkle updated the task description. (Show Details)Dec 17 2019, 6:14 PM
Krinkle closed this task as Declined.Dec 17 2019, 6:17 PM

This information can be received through the MediaWiki API, which is easily accessible for gadgets via mw.Api. Using mw.config for this is the old style and should not be encouraged for new abilities.

It looks like some or all of the use cases described in this task are not about presentation of information in the gadget, but about internal values used to prevent edit conflicts. If that is the case, be sure to create a new task about that solving problem (instead of about making a workaround easier). For example, the mw.Api#edit method could provide anything you need to prepare for an edit, and then submit it. Taking care of anything else like this internally, in an internally optimised way, not by creating public features for its internals.