As the subject line asks: anyone out there using this software to host a blog?

Aside from not having an easy way to embed images, it seems like it would be a good fit for non-flashy blogs (no sidebar navigation to other posts, etc.), e.g., developer diaries/blogs announcing and discussing new features. ("Tech notes" can also be used for announcement, but not discussion.)

Somewhat related: there was a recent suggestion for a "sticky" flag for posts, and that would be especially helpful for a blog-style forum, as would the ability to tell the forum "only admins may create new top-level posts, but others users may respond to existing posts." Stickiness doesn't sound too difficult to implement - it's "just a tag" on the post - but how much that may complicate generation of the article list, i've no clue.

Two big problems with using the forum as a blog: 1) there's no RSS feed for new posts

timeline.rss could be enhanced to use the option y=f to display forum posts. (Only when y=f. Not when not specified nor when y=all.)

Alternately, the basic mechanism of the email notification "digest" could be re-used for a RSS feed. One downside is that the "unsent" table is emptied when the email is sent.[1] This could be left as-is (if you don't mind only feeding today's posts); a separate "feed" table could be used, with the fields "nrid" and "date"; a "date" field could be added to the "unsent" table.

The "date" field, in either the "feed" table or the "unsent" table, would be used to expire old entries in the table.[1]

If the "unsent" table is enhanced to include a "date" field, the email notice generator would need to be enhanced to only include entries since the last time the notification was sent.

... with tech notes... The only way to browse through posts is the timeline, and in the timeline you can’t click on the titles of the tech notes to read them... the historical reason for this is that the "timeline comment" for tech notes might contain links

For tech-notes (and maybe wiki pages), maybe filtering out links in the comment for timeline display would be reasonable. (How many users actually put links in tech-note comments and how often? Would it really be that inconvenient to have to click through to the tech-note to be able to click on comment links?)

(Also, why don't tech-notes have L cards (titles)? like wiki pages do?)

Finally you could get discussion functionality right now by just creating tech notes and forum posts in pairs and adding links at each one to the other. But some automation of this would be fun

When a new tech-note is created, could auto-create a forum post with an I card referring to the new tech-note.

Alternately, auto-create the forum post and use an Attachment artifact to associate it with the tech-note.

The text of the post could be something like:

    Comments on [title](technoteID)

Where title is some (sanitized) prefix of the tech-note comment (or other approximation of title).

Either concept could also be used to associate forum threads with commits, wiki pages, tickets and maybe even individual files - like embedded docs.

---

[1] I think it makes sense to limit RSS items to only within a day or 2. Possibly keep some reasonable numbers of items and only expire old items beyond that number. That way the feed wouldn't be on empty "no news" days.

Aside from not having an easy way to embed images

In https://fossil-scm.org/forum/md_rules it says:

In-line images are made using

Has this been disabled and the forum/md_rules document not updated?

ability to tell the forum "only admins may create new top-level posts, but others users may respond to existing posts."

That would go a long way toward supporting a blog-forum.

Stickiness doesn't sound too difficult to implement - it's "just a tag" on the post - but how much that may complicate generation of the article list

Looking at forum_main_page in forum.c, looks like it would "just" be modifying a master-level SQL query to somehow add another 2 layers of ordering by stickiness[1] and original post date.

---

[1] I am thinking multiple levels of stickiness corresponding to importance. And probably will need a way to edit the level of stickiness/importance.

Have [in-line images] been disabled...?

No, but where you imaging that the link points? Without the proposed ability to add attachments to a forum post, you have no way to link to a new in-repo artifact, and the default CSP prevents linking outside the forum.

In-line images are still useful with wiki articles and tickets, which do allow attachments, plus embedded docs, where if you're allowed to edit the doc, you must also be able to check-in the linked-to image as well.

For those users that can check in files or submit/edit wiki pages and/or tickets, I suspect they could inline an image in a forum post.

(I thought stephan had check-in privilege.)

Everyone else, obviously, no inlines. (except for small images that can fit in a data URI)

Of course. And you're right that those of us like Stephan and I who can check files directly into the forum repo can get around this problem.

What this proposed feature solves is the ability for all the rest of you to attach images to your posts and refer to them inline.

It's pretty much a pure round-tuit issue: Fossil forums are built on the same infrastructure as the Fossil wiki, and it already supports attachments. So, someone's just got to want to implement it. It's probably not all that hard.

Sometimes the best features are that way. Here's a great recent example: small diff, huge benefit.

In https://fossil-scm.org/forum/md_rules it says:

i missed that. It's still a bit of a pain, though, in that you first have to upload the images somewhere else (and somewhere which allows arbitrary referrers to download the images - not all sites do, to avoid "bandwidth theft"), rather than being able to simply embed them in the document you're writing. i am not at all suggesting that the forum should allow us to upload images into our posts (That Way Lies Madness and Sync Bloat), but it is a convenient feature in some forums (e.g., BoardGameGeek and coughgithubcough).

That markup doesn't seem to work here:

![image test](https://wanderinghorse.net/gaming/painting/20180721_105304.jpg)

HERE--> <--THERE

Aha, the IMG tag is there but the browser console says: "Content Security Policy: The page’s settings blocked the loading of a resource at https://wanderinghorse.net/gaming/painting/20180721_105304.jpg (“default-src”)."

That topic may have been covered in other posts related to this feature, so i'll check there.

[1] I am thinking multiple levels of stickiness corresponding to importance. And probably will need a way to edit the level of stickiness/importance.

Fossil tags have always optionally supported a value, it's just not a commonly-used capability (bgcolor comes to mind as an exception), so a variable stickiness priority could be set as a tag value.

I had made a suggestion for "Sticky" flags for threads in /forumpost/261fa9e823 (The Forum Enhancements wish list post).

I thought I'd expand on that a little further here, and your comment on "tagging" a post.

Currently, in the the forum, the only metadata you can rely on for figuring out if a forum thread is worth reading is the title. In conventional forum-type software like phpBB (https://www.phpbb.com/community/) and Discourse (https://try.discourse.org/), forum topics can get tagged so it is easier to filter through a large volume of posts for topics that are of interest. drh had referred to associating forum posts with check in's, wiki topics, tickets, etc, which sounded great to me, but more generic categories that could show up in a side-bar in the forum page, like (bugs, announcements, releases, wish-lists) would also be good so it is easier to find a post already related to the topic you are going to post about and minimize the number of posts related to the same topic, or even give admins/moderators the ability to associate a thread with an existing discussion so that they can be neatly found in one place (ex. multiple threads related to a specific release of fossil, grouping of wish-list features related to the forums or tickets, associating a topic discussing a bug report with a corresponding ticket etc). Ultimately, I think this would help bring people interested in a specific topic to one place to discuss it. As a possible downside, it may isolate users who read a category of threads from other discussions to which they could contribute.

I've seen stickiness used in two contexts: for highlighting a thread (for suggestions before making a post, important announcements, etc.), or highlighting specific topics when there is a high volume of posts within a thread (ex. slashdot, reddit, arstechnica) if there is interest by the moderators in centering a discussion around that post. Alternatively, they may also allow upvoting of topics so they gain more attention during posting, but I have never been as much of a fan of that specifically because it changes the directions of forums from posting for discussion to posting for recognition.

(Disclosure: edited by stephan to hyperlink the referenced forum post.)

... but more generic categories that could show up in a side-bar in the forum page, like (bugs, announcements, releases, wish-lists) would also be good so it is easier to find a post already related to the topic you are going to post about...

Personally i'd like to see hashtag support added to the forum, independent(??? maybe?) of fossil tags (or maybe implemented on top of fossil tags). That would give us the option to build a tag cloud users could filter the forum with. The main advantage, perhaps, over the search feature is that it gives the user an idea of which topics there are without them having to think of the search terms themselves.

Clicking on a #hashtag within a post would/should take the user to the filtered view of posts containing that hashtag (normalized to lower-case, because users often type hashtags using different casing). Markdown's headings seem, at first, to collide with #hashtag syntax, but headers are supposed to have a space after the # (presumably for this very reason). That said, fossil's markdown does not require a space there, which means it's incompatible, without a backwards-incompatible change, with my desire for hashtag support :(. #FirstWorldProblems

normalized to lower-case, because users often type hashtags using different casing

People often misspell hashtags differently. Also, people often use different terms for the same thing. So I usually prefer predefined tags over poster defined. the downside of that is often the needed tag isn't predefined.

fossil's markdown does not require a space there, which means it's incompatible, without a backwards-incompatible change, with my desire for hashtag support

On the one hand, it is a non-complience.[1] On the other, how many documents would break? Perhaps a transition period where Fossil (somehow) warns about the missing space before starting to parse #hashtags.

Another option: #hashtags could be put in other places, for example, after the text of a header:

# level 1 heading #hashtag

Markdown/CommonMark don't allow that construct, but do allow # after the text of a heading. So, that is a possible place to "hide" #hashtags.

But, Fossil's Markdown currently will include #hashtag as part of the heading.

However, I strongly doubt more than a few documents would break.

Parsing #hashtags after a heading seems a reasonable compromise.[2] Not sure if parsing them in other text is a good idea.

---

[1] Example 34 in the spec shows a #hashtag and the text above provides some rational for the space after the #.

[2] But I still think a more formal forum tag mechanism would be better despite the limitations of predefined tags. I think the benefits of standardized tags outweigh the limitations.

There have been a few solutions already implemented for handling metadata in markdown that do not use hashtags. Usually it gets placed at the top of the documents. See this Stack Overflow Discussion. There could be a metadata field in this fashion called tags, with tags separated by commas.

iA Writer 5 for iOS also implemented hashtags in text-based documents iA Writer 5 review, See section titled Hashtags. Bear for iOS also has something similar, but I have never tried these out. Hope this helps in brainstorming or providing for some inspiration.

By the way, is there any chance some buttons could be added to the right of the Markup Style to make it easier with users unfamiliar with a given markup style (ex. Fossil Wiki) to add the characters needed for adding bold text, links, headings, etc? Is this request something better added as a ticket? If so, I was not quite clear on how to add a ticket from the website.

Is this request something better added as a ticket? If so, I was not quite clear on how to add a ticket from the website.

That's actually intentional! Early on the in the project we found the mailing list (now the forum) to be a better ticketing solution for the scale/scope of this particular project. Tickets tended to be requests for help, rather than bug reports, and that was never the intended purpose of this particular project's ticket system. (That's a quirk of this project, though - the ticket system is used quite a bit in sqlite (Fossil's omni-relative (sibling/parents/aunts/uncles/cousins, all in one)).

i suspect that it's only a matter of time before someone who's itched enough by it integrates the wiki's WYSIWYG editor into the forum. (If that's even still a thing - i only know of it indirectly, but never used it.)

When in doubt, select the Plain Text format - that's what i used in the forum until i finally gave up on my dislike of markdown (which was admittedly due to its deep association with my Arch-Nemesis Git, rather than any failing of MD itself). There are really only a few markdown things one needs to know in order to use it fairly effectively in the scope of the forum: italic and direct links: https://fossil-scm.org. Everything else is just "bonus points."