Page MenuHomePhabricator

Stash unsaved drafts of articles
Closed, DeclinedPublic

Description

There's a feature in MediaWiki core called "stashed uploads", which are files that were uploaded to the server but not actually saved to the site. They appear as private data for each user. I'd like to have something similar for page text.

This would involve designing and implementing a new database table for the saved text, adding a special page and an API module for access, and probably implementing new userscripts or gadgets to automatically save text in edit pages.

You may or may not be able to revive the existing Extension:Drafts project, clean it up, and make it work with a new gadget for auto-saving. The existing solution requires a log-in - we may want to look into storing logged-out editors' drafts in localStorage, too!

Project goals:

Design and create a new database table that stores private text per-user
Add an API module that allows clients to access that text
Add a special page that allows clients to manage which text is stored
Implement a gadget or extension to auto-save edit pages every N minutes (bonus points for configurability)

  • Relevant skills: PHP, MySQL, JavaScript
  • Mentor: @MarkTraceur
  • Co-mentor: <Phabricator Username>
  • Estimated time for a senior contributor: 2-3 weeks
  • Microtask(s):

Event Timeline

Qgil created this task.Feb 11 2015, 12:37 PM
Qgil raised the priority of this task from to Low.
Qgil updated the task description. (Show Details)
Qgil added subscribers: Qgil, MarkTraceur, Technical13.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 11 2015, 12:37 PM
Qgil added a comment.Feb 11 2015, 1:44 PM

Wikimedia will apply to Google Summer of Code and Outreachy on Tuesday, February 17. If you want this task to become a featured project idea, please follow these instructions.

@MarkTraceur, @Technical13, are you confident that this feature has community consensus or at least no blockers?

Before marking this task as a GSoC/Outreachy featured project idea, I would welcome the opinion of @TrevorParscal, @Jdforrester-WMF, and others having an opinion about Extension:Drafts and/or the feature proposed here.

PS: we need more project ideas indeed! This is just a sanity check to avoid sending GSoC/Outreachy candidates to conflictive areas or dead ends.

I've had people hunt me down to ask me if I could write a userscript for this and I've had people say it's a great idea when I talk about it. I've never had anyone express any concerns (except for a doubter that thought it was technically impossible but thought the idea was good) or say they didn't like the idea. After all, who wants to type the same content twice or fix the same thing twice? Also, I can only imagine how many decent new editors got discouraged by not having their contributions added correctly and just gave up/walked away since "it's only Wikipedia" and "someone will eventually fix it or create it"

Niharika updated the task description. (Show Details)Mar 4 2015, 2:52 PM
Niharika set Security to None.

@Technical13, @MarkTraceur could you add a couple of relevant microtasks above?

@TrevorParscal, @Jdforrester-WMF, comments welcome!

Rits added a subscriber: Rits.Mar 4 2015, 2:56 PM

@NiharikaKohli I believe I have pointed people to tasks on the MediaWiki-extensions-Draft project before, but I will attempt to curate some good ones.

@Qgil I don't know if there's community consensus for putting this on WMF wikis, it seems to not be deployed currently, but there's a project that exists and needs polish. I think it's useful. I don't really want to go out and try to convince communities to use it, but that doesn't mean it's not a good feature to have available. (also what T13 said.)

Sorry about the slow reply, I'm not terribly good at checking my 500+ phabricator notifications.

@Qgil for a start

If anyone needs help with these they can contact me.

@MarkTraceur: would you be interested in being a primary/secondary mentor for the same, iff we get community consensus?

Qgil added a comment.Mar 4 2015, 8:15 PM

About the community consensus, in this case this is more a double-check than a requirement. As the proposal explains, Commons is already caching images before publication. We had a discussion somewhere about the caching of comments right here in Phabricator, and the agreement was that there was a legal blocker.

At the time the Drafts extension had some problems, but that wanted to be a lot more sophisticated than the case exposed here. Besides, this is clearly a feature that your average 3rd party MediaWiki will want to have if it works and is easy to install.

I pinged JamesF and Trevor just in case they had something to say. I think that this is good to go if the mentors confirm.

Isn't @TheDJ already working on this with localStorage?

TheDJ added subscribers: aaron, ori.Mar 4 2015, 10:23 PM

@Legoktm Yes, I've been working on a localStorage drafts module (and a rewrite of it using indexedDB, which I personally prefer).
https://gerrit.wikimedia.org/r/5130
https://gerrit.wikimedia.org/r/159626
This feature was mostly envisioned to increase robustness in cases of lost connections, crashing browsers etc.

There is also stashing, which can be used to pre-submit, made by @ori and @aaron, intended to speed up the final submission process:
http://git.wikimedia.org/blob/mediawiki%2Fcore.git/ade66c04e9b304129f18ee33496fdf00869f4597/resources%2Fsrc%2Fmediawiki.action%2Fmediawiki.action.edit.stash.js
I note that this is still experimental however (and really should debounce it's keyhandler I suspect...)

Would be cool if someone could pull all of that together I guess.

@TheDJ Is there still any scope to push this as a GSoC/Outreachy project?

Would be cool if someone could pull all of that together I guess.

Would that be big enough for a 3-month project? Could we combine a bunch of tasks together?

Qgil added a comment.Sep 23 2015, 9:06 AM

This is a message posted to all tasks under "Need Discussion" at Possible-Tech-Projects. Outreachy-Round-11 is around the corner. If you want to propose this task as a featured project idea, we need a clear plan with community support, and two mentors willing to support it.

Qgil added a comment.Sep 23 2015, 9:35 AM

This is a message sent to all Possible-Tech-Projects. The new round of Wikimedia Individual Engagement Grants is open until 29 Sep. For the first time, technical projects are within scope, thanks to the feedback received at Wikimania 2015, before, and after (T105414). If someone is interested in obtaining funds to push this task, this might be a good way.

Sumit added a subscriber: Sumit.Mar 1 2016, 5:37 PM
IMPORTANT: This is a message posted to all tasks under "Need Discussion" at Possible-Tech-Projects. Wikimedia has been accepted as a mentor organization for GSoC '16. If you want to propose this task as a featured project idea, we need a clear plan with community support, and two mentors willing to support it.
Qgil removed a subscriber: Qgil.Mar 2 2016, 10:30 AM
Niharika removed a subscriber: Niharika.Mar 2 2016, 6:59 PM
Sumit added a comment.Sep 12 2016, 6:41 AM

This is an interesting project. @MarkTraceur @Technical13 you are listed as mentors of this task. Can we have this featured for the current round of Outreachy-13 internship ( Dec 6 to March 6 ) ?

@Sumit I have no outright objection to that. If the stars align, I may need to find another mentor, but we can cross that bridge when we come to it.

Sumit updated the task description. (Show Details)Sep 12 2016, 3:35 PM
Sumit updated the task description. (Show Details)
Sumit updated the task description. (Show Details)

@MarkTraceur thats great! I'm adding this to Outreachy-13 and leaving your name in as the mentor then. It'd be great if you could add one or two microtasks, as those always help in selecting candidates later.

We in Editing are already working (T57370: [Epic] VisualEditor: Implement some form of auto-save to help with browser crash recovery and accidental tab closing) on doing client-side edit stashing/resume in the visual and new wikitext editors; we'll probably get a version of it out to production in the next month or so, hopefully (here's to Sod's Law). It feels like pushing this (as doing the same, but now on the server) as an Outreachy project wouldn't be as exciting in that situation, especially as we'd be unlikely to want to deploy both to Wikimedia production?

We in Editing are already working (T57370: [Epic] VisualEditor: Implement some form of auto-save to help with browser crash recovery and accidental tab closing) on doing client-side edit stashing/resume in the visual and new wikitext editors; we'll probably get a version of it out to production in the next month or so, hopefully (here's to Sod's Law). It feels like pushing this (as doing the same, but now on the server) as an Outreachy project wouldn't be as exciting in that situation, especially as we'd be unlikely to want to deploy both to Wikimedia production?

@Jdforrester-WMF in that case, is it possible to takeover the above and pitch it or its part as an internship project?

We in Editing are already working (T57370: [Epic] VisualEditor: Implement some form of auto-save to help with browser crash recovery and accidental tab closing) on doing client-side edit stashing/resume in the visual and new wikitext editors; we'll probably get a version of it out to production in the next month or so, hopefully (here's to Sod's Law). It feels like pushing this (as doing the same, but now on the server) as an Outreachy project wouldn't be as exciting in that situation, especially as we'd be unlikely to want to deploy both to Wikimedia production?

@Jdforrester-WMF in that case, is it possible to takeover the above and pitch it or its part as an internship project?

No, I don't think so.

The work is already half-written (see https://gerrit.wikimedia.org/r/#/c/303572/ and its stack), and taking it over or doing it from scratch would require exceptionally deep understanding of the VE DM and especially the transaction model. It would be a frustrating and painful experience for an Outreachy/GSoCer who didn't already have deep experience with VE, and would be pretty disruptive for @divec to have to down-tools on the project so that an intern could take it over.

Sumit closed this task as Declined.Sep 12 2016, 9:13 PM

Considering current developments, I guess this is no longer valid.

This shouldn't be dependent on VE. I've been mostly away and out of the loop. I'd still be interested in working on this.

Sumit added a comment.Sep 13 2016, 4:27 AM

This shouldn't be dependent on VE. I've been mostly away and out of the loop. I'd still be interested in working on this.

Can you elaborate on the above? Given that @Jdforrester-WMF has already stated the development of a similar feature client side, what would be the benefits of the same feature on server side, and what motivation would be there to deploy it, given that the VE stash feature would be in place?