Yep that's perfect, thanks 👍 That way anyone can make changes if needed. I've also changed that default value in the "Create Task" form.

Awesome. Plenty of people asking about that now, so that'll be good. If you want to take the charge on that one, please feel free!

Still need to describe what each setting does, but this is nearly complete.

I updated the task's tag and changed it to be editable by All Users. Is that the right group?

Great point. This should be relatively easy, so maybe we can get it into the next release.

This is done. The relevant commits that resolved it:

Oh, and I believe that adding PostgreSQL support will be much easier than SQLite. It should be able to use schema.sql and all of the MySQL SQL commands unmodified. The only bit that it'll require is a new connection block in the initial setup.

Ooh. I look forward to seeing this implemented, since I currently have a Blogger blog.

Some feedback from my initial multi-user testing: so far almost everything looks solid, this is really good work! Only issue so far is something weird going on with scheduled posts. They correctly show as "scheduled" and don't show up for non-auth'd users. But once the published time has passed, the "scheduled" badge correctly drops for auth'd users, but the post doesn't show up for non-auth'd users like it should.

Awesome!! I'll give it a thorough testing this weekend in various configurations and let you know how it looks.

@matt OK, with the latest commit on the sqlite-support branch, SQLite support is working.

I have a working variation of schema.sql (called, appropriately enough, sqlite.sql) for SQLite.

Ah, gotcha. I thought there might be some differences when I was reading through this fork with sqlite support.

As an example, SQLite doesn't support the SQL function NOW(). It also only has five data types - NULL, INTEGER, REAL, TEXT, and BLOB. Yes, that means boolean values are stored as full INTEGERs.

So as I've started testing this, I've discovered there is a vast chasm of differences between normal SQL and SQLite SQL. I'm working on the logic to handle both.

The working branch is here: https://github.com/writeas/writefreely/tree/sqlite-support

Ok cool 👍 let me know if you need anything along the way. Excited to get this in!

Actually, I retract my previous statement. I was thinking in terms of integration tests, not unit tests - the current pattern is fine.

Nice! I'm all for adding unit tests for database funcs -- especially with different databases, I agree we should make sure they work consistently.

I started working on a proof of concept for this yesterday morning. In the process, I noticed a couple things.