In short, no (to both questions).

The wiki sort of fell out of favor once "embedded docs" were developed, as they can do everything the wiki can (except online edits) and are "first-class members" with regards to the the SCM features, participating in branching, renaming, etc. Though the internal architecture fundamentally allows for wiki pages to do so, their status as "non-files" means that many of the SCM features cannot be applied as-is, with existing code, to them, and (since the addition of embedded docs) there's never been a compelling reason to expend the effort.

That said: patches are generally well-received (but it would not be a small patch).

(Edit: this was posted by stephan. A login glitch led me to believe i was logged in at the time of posting. It's possibly related to Richard's note about the login group change, but FF for Android offers no way to clear cookies for a single site, so i can no longer log in via that platform.)

Another consideration is that although wiki content is versioned, it isn't treated as a "peer" to the versioned file content. If I say fossil up abcd1234 and then fossil ui, I still see the "tip" version of all of my wiki articles, not the version as of the check-in date of [abcd1234].

This fact means the wiki is best used for "evergreen" content, meaning that the current version of the wiki is always the best version for all cases, across all branches, across all time. If that condition is not true for your wiki content, then you should probably be using embedded docs, not the wiki.

That in turn means that wiki docs tend to build up more inertia than embedded docs: because their content is good for all time across all branches, there's a much greater chance that outside sources will make links to them than to random versions of an embedded doc file, which means you have a higher chance that you have external links pointing to your wiki docs, depending on the name of the wiki to not change.

Renaming wiki articles is, plain and simple, not a good idea.

That is useful information, thank you both!

But I'm at loss here. I use the wiki as automatic synchronized personal / desktop wiki (fossil ui is really useful!). And it not only fits nicely, it is an light integrated solution for so much more..

The last time I tried to use embedded docs I ran into problems because of no easy linking inbetween and no editing via the ui..

Are there plans to enable editing the embedded docs via the web ui?

Are there plans to enable editing the embedded docs via the web ui?

In short, no. The reason is simply that checking in changes to file content requires having a checkout. The file-checkin process (as opposed to the wiki/ticket "checkin" (edit) processes) is tightly coupled with both a checkout db and command-line-level interaction. There's no simple/straightforward way for the checkin process to be modified to (A) work without a checkout and (B) handle the required interactivity in both CLI and WWW modes. By interactivity i mean prompts like "auto-sync failed? Continue?" Warnings, as well, are all hard-coded to go to the console (changing that would be the least of the troubles, though).

That said: if this were to itch someone enough that they'd overhaul fossil to accommodate it, i'm quite certain that many users would hold a parade in their honor. The ability to check in file content without a checkout db would allow us to upload any file content via the web (a not-infrequently-requested feature which, at a technically level, amounts to the same thing as editing embedded docs online). That would bring with it new usability problems, like how to map uploaded content to existing files, but those are peanuts compared to modifying the architecture to be able to support that.

About wiki attachments: here's a thread from the old mailing list which provides at least one solution (requiring knowing the UUID of the attachment):

https://fossil-users.fossil-scm.narkive.com/WzVBRzlv/questions-about-wiki-linking-to-non-branch-artifact-ids-images

The solution is demonstrated and confirmed in the bottom-most responses.

(Edit: typos. Gotta stop being so pedantic. Just let it go... let it go... just think of it as an immutable email...)

No fast/easy way, at least for me (subpar programming skils).

If wiki pages are identified via their name, can I rename them with a raw sql command, and preserve any attachments to that page?

And thanks for explaining these details!

That question is based on a common misapprehension about the way Fossil works. People see "SQLite" and think its content is all held in relational form as SQL tables, but virtually all of its content is actually block-chain/NoSQL-structured, with the properly relational parts of a repo DB being just lookup tables into that block-chain.

(Reconstruction of those lookup tables is a large part of what Fossil's doing in its rebuilding stage while cloning a repo.)

So no, you cannot rename a wiki page in SQL, because the wiki page name is not a SQL column. There may be a SQLite column holding wiki page names (I haven't bothered to look) but if so, it's a lookup table pointing at a Fossil artifact blob holding the actual data. Changing that table would not affect anything permanently; you'd lose the change on the next fossil rebuild.

no editing via the ui..

There are many graphical Markdown editors. If you're on macOS, my current favorite is Byword.

There are also quasi-WYSIWYG editors; most programmers' text editors have some way of styling Markdown to give something like the flavor of a GUI editor, which suffices as a preview of its final rendered form.

Finally, you can pair an external editor with Fossil UI through use of the ckout special name. You have the file open in your editor of choice, then you can Alt-Tab over to the browser window and do a reload to see how Fossil will render that file. This saves you from inadvertently checking in a change to a file that Fossil will render badly, a fairy common occurrence in editing Markdown and Wiki text, since there's so much dialectical variation to keep in mind when working with those languages.

How would you handle (and link) attachments from wiki pages within embedded docs?

You just store the files in the repo normally and then use Markdown, Wiki, or HTML syntax to link to those files using Fossil URLs. (Or things which can be turned into URLs, such as check-in IDs.)

As an example, take a look at the Demonstration section of my "Image Format vs Fossil Repo Size" article, which links to a Juypter notebook stored right alongside the article's Markdown text file. The same article also embeds an SVG chart also stored right alongside it.

Thank you stephan, thank you wyoung!

I'm going to migrate from wiki pages to embedded docs:

• hunt down all attachments (via timeline since there seems to be no simple way)
• store attachments as unversioned content (since these are mostly pdf and maff)
• export wiki pages into files
• use the exported wiki files as starting point for embedded docs

With this I'll loose the ability to edit the "wiki" via the web ui, but since this is a desktop wiki scite and vim are already here.

Linking in between embedded docs works relative easy with [page](/doc/trunk/pagename.md).

export wiki pages into files

In the off chance that you don't know this already: the wiki CLI command can do that.

That was the easy part, but the attachments were nasty since one can only add attachments via cli but not export...

The attachment command also does not support attachments to tickets.