# Hugotator

Web Content Management System on top of Hugo and git for non-git and non-markdown folks.

The goal is to replicate the ease that someone have to use a classic blog CMS like Grav or Wordpress.

## Features


## Philosophie

- Avoid too much dependencies


## API

### Auth

Auth is done via JWT

POST /login
GET /me

GET /sites
GET /sites/{site_slug}

GET /sites/{site_slug}/postings/{posting_slug}
POST /sites/{site_slug}/postings
DELETE /sites/{site_slug}/postings
PUT /sites/{site_slug}/postings/{posting_slug}

## Technical details of auth

auth is done by generating bcrypt password hash and store them in a config file

[[users]]
name = "admin"
password = "$bcryptpass"


## Details of git

### Debounced auto-push

Criticity: Low

- we can afford network traffic (surtout si c'est notre propre serveur git en local)
- in this case it good to avoid to make too much push in one go.
- that would mean that the site would not be immidiatly online

### Debouncing commits

Criticity: Low

In order to track the changes made in the git repository, we need to commit each time an "update" is made to the content of our website.
We could, for a starter, commit at each change. This would work but it will probably create too many commits because one of the way the user will use the admin interface will be in rapid succession of actions: e.g, there is a mistake in a keyword, the writer will change the title, then click the save button and notice that he should also change a word in the description of the article. Another example is when the user want to save regularly his work to the server to be safe.

We could use `git commit --ammend` to commit a change in a file that was committed recently.
We could also have a debouncer system, on an article change, we set a timer to commit in 60 seconds for that site, but if there is another change, it will reset the timer.

This is tricky to implement because what if for some reason, we made a small change in an article and then after a big big change in quick succession. It probably makes no sense to bundle those changes together.

We could probably try to detect to separate a big change with a smart algorithm but that too much complexity.

An easy solution would be to not bundle commits at all for now, as it's probably not a critical feature.

## Merge resolution

Criticity: Medium

For now, we can assume that only a handful of people do change on a site repository, so we assume very little merge conflict.

Picture this scenario:
- User A edit the article A on the hugotator web platform
- User B edit the same article A but on her setup with git and vim.
- User A do stuff and commit, and pushes.
- User B do stuff and commit, but when pushing there is a conflict. It this case, the conflict is managed by the User B

But what if the User A pushes *after* User B. In this case, as the git interface is hidden from the Hugotator user, we need to provide some kind of merge resolution.
We can probably try an automatic git resolution, but if it fails (and it will even in simple case), the best next thing is to warn and provide a choice for the user (accept their or yours).

## Auto-deploy

It must be separate from hugotator, as hugotator is just meant to be a simple editor.
The deployment is downstream of the git repository and hugotator is upstream.
We can try something like github actions or gitlab jobs or similar with gitea/forgejo.
It's just a script that will `git pull` and execute the hugo build, as well as emptying the cache.