Page MenuHomePhabricator

Add a wgCurRevisionTimestamp to mw.config
Closed, DeclinedPublic

Description

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: Make last modified timestamp on page views machine-readable

Details

Reference
bz54619

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.

https://github.com/azatoth/twinkle/issues/175

https://github.com/WPAFC/afch/issues/153

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:

https://github.com/WPAFC/afch/issues/30

https://github.com/WPAFC/afch/issues/156

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:
https://github.com/azatoth/twinkle/issues/175
https://github.com/WPAFC/afch/issues/153

Amorymeltzer subscribed.

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

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.