Matt's Dev Log

Got routing working. There's an issue with logging in, but I think that's because the site isn't on HTTPS. Need to add certificate generation to test this theory.


Finally got automated database creation going from the side. So when you sign up via the for Teams flow, it marks the account as a “Teams” account, and creates a new database and all tables.

Now that this is running non-locally, I can finish up the last part: the multi-WF application that connects to the different databases and routes requests to the correct host.


Essentially, I need to be able to start up a server that tracks multiple WF instances and load configurations from the database instead of the filesystem.

I was smart to create the separate writefreely package (I didn't do this originally for, but there's still plenty to untangle to support this use case.

Right now, preventing a mysql.Register() call in the writefreely package is the most important.

This work is being tracked in issue #102 on Github.


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.

With a growing team of core #WriteFreely developers (#wfdevelopers), we're starting to document everything needed to actually work on the application. It'll be a long process, but it's underway.

Official documentation lives in Markdown files in the writefreely/documentation repo. Current work is done on the develop branch (contributions welcome).

Most recent addition, thanks to @sandrockcstm: an explanation of the database schema

I got the number of open issues on WriteFreely down below 10 again today, after reaching its high of 13. After some time maintaining this project, I think keeping this number low is actually kind of important.

  • We tell everyone that Github is only for reporting bugs, and that we're very responsive there. Keeping this number low backs this up.
  • A low number of issues makes it easy for others to find bugs they might've encountered, as well.
  • Keeping this number low signals that the project is active and moving forward.

For a #FOSS project like ours, with a strong vision / direction to follow and core developers pushing that forward, I'm finding this setup really works well for us. We gather input on our forum, turn that into long-term plans in Phabricator, and adjust to real world usage on the platform that's closest to it all, Github.

Here's how you might create a new page for users in WriteFreely.

In this example, assume you want to create a new Import page based on the current Export page template:

  • create a copy of templates/user/export.tmpl named templates/user/import.tmpl
  • change define "export" on the first line to define "import" (the name here should match the filename between templates/user/ and .tmpl
  • duplicate the viewExportOptions() handler func in account.go, changing it accordingly
  • add the import page route in routes.go

#WriteFreely #wfdevelopers

Single-user issues so far:

  • “Public” option shows on blog Customize page (should never be there in this mode)
  • Pinning a post links to /matt/about instead of /about
  • Instance-level About page shows at the bottom of user pages (should never show in this mode)
  • Drafts page shows “Find your blog posts from the Blogs page.” (should never show in this mode)

I'll use this blog to share quick, unedited thoughts about development behind WriteFreely and simultaneously test out WriteFreely when running in single-user mode — a mode I don't get to test often!

Stay tuned.