this changed the CLI flag to use the username instead of the userID
leaving the underlying database function as is.
also now posts are all deleted with no option to skip as this is likely
never needed.
CLI only but backend supports calls from app.db.DeleteAccount already
takes --delete-account user_id_number with optional --posts to also
delete posts. if --posts is omitted all user posts will be updated to
anonymous posts
includes cache of latest version and page to view if updates are
available with a link to the latest update's release notes and a link to
check for the latest update now, refreshing the cache manually.
This adds a new config value: `chorus` that signifies an instance is
more about the Reader view than individual blogs / writers. When
enabled, user navigation will show on all pages, including About,
Reader, and Privacy (ref T680).
It also uses different collection templates that keep the instance-wide
navigation at the top of the page, instead of the author's name --
again, branded more for the collective than the individual.
Ref T681
This adds a new config option in the `[server]` section: `autocert`.
When true, WF will automatically generate certificates instead of using
ones from the provided cert path. However, all generated certificates
will be stored in the configured `tls_cert_path`.
Ref T542
This enables admins to customize their landing / home page via the Admin
dashboard -- including the text at the top of the page and the section
below it. It keeps the current default text, falling back to it if the
user hasn't overwritten it.
Ref T565
Use the split argument list (slice) just for validation purposes
as it's substantially easier to do `.contains` in a string instead
of a slice. As such, pass the `configSections` arguments to
`Configure()` and check the existence of each one before showing
the options to the user.
An empty argument list is replaced by "server db app" so everything
is there negating the need to check anything else in `Configure()`.
In the same vein the default is "server db app".
The parsing is done in `app.go` alongside the other flags instead
of `main.go` as described in T657.
Add --sections flag to app.go according to T657, parse them
into a string array (check for invalid arguments and abort)
and pass them to Configure(). For now Configure() doesn't do
anything with them yet.
Previously, this would only run when configuring an instance for
single-user usage. Now it'll also run when configuring for multi-user
usage.
It also adds a log when the database has already been initialized.
This moves `hostName` to the `Collection` struct, where it's needed. The
field is populated after successful `GetCollection...()` calls.
This isn't the cleanest way to do things, but it accomplishes the goal.
Eventually, we should accept the AppCfg to `GetCollection...()` calls,
or make them `App` methods, instead of `datastore` methods.
Ref T613
- Adds a new interface, Apper, that enables loading and persisting
instance-level data in new ways
- Converts some initialization funcs to methods
- Exports funcs and methods needed for intialization
- In general, moves a ton of stuff around
Overall, this should maintain all existing functionality, but with the
ability to now better manage a WF instance.
Ref T613
This ensures the writefreely pkg can be used in other applications that
need to load mysql themselves -- this can be done by building with the
tag: wflib
Ref T613
This adds a new `landing` value in the [app] section of config.ini.
If non-empty, unauthenticated users on multi-user instances will be
redirected to the path given there.
This closes T574
This exposes setup and admin functions in the writefreely package, and
uses them in the main application, initialized by the flag parsing that
now happens there.
This is the first step towards making `writefreely` usable as a
standalone package.
This makes it so we can keep all schema changes in the `migrations`
module, instead of adding them there *and* in the schema files. It
fixes#92 and should prevent these kinds of issues in the future.
Now admins can choose a title for their About and Privacy pages; now
editable through the instance page editor.
This adds `title` and `content_type` fields to the `appcontent` table,
requiring a migration by running `writefreely --migrate`
The content_type field specifies that items we're currently storing in
this table are all "page"s; queries for fetching these have been updated
to filter for this type. In the future, this field will be used to
indicate when an item is a stylesheet (ref T563) or other supported
type.
Ref T566
This adds a "Pages" section to the admin part of the site, and enables
admins to edit the pre-defined About and Privacy pages there, instead of
on the dashboard itself.
It also restructures how these pages get sent around in the backend and
lays the groundwork for dynamically adding static pages. The backend
changes were made with more customization in mind, such as an
instance-wide custom stylesheet (T563).
Ref T566
Previously, our hashtag parser would indiscriminately replace
hashtag-like text with hashtag HTML -- including in places it shouldn't
have, like inside code blocks. Along with the v1.7.0 changes to
writeas/saturday, this fixes that and closes#6.
As a bonus, strings of #spaceless#hashtags#in#a#row are now rendered
correctly.
...instead of doing os.Exit(). This allows the func to be used in many
places (as it is) and handle success results in different ways.
Previously, this caused the single-user configuration process to exit
prematurely. This fixes that and closes#71.
This adds new configuration values that specify the parent directory of
application resources:
- templates_parent_dir
- static_parent_dir
- pages_parent_dir
- keys_parent_dir
For any values not specified, the application will default to the
current directory.
This closes T560
This adds new configuration values that specify the parent directory of
application resources:
- templates_parent_dir
- static_parent_dir
- pages_parent_dir
- keys_parent_dir
For any values not specified, the application will default to the
current directory.
This closes T560
This fixes the --config step so that when setting up a single-user
instance for the first time (and creating the admin user as part of the
process), the database is automatically initialized before creating that
user.
This removes the need for the --init-db command after --config when
setting up single-user instances.
It fixes#59: "no such table: users" error during the --config step on
single-user instances that haven't previously run --init-db.
SQLite doesn't have an `RLIKE` function, so the query for hashtagged
posts was failing before. This adds a `regexp` function to SQLite and
correctly retrieves all posts on a blog with the requested hashtag.
This closes#55
This adds a new `sqlite` build tag that you should include only if you
want SQLite3 support built in. Both `make run` and `make release` create
builds with SQLite included.
This includes schema.sql and sqlite.sql in the release binary, so they
no longer need to be included in the release archives. This reduces the
number of files extracted, but otherwise leaves all functionality as it
was -- especially the --init-db flag.
Ref T536
This adds a "Reader" section of the site for admins who want to enable
it for their instance. That means visitors can go to /read and see who
has publicly shared their writing. They can also follow all public posts
via RSS by going to /read/feed/. Writers on an instance with this
`local_timeline` setting enabled can publish to the timeline by going
into their blog settings and choosing the "Public" visibility setting.
The `local_timeline` feature is disabled by default, as is the Public
setting on writer blogs. Enabling it adds a "Reader" navigation item and
enables the reader endpoints. This feature will also consume more
memory, as public posts are cached in memory for 10 minutes.
These changes include code ported over from Read.Write.as, and thus
include some experimental features like filtering public posts by tags
and authors. These features aren't well-tested or complete.
Closes T554
This allows users to load a different configuration file instead of the
default config.ini. It works in combination with other configuration
actions, like --config and --create-config.
This enables automated user creation by running:
writefreely --create-admin username:password
It will fail if an admin (first user) already exists, which makes this
suitable for use on both for single- and multi-user instances.
Closes T544
A quick test with ApacheBench revealed that SQLite really can't handle
multiple concurrent requests with the default settings, due to a locked
database. This fixes that by following the suggestions here:
https://github.com/mattn/go-sqlite3#faq
Testing with ab -n 100 -c 5 http://localhost:8080/blog/post shows that
this fixes the issue. But we could improve performance by reducing
writes, like what's mentioned in T545.
Part of T529