django-wiki
Feature request: editing page sections
Hi. One feature I've really been missing from MediaWiki is the ability to edit just a section of a page. It allows for simultaneous edits by different people, and in general it just makes it safer and more clear when only part of a page needs to be changed. I'd love to see something similar in django-wiki. Is this a feature you've considered?
Thanks.
Hi! Sounds like an interesting brainstorm!
Currently, if there is a concurrent edit, the edit page will warn that there has been made a newer revision, and then displays a merged version (including any conflicts in the text). No new revision is saved until the user has pressed Save once again.
How do you have in mind to split pages into sections and run the revision system on separate sections? It sounds very complicated.
I think what a wiki does differently from a collaborative editor (like Etherpad) is to be more explicit about its revisions. But I could really see a mix happening. For instance that an article was temporarily locked for collaborative editing, and then when the collaborative session ended, a new revision is created and the article unlocked.
The way MediaWiki breaks it out, it seems like there's an "edit" link at every header tag (H1, etc). Click that and the editing form only gives you the content for the children of that tag. It's nice for limiting the context of what you have to see in the editing form, especially when you're working on a long article.
I hadn't actually tested concurrent editing in django-wiki yet. I was wondering how it handled conflicts like that -- good to know! Perhaps after saving changes, the revision system could simply check in a revision of the entire page as it does now, but the editor could be limited in the scope that it shows. That might work out neatly, and would make it a simpler thing to implement.
Hmm, I can see that it's possibe to parse the contents and chunk it into sections, but what if that structure changes concurrently with an edit?
User 1 -> Edits section no 3. in article User 2 -> Adds a section before section 3
Above example shows that each section would need a prescribed unique ID for this sort of conflict to be avoided. Using the header text is no good, since that could change as well.
But if we start putting this sort of auto-generated code into the article text, we're losing out on the simplicity for which Markdown was chosen.
Another method could be:
User 1 -> Edits section no 3. This section automatically gets encapsulated by [locked_by=username dtm=2013-01-09 21:31:00][/locked] and a plugin ensures that all edits done by other users removing this tag will be invalid. User 2 -> Can edit everything except removing the locked-tag and anything inside it.
After a while, the lock becomes invalid and will automatically be removed.
But you're right about your last suggestion, that would avoid undetected conflicts. It could be interesting to try using maybe just an uneditable version of the heading (as an ID) and an enumeration of where it occurs (3 = 3rd H1, 3.1 = 1st H2 below 3rd H1 etc). If the enumeration and heading ID does not match with a new revision, a conflict will be assumed and the change will be dropped.
It looks to me like MediaWiki tries to keep the software simple and leave most of the decision making to the user. I found this in a wikitech-l mailing list post:
It's pretty simple. We use optimistic conflict resolution. No locking is used. If, when you go to save a page, someone else has modified the page in the time between when you started to edit and when you saved, an automatic merge is attempted. The merge will go through silently if the lines modified in previous revisions are different from in the submitted one. If the submitted revision modifies a line that was also modified since editing began, the user is informed of the conflict and asked to resolve it, with the full wikitext of the current version and the submitted one, and an appropriate diff.
http://meta.wikimedia.org/wiki/Help:Edit_conflict is mentioned there, which has a more in-depth overview. That page also makes it sound like all the intelligence of processing is left to the users rather than the software. So the 2nd user to save would be left resolving the conflict using some diffs and a form. I like the idea of using expiring "locked" tags where an edited section's H tag is, but I wonder if that would get in the way of conflict resolution. If the user that's cleaning up the edit conflict gets a full copy of the new page, you'd have to strip those out so that it would be safe to save. It might be enough just to remember what the heading tag was and its relative position (in case there's more than one matching title/heading level pair) within the editing form.
http://meta.wikimedia.org/wiki/Help:Edit_conflict is mentioned there, which has a more in-depth overview. That page also makes it sound like all the intelligence of processing is left to the users rather than the software. So the 2nd user to save would be left resolving the conflict using some diffs and a form. I like the idea of using expiring "locked" tags where an edited section's H tag is, but I wonder if that would get in the way of conflict resolution. If the user that's cleaning up the edit conflict gets a full copy of the new page, you'd have to strip those out so that it would be save to save.
One way around this is to allow "comment" lines which only appear in editable version -- conflict resolution cruft could be added as comments. It might be enough just to remember what the heading tag was and its relative position (in case there's more than one matching title/heading level pair) within the editing form.
— Reply to this email directly or view it on GitHub.
Is it really optimal to auto-merge stuff and save new revisions? There might be semantical conflicts remaining. We could just warn the user of course.
I don't know about the locking tag... it could be abused pretty heavily and mess with the core nature of the wiki. For instance, malicious user writes something dirty, then locks it. This would require additional work on the permission system.
Pondering this, I think you're right that it should be implemented in the naive way. These are cases... User A always presses save LAST, but User B has edited something meanwhile.
Case 1:
User A -> Edits a section 3.2, which is identified by its enumeration and headline title User B -> Changes the headline of 3.2
Expected result: User A is told that the section being edited was not found, please save your text and go to the article again.
Case 2:
User A -> Edits section 3.2, which is identified by its enumeration and headline title User B -> Adds a new sections so the enumeration of 3.2 becomes 4.2
Expected result: The wiki identifies the new enumeration by the headline and simply warns the user
Case 3:
User A -> Edits section 3, which is identified by its enumeration and headline title, adds section 3.2 User B -> Adds section 3.3 meanwhile.
Expected result: User B's section is merged, and the user is warned. If the merge fails, User A will be presented with the conflicts inline.
Does all this sound fair? And do you have any worse cases? :)
@shaunc regarding the whole comments thing, I would love a comments system highly similar to the one in http://www.djangobook.com/ to be implemented as a plugin, would be beautiful!!
That all makes good sense, Ben. I think the direction sounds right on. So here are a few other scenarios:
Case 4:
User A -> Edits section 3.2, renames it. User B -> Adds new section 3.2 before the original 3.2
Expected result: User A gets conflict message and is given the chance to edit the entire section 3, including User B's new content and User A's new content. Or would it be better for B's 3.2 to be inserted neatly before A's 3.2? That might break the context A was thinking in while writing, so I'm inclined to think the report-conflict-and-re-edit solution with section 3 as the context is best.
Case 5:
User A -> Edits section 3.2, changing the headline title User B -> Edits section 3.2, leaving the title the same but adding content
Expected result: User A gets conflict message and is given the chance to edit section 3.2, including User B's new content and User A's new content.
In cases like these, it seems to me the final effect is that User A checked out the text after User B made their save, so they then have to go back and re-edit. It's important that they're able to see User B's contributions and their original new text, though. So there's probably some important consideration to be given for how to present that info. Perhaps generating a minimal diff and presenting it nicely, then giving User A a form that has User B's version of the section pre-loaded and leaving it up to A to re-add their changes would work well.
I guess we could drive ourselves mad trying to think of all the minor differences in scenarios that might produce conflicts. Overall, though, it sounds to me like you might end up in a couple general situations after User A saves: you can warn and merge gracefully, or you can warn and present the editing form again with a specific context.[1] The context might need to be flexible based on the scope of the conflict: leave it at that subsection, expand it up a level, or expand up to the whole page? That sounds like something that could be generic, too, and you could always just pick the lowest parent header that's an ancestor of all conflicting section headers. I think it's fundamental to avoid going down all the rabbit trails, though, and to try to come up with some general principles and then leave the heavy lifting to User A. He's going to know how to resolve this better than any software could, at least much more often, and in some wild scenarios where there are massive rewrites of huge sections and that sounds like a really unfortunate option to inflict on User A, I guess there's always the Changes page to use as a historical reference and a saving grace.
[1] I guess that more generally speaking, the 1st scenario could be called a warning and the 2nd a failure -- you can save in the former, but you can't yet in the latter. So maybe it's a soft failure.
Hi @oshaughnessy ! Sorry about the late response.
So, this is manageable but requires some careful thought.
I think the way to implement this, is to make some sort of modification to the plugin system so it's possible to add it as a plugin. The reason is to keep the core code base as simple as possible.
This would be a great addition.
There are some existing jquery plugins that allow for editing logical elements of a page.
Specifically jEditable is a good example that supports markdown...
Main jEditable Page
http://www.appelsiini.net/projects/jeditable
Demo
http://www.appelsiini.net/projects/jeditable/default.html http://www.appelsiini.net/projects/jeditable/custom.html
@mogga - jEditable looks interesting. Thanks for the tip. However, because of the great complexity of the Edit page (plugins sidebar etc.), such a nifty jQuery add-in is not enough to do the job.
I do, however strongly support embedded editing, which is scheduled post 1.0. The generic modeling already allows articles to be attached to any model object, so having embedded editors is a must. I think it will be a solution akin the django-cms edit mode.
I didn't fully read the request. It wasn't about using the Edit Page for me... I also hadn't considered multiple users.
I would say this is a few requests in one.
-
Get inline editing of an entire page working, exclusive of the Edit Page
-
Get editing of individual blocks using the Edit Page working - easiest way is to use header ids with the header_id markdown extension I think - limit user to editing header to next header
http://packages.python.org/Markdown/extensions/header_id.html
-
Allow multiple users to edit the same page - this is a big one if it's gonna be like google docs...
I was thinking a separate view that jEditable editing inline submits to. It would take a little reverse engineering of the markdown given everybody has a different preference for how they write it.
http://www.aaronsw.com/2002/html2text/ http://daringfireball.net/2004/03/marcia_marcia_markdown
3 is never going to happen. Concurrent editing and structured, transparent editing are two different scenarios.
With that said, I think that 1 and 2 will switch places, because 2 is easier to solve and there's a nice discussion above detailing out different cases :)
Thanks for the tip on the header_id extension. Looks very useful!!
Just to elaborate on 3, concurrent editing requires a lot from the revision system. The reason why wiki data can be properly managed is because the revision system clearly outlines who did what and when in a linear fashion. Using concurrent editing as with Google Docs would overload the revision system in a way that made it very difficult to track changes and revert them or merge them.