The sections are more a check-list at this point. Things I need to
implement. I've stubbed them out and going to call it a day. They HTML
I've used is rough but it give me something to work on next time I
work on this project.
This is template still needs a lot of work done to it. The additions
in this commit focus on the set home page and enable/disable the
sign-up features.
This is work-in-progress for the site-settings section of the
website. These additional features in this commit focus on setting
home page and enabling/disabling the sign-up features.
This template displays a list of pages stored in the system in the
/storage directory. It is very rough -- only bare basics to get the
page operational.
This is prep. for getting a working version of the /create/page
defroute. My thinking at the minute is the logged in user can create a
'page' which is a page specific to the website and a 'post' of some
sort for an actual archive entry. I don't know how desirable or
feasible this design/approach is but I'm trying it to find out.
This replaces white spaces in a string with a hyphen ('-'). I prefer
file names to be stored with no white space, which is where I intend
to use this function the most.
The code in this commit is very rough but it works. I just got the
basics up and running. The template posts the content but the back
isn't implemented yet. At this moment in time, I need Nic to sign-off
on what she wants from this page. There is a chance this template
might not exist in the future.
The code in here is for the site's administrator to see a list of all
the users with an account with edit and delete options. There is,
also, a section to create new users (non-admin. accounts).
Just an extra check in amongst what's already there. If the username
the new sign-up attempt has entered matched one already in the
database, a message is relayed stating as much and redirects back to
the sign-up page.
The functions are helper functions for when dealing with
SQLite3. Because SQLite3 doesn't have a Boolean data-type, I have to
store the 'true' and 'false' values as integetes.
0 == false
1 == true.
The update part refers to the redirect when a database is found whilst
making a HTTP POST request, as part of the init-db
process (A.K.A. website's first run procedure).
The auth to nera change is because I didn't catch all of the moves in
a previous commit. The image I was running at the time still had the
auth version so it wasn't showing any errors. I spotted this one when
trying to run a new image.
The web package was already using code from some of these
packages. This commit moves some of the code in the web package into
one of the various referenced packages and also has 'web' utilise the
new features in those pacakges also.
The biggest shift is in how the alert-messages are handled (store in
ningle:*session* across HTTP requests) and how auth. is handled --
mostly the redirects functionality.
The main reason is so the constants defined in the status-codes
packages can use it. I've put the (HTTP) status codes in their own
package because they are a self-contained thing. I find it easier to
work with them this way.
nera is responsible for the database stuff which is not part of
Caveman2. The status-codes package is a list of constants representing
the various HTTP status codes -- with an explanation of what they are for.
