Closed
Bug 678498
Opened 14 years ago
Closed 13 years ago
kuma: Implement per-section edits on the server side
Categories
(developer.mozilla.org Graveyard :: Wiki pages, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
1.6
People
(Reporter: lorchard, Assigned: lorchard)
References
Details
Bug 665697 enabled per-section edits with client-side scripting. When it saves changes, though, it saves the entire text of the page and not just the changed section.
So, consider if both UserA and UserB load editors for different sections. If UserB saves changes first, and then UserA saves her changes, all of UserB's changes will be lost.
As a counter-example, MediaWiki implements per-section edits on the server-side in a way that allows editors to change a section at a time, and usually with many editors working on the same page at the same time without conflicts.
Some implementation ideas, if we do this (each of these probably breaks out into a p=1 or p=2 bug):
* Ensure sections are wrapped in HTML5 <section> tags. This should be something ckeditor does when H{1-5} tags are added. It should also be enforced/normalized on the server-side in case the page source is edited directly.
* Ensure sections have IDs that are unique per page. This could be done with UUIDs, or it could even be done with random numbers and a uniqueness check. Should be handled on both the client and server sides.
* Bonus features
* Sections anchor targets for links. We could auto-linkify all section headers, given the section ID.
* We can use the HTML5 Outline algo [1] for building Tables of Contents
* Once we have this structure enforces in documents, use pyquery [2] to parse and manipulate the page source on editor load and save.
* On editor load, extract the source for the section by ID with pyquery.
* On editor save, load up the most recent revision. Then, selectively alter the source for an edited section by ID with pyquery and save a new revision.
The difference with this server-side approach is: Since every save starts with a load of the most recent revision and ends with a selective per-section change, it should help prevent clobbering changes made by other users also working on the page.
[1]: http://www.whatwg.org/specs/web-apps/current-work/complete/sections.html#outlines
[2]: http://pyquery.org/
Assignee | ||
Comment 1•14 years ago
|
||
Also, wanted to note for a future sub-task bug that enforcing <section>s for <hn> tags will take a bit of figuring out. It'll need to do things like:
* Never change the ID for an existing <section>, unless it's done by manual source edit.
* Wrap content following a new <hn>s in a new <section>
* Wrap sub-<section>s with <hn>s at a sub-ordinate level than the new <hn> (eg. <h3> vs <h2>)
* Stop wrapping content when an existing <hn> at the same level is encountered.
* Split and join <section>s for groups of <hn>s at the same level.
* Gracefully handle interesting split/join cases, eg:
* an <h1> is dropped into the middle of a group of <h4> sections and later removed
* large chunks of the content are cut/copy/pasted around the document
Comment 2•14 years ago
|
||
(In reply to l.m.orchard [:lorchard] from comment #1)
For a bit of jquery logic that does some of this, see https://github.com/mozilla/kuma/blob/b6d5a474a0309623a1273ba6c2d19061a3743589/media/js/wiki.js (esp. nextUntil, wrapAll, and unwrap.) Sadly, pyquery doesn't have nextUntil - though it has nextAll - nor unwrap built-in.
Comment 3•14 years ago
|
||
setting to 1.1 so we plan this sooner rather than later.
Target Milestone: --- → 1.1
Comment 4•13 years ago
|
||
Let's plan this better next Wednesday.
Updated•13 years ago
|
Target Milestone: 1.1 → 1.2
Updated•13 years ago
|
Target Milestone: 1.3 → 1.4
Comment 6•13 years ago
|
||
James and I created the new dependency bugs today based on planning discussion. Please review and add comments as needed.
Assignee | ||
Comment 7•13 years ago
|
||
Should probably break the dependency bugs down a bit more... I'd intended each bullet in comment 0 to be a full p=1 to p=2 bug of its own. I might take a poke at that if I stay awake for a bit more :/
Assignee | ||
Comment 8•13 years ago
|
||
Bumping this umbrella bug to 1.5, since there's more of this to be done then
Target Milestone: 1.4 → 1.5
Updated•13 years ago
|
Whiteboard: u=contributor c=wiki p=
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → lorchard
Comment 9•13 years ago
|
||
bumping to 1.6 for collisions but then we should be done!
Whiteboard: u=contributor c=wiki p=
Target Milestone: 1.5 → 1.6
Assignee | ||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Version: Kuma → unspecified
Updated•12 years ago
|
Component: Website → Landing pages
Updated•5 years ago
|
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•