aboutsummaryrefslogtreecommitdiff
path: root/README.md
blob: de5573524086743c778ce4ae3a6645adffe489c7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
# NAWP (NAWP Ain't WordPress) -- Minimal Blogging Engine in Chicken Scheme

This is very much a work in progress, and not everything is guaranteed
to work just now.

NAWP stores content in an sqlite database.  It is dynamic, not a static
site generator.  It is supposed to run as a CGI script.

## Why Would Anyone Actually Want to Use it?

Here's a short list of reasons.

* Minimum dependencies.  No PHP, no external RDBMS.  Just the binary and a CGI-capable web server.  If you pass `-static -L -static` on the `csc` command line when building it, you can even have a fully-static binary with no external dependencies at all.
* Because you don't need the features of a more capable platform; you just want a publishing tool with as little friction as possible.
* Because you know and love Scheme.  You can reason about it and fix it when it breaks.  Rest assured, it will break.

## Installing

Here is a list of the external Scheme libraries ("eggs" in Chicken Scheme parlance) that NAWP needs:

* anaphora
* atom
* crypt
* lowdown
* matchable
* rfc3339
* sql-de-lite
* srfi-1
* srfi-13
* sxml-transforms
* uri-common

You'll also need a CGI-capable web server.  I use lighttpd with mod_cgi
enabled.

Copy `nawp-site.scm` to `/etc/nawp-site.scm`.
Edit `/etc/nawp-site.scm` in your text editor of choice, customizing the
variables `blog-base-uri`, `blog-title`, and `blog-description` to taste.

Once the dependencies are installed, run:
```csc nawp.scm```

Copy the resulting binary to your cgi-bin directory.

Next, make the database:
```sqlite3 /var/lib/nawp/blog.db < schema.sql```

Make it readable and writable by the user the CGI script will run as.

Add a new user.
Run the script as the owner of the DB, with the adduser argument.
For instance, to add a user named `chris`:

    doas -u dbowner /path/to/nawp adduser chris 'Chris Brannon'

You'll be prompted for the password.  Unfortunately it'll echo to stdout
for now.  Fixing that is going to require a little yak-shaving.
Finally, you'll want to do some web server configuration.
Here's a sample configuration snippet for lighttpd:

    server.modules += ("mod_cgi", "mod_redirect", "mod_rewrite")

    # Redirect ^/blog$ to /blog/, so that relative links resolve properly:
    url.redirect = ("^/blog$" => "/blog/")

    url.rewrite-once = (
      "^/blog/$" => "/cgi-bin/blog",
        "^/blog/(.+)$" => "/cgi-bin/nawp/$1"
    )

    # Assuming you want the old-school Apache-style /cgi-bin directory like I do:
    $HTTP["url"] =~ "^/cgi-bin" {
       cgi.assign = ( "" => "" )
    }

## Using

To make a post, visit https://yourdomain/blog/post-form and fill in the fields.

Just visiting https://yourdomain/blog will show the most recent posts.
There is an atom feed at https://yourdomain/blog/feed.atom

## Contributing

To contribute, you can push to branches in this repository that have names
starting with `patch_`.    I borrowed this idea from Tim Vaughan, author
of `elpher` et al.  The difference is that Tim Vaughan uses the `git://`
protocol, where I use `https://`.

Note that you need to be using the canonical clone URL to push:
`https://the-brannons.com/git/nawp`

I forgot to disable cgit's "dumb HTTP clone endpoint" feature, so if you
cloned with a `/cgit` URL and want to contribute, you should do

    git remote set-url origin 'https://the-brannons.com/git/nawp'

## Roadmap / TODOs

I plan on adding an API.  It will probably be the metaweblog XML-RPC
API used by WordPress, or a slimmed-down version thereof.  There are
command-line tools for blogging with WordPress, and it would be nice to
be able to use those with NAWP.

I may add Gemini support.  I haven't quite decided how I feel about Gemini.
At first blush, it seems quite compelling and worth the effort.

I may add support for alternative input formats like asciidoc.
More likely, I'd consider replacing markdown with asciidoc and sticking
to one single input format.
Markdown is useful, but it is also poorly specified -- excepting CommonMark -- and underpowered.

Idle speculation: I wonder how hard it would be to add SXML as an output format to pandoc...

A comment system would be nice.