Matt's Dev Log


I’ve just updated this instance to the wysiwyg branch of WriteFreely, where we have a new what you see is what you get editor to choose from. Work on this editor is in progress on #383.

I’m now writing with that editor. (You can view the raw output here.)

It’s built on ProseMirror, and gives you a more classic writing experience while converting everything to Markdown (as WriteFreely understands) behind the scenes.

It also auto-saves, just like any other standard editor that comes with WF. I’ve refreshed the page a few times (saving everything to the clipboard first) and it’s always sucessfully loaded. This is the most basic requirement for our editors, so that’s great!

Some issues

It does seem to insert magic quotes in the editor ( instead of “), which is not what we want — that happens automatically on the rendering side, which is good (it seems to do it for em-dashes too).

I’m not sure if our shortcodes will work, like <!—more—> — especially with the auto-em-dash stuff.

Also, the scroll bar is right next to the text instead of outside the text area padding, which is un-ideal, but fine.

Poetry\ probably\ b r e a k s\ (It doesn’t completely! But the spaces before “breaks” gets removed when going back into the editor to update the post.)

Ctrl+K should add a link to the selected text. Also “Target” in that modal is confusing even to me. Hopefully we can fix that.

The editor doesn’t render HTML.

The editor inserts a backslash on the following before the first # symbol, preventing the hashtag from activating.

#WriteFreely #wfdev

Get future updates via RSS and ActivityPub:

WriteFreely allows instance admins to choose the writing experience their users enjoy. This guide will walk you through building and integrating a new editor.


To import posts into WriteFreely from an outside platform, it is ideal to get all articles into a JSON document that looks like the following, where each object in the array is a complete article:

    "title": "Optional Post Title",
    "slug": "optional-post-title",
    "body": "Entire post content, in Markdown or HTML, including any images and #hashtags.\n\nNote: newlines should be preserved in this field, even when using HTML.",
    "font": "serif",
    "lang": "en",
    "rtl": false,
    "created": "2006-01-02T15:04:05Z"

These field names map directly to the API — you can read details in the API documentation. Otherwise, a few notes:

  • The slug should contain only alphanumerics and hypens. Any invalid characters will be automatically converted.

  • The body property should include all original markup (HTML) and Markdown, with newlines (WriteFreely respects and requires newline literals). Note: Getting as close to Markdown / plain text as possible here is ideal, as it provides the best editing and data export experience. But WF will render HTML.

  • Include any categories or tags as #hashtags, inline in the body. To make it look nice, you might append any to the end of the post, separated from the post body by \n\n.

  • Supply a created time, in the RFC3339 format (shown above) and converted to the UTC timezone, to preserve original publish date and time.

In this format, we can trivially loop through the array of objects and POST each one directly to the WriteFreely API — creating either drafts or blog posts.

#WriteFreely #import #dataMigration

Get future updates via RSS and ActivityPub:

I took a bit of a break from #WriteFreely development over the past few months, after our v0.12 release. Now I'm back to it.


Our next release of #WriteFreely, v0.12, is shipping with OAuth 2.0 support! This will make it even easier for people to join your instance, and use WriteFreely as a complement to other tools.


Right now, we have a pause on major features in WriteFreely. I've finally started to work through the backlog of outstanding pull requests, some of which were from mid-2019, and now am getting to more of the polishing side of things. So coming soon, there will be some small new visual changes in WriteFreely /, particularly that affect user blogs.

  • Dates on blog posts. It's been missing for years. They'd show on the blog home page, but not blog posts. Well, this is no longer the case. Soon, posts on blogs that use the Blog display format will consistently show dates both on their home page and individual posts. Other display formats will continue not showing dates, because that's exactly what they're there for: not showing dates.
    • Also, dates are now correct, relative to your device's timezone!
  • <table> style. These elements were previously unstyled. Now they'll have some improved, basic styling that you can easily override with custom CSS. See #194.
  • Consistent user page headers. User pages (Blogs, Drafts, Account Settings, etc.) were all over the map with their headers. I'd start using a new style on new pages and not update the old ones. Well, now that's fixed in #262. users will notice this change is already live.
  • Slightly more line height. We've added 10% more space between lines of text. It's perhaps too small to really notice, but large enough to make a nice improvement. Changes in #263.

On the admin side, we're redesigning the dashboard to make it much more user friendly, and optionally less technical, in cases where an instance is in a hosted environment and the admin doesn't care about getting into the weeds. See #264. We need this change in for Teams, but it should also prove helpful for other WriteFreely hosts.

Particularly since these are visible changes that affect users, we want your feedback! Please jump into those pull requests on GitHub, try things out, and let us know what you think. We want to be sure people are happy with these upcoming changes before they get released to everyone.

#wfdev #design #WriteFreely

Get future updates via RSS and ActivityPub:

After several months of work, we released #WriteFreely v0.11 today / last night. This included one last bugfix I found while testing, #205 / Fix URLs in CSV exports.

The team caught some issues with templates with during our review process before merging, but then introduced new bugs with the attempted fix that weren't caught during further review. The new bug only affected instances configured for single users (not multiple users), but if a blog had any pinned posts, all blog rendering would fail and display our silly “500” error text instead of the author's writing. In other words, this wasn't an edge case, but the software catastrophically failing for a decent subset of users.

Admittedly, this is a configuration we don't currently test super-thoroughly — but nonetheless it got merged with the rest of the intended fix.

I quietly released v0.11 around 3am Japan Standard Time, and within two hours a user upgraded their instance and encountered our newly introduced bug, filing an issue for it (#207).

The bug was easily fixed when I woke up (#209), but this incident — a large release after several months, completely botched for a subset of users — made it clear we need to change how we do things in the future.

Going forward, we'll put out a Release Candidate or two before all major or minor releases. The goal will be to get more eyes on the code we're about to send out, so that we might catch silly errors like this before putting our stamp of approval on a new release.

In the meantime, skip v0.11 and enjoy WriteFreely v0.11.1! This time, you won't regret the upgrade!

Get future updates via RSS and ActivityPub:

We're working on supporting #ActivityPub mentions in #WriteFreely now (T627). The work is in progress, and last post didn't work.

Testing to see if gets this.

Let's see.

Get future updates via RSS and ActivityPub:

Testing #ActivityPub #mentions in #WriteFreely now (T627). Apparently Mastodon doesn't honor mentions in Articles (they only work with Notes — we've opened #12129 to fix this), so won't work. But Pleroma does honor them, so should work just fine.

Let's see.

Get future updates via RSS and ActivityPub:

Now that we're growing past one core developer, we've moved #WriteFreely development off of master. As I mentioned on Mastodon:

Things are validated. Now all core development is done on feature branches off of develop, with code review before merging. (So, more validated than the master branch used to be.)

Of course, there may be some larger features that get added over several pull requests (thus might need fixes / changes), but in general we're trying to avoid that.

Get future updates via RSS and ActivityPub: