= Discussing Advanced Wiki Operations = [[PageOutline(2-4)]] The Trac wiki currently lacks some advanced features you can find in more mature wikis, operations like '''rename''', '''copy''' and '''merge'''. This will summarize and expand the proposals found in #1106 and other places. == Operations === Delete By default, mark a page as deleted instead of purging it from the db (#9222). === Rename Basic renaming was implemented for 0.12, but this feature can be enhanced further. See WikiRename. === Copy Mainly interesting if supporting ''batch'' copies, a.k.a. Subversion style branching. === Merge Note that there are several kinds of merge. The one which is directly in line with the ''advanced wiki rename and copy operations'' is the operation consisting of **merging two pages into one**. This can also be seen as renaming a page to an ''existing'' page, which is currently forbidden. That operation can be used to consolidate several small topics into one umbrella topic, or for merging two synonym pages into one, etc. In any case, this would involve to solve the following issues: - merge the two wiki texts (#152). The existing interface for this is rather minimal, it only shows the differences without the possibility to say which side(s) should be kept. - bringing over the attachments. We should also take care of possible conflicts at that level. The attachment `rename` methods from WikiRename will also be relevant for this operation - merge the two lines of history. Maybe simply concatenate the two lines? 1. v1 page a 2. v2 page a 3. v3 page a 4. v1 page b (merged in) 5. v2 page b (merged in) 6. v6 page a (with b merged in) The diff between 3. and 4. would be meaningless, but besides this, it should be enough. - merge the potentially conflicting fields besides the wiki text. Fortunately there's only the read-only flag, shouldn't be that hard ;-) But well, there's #695, #3911. The other kind of improved merge is simply the resolution of conflicts in case of concurrent edits (#152). An improved interface for this situation should actually also handle the different points listed above (except merging the two lines of history). Note that this advanced conflict resolution method would also benefit to ''other'' kind of resources, in particular #7145 (not to mention the possibility to merge tickets, in case of duplicates for example - #3006). === Diff Compare different Wiki pages * I can see this useful for Trac itself, comparing 0.11 and 0.12 versions of a page. Current wiki diff link is: {{{ http://trac.edgewall.org/wiki/TracLinks?action=diff&version=76&old_version=75 }}} Possible suggestion: {{{ http://trac.edgewall.org/wiki/TracLinks?action=diff&version=76&old_page=wiki/0.11/TracLinks/&old_version=75 }}} But along with the TracDev/Branches/WikiBlame idea (and even the copy operation), I can't help but note that this would come for free if we had #1132 support ;-) Now that we have MultipleRepositorySupport and "unlisted" repositories `(hidden = true)` for those who would prefer that ancillary repository to remain invisible, this is increasingly becoming a more realistic option. (rblank) I agree with that. Even more, I would like to be able to have the source code, wiki ''and tickets'' in a single DVCS repository, so that I can take the whole thing on the road. Something along the lines of [http://www.fossil-scm.org/ Fossil]. I guess the most difficult part is creating a GUI for merging that is simple enough. (cboos) See also related discussion in DistributedTrac and above, in [#Merge]. === Edit ==== Section Editing Many wiki's allow you to edit paragraphs or sections while leaving the rest of the page un-edited, like [http://en.wikipedia.org/wiki/Section_editing#Section_editing in Wikipedia], for example. One idea could be to allow for double-click editing, with the smallest section under the mouse being extracted for edition (e.g. a paragraph, a list item, or the content of a #!th block). From that edit interface it should be possible to widen the scope of edition, gradually taking more context (the surrounding section, or list, or table, up to the whole page). This can be achieved by retrieving the current "location" trail. Special care should be taken with transcluded content. See also #1024. ==== Comments per paragraph Maybe this does not belong in Trac and should be plugin instead - but the neatest way of collecting user feedback I have ever seen was the Django book http://www.djangobook.com/about/comments/ (mmm) I think it makes sense to think about a generic comment system, as wiki pages (or sections) are not the only parts of Trac that could benefit from comments / annotations. We have also #2035, commenting on changesets and sources. Commenting on attachments (patches) would be a similar feature. And although tickets have "comments", those are in fact more changelog messages, and as such allowing comments on them could also make sense. (cboos) All these "comments" are snippets of Wiki text that are attached to a main resource corresponding to the [WikiContext context] of that text, and they are attached to a specific place in the main content of that context (the location trail sketched above in [#SectionEdition]). See also #4279. == User Interface The advanced operations should not clutter the wiki page. Instead of ''Copy'' and ''Merge'' buttons coming in addition to the ''Rename'' one, maybe a single ''Advanced...'' button would be preferable. This could go to a single page containing the different forms, one for each advanced operation. Plugins could add their own advanced operation there. === Better Hierarchy Navigation In 0.12 we introduced the wiki page name ''path'' trail, visible in the top left corner of the page, which makes it easy to quickly navigate to any ancestor (#8857). It would be nice if this could be used to navigate to children and, perhaps, siblings: - if there are children, the path trail would end with a `...` link, leading to a page list (URL could be `/wikilist/`). If Javascript is enabled, the link could be disabled and replaced by an action that would query that same list with an XHR and display a selection list (or a more elaborate form of menu; but a simple