The index.html is the default home page and had it's own styling. Based on the
feedback provided by Nic, regarding the layout in the page entry HTML templates,
I've added the HTML tags and CSS classes to the index.html template. This is me
just getting ahead of a change she is going to ask for in the future.
It is a minor change so changing it back won't be a problem.
The original 404 page was a self-contained HTML template. This meant it didn't
use the render function like the rest of the routes in the web package. I had to
change merge-pathnames to render because I wanted the 404 page to use the Djula
tempting engine. By doing this, the 404 page could use the main.css file and the
insert-snippet lisp code-block.
The original 404 page was the default one generated by the caveman2 project
generator. This change brings the template more in line with the design/looks of
the ritherdon-archive design language.
The page.html template's text was filling the entire width of the browser window
-- regardless of its size. Nic wanted the page entries to match the max-width
size used by the archive-entry template. This change wraps the CSS classes and
HTML tags in the page.html template's content-area with the same ones used in
the archive-entry.html template.
It looks like the caveman2 project generator has a typo regarding the robots.txt
file in the static file and paths list (in app.lisp file). The list has 'robot'
instead of 'robots' in it. This means the search engine crawlers can't reach the
robots.txt file because the site returns a 404. This change fixes that.
This is a hard-coded change which addresses the bug (#1) which points to the
wrong URL for the Meilisearch server -- when running in prod. -- but this will
need further refactoring. I've already created an issue (#2) in the Issues
tracker in prep. of that work.
I fixed typo's and added placeholders (E.G. '<INSERT USERNAME HERE>') in places
where you need to add your own data which is used on your server/system.
This is tag-along code from porting the storage package over from another
project. It's never got in the way so it's never caused any errors -- hence no
deletion/dealing with it until now. I've commented it out with the intention of
deleting if no use for it develops as it the site gets closer to going into
production.
The first part is just a minor change to get Emacs to indent the defpackage
stuff in an orderly fashion.
The second part refers to the 'main' function. I've changed the server it
uses/specifies from Hunchentoot to Woo. I've been using Woo throughout
development so I'm more confident with the system using that when it goes into
production. The 'main' is used, instead of 'start' when running the website as a
systemd service on the production server.
I used Caveman2's project maker and it adds packages, systems, exports Etc. with
strings. I changes how they were called here by replacing the string-quotes with
'#:'. It annoys me how Emacs indents/aligns the system and package stuff in a
wonky way when you don't use '#:'. I finally had fed-up with it and changed
it. Overall, this is a minor change.
The <a> tag would stretch across the top of the page and it made it hard to
click in an 'empty' space on the page. It was, also, confusing when the page
would change to the home page when you were not paying attention whilst clicking.
Because the code now establishes the 'server' variable in the various HTML Djula
templates (grabbed from the database). The code which generates the old 'server'
variable and it's data has been commented out or deleted.
This variable contains the URL for the Meilisearch instance this site calls out
to. It is grabbed from this site's database and passed to the Djula templates
providing Meilisearch-based features. The 'server' variable is called here so
it's easy for the dev. to see how and when it's called.
The filter code was moved to its own file and these two files utilse that
code. So, these templates now must call them. The reason for moving the code out
is to stop the browser's console printing errors -- because the filter JS code
was trying to run on pages which didn't have the correct HTML.
I've left the old code as a comment just in case I need to reverse course. The
new way the function gets the (Meilisearch )search URL is to get it from the
database (site-settings table). This should make it easier to pass the URL
around between the back-end and front-end.
This file contains the code for the filtering feature in pages.html and
archive.html -- a basic search feature which works by filtering the list of
entries on the page.
It was originally in main.js but I moved it here because it was producing errors
on pages which didn't have the filer stuff on the HTML template. This change
allows each template to call it when the template actually uses it.
This feature is for updating the search-url used by this site to call out to the
Meilisearch service (which provides the search database for this website). It
doesn't touch or alter anything on the Meilisearch service/instance/server.
search-url is part of the site-settings class. It is used to help tell the
system which URL to use for the Meilisearch instance this website's search
features are utilising/calling out to.
I, also, replaced some 'logged-in' permission checks to 'administrator' in
several defroutes (mostly 'danger-zone' routes).
This is the back-end functionality which allows users to upload Snapshots (in
.zip files) to the /snapshot directory.
The route accepts multi-file uploads and ignores files which are not either a
.zip file or if a file has the same name as one of the Snapshots already in the
/snapshots directory.
Technically, the user can upload several files at once which are not .zip files
and the alert-message will relay a 'success' message, even when nothing was
added to the system. This is because the system is relaying the upload went
without errors and not how valid each file was. The system doesn't have anything
built-in which allows the multi-faceted alert-message approach to work.
Another thing to note here is the lack of checks for the contents within a .zip
Snapshot file. Basically, there isn't any. I am unsure how many moving parts are
going to be in these Snapshots in the future and hard-coding checks for
directories and file names seems a bit premature (maybe unpredictable?). The
HTML template responsible for dealing with the front-end of the Snapshot
features clearly state it is a 'danger zone' section of the site. So, there is
an expectation (hopefully) of 'if you don't know what you're doing, then don't
touch it'. Hello, person of the future. I was really wrong with that assumption,
wasn't I?
This feature provides the ability to unzip a .zip file (the expected file format
users must upload Snapshots with) and store the contents of the .zip file in the
/snapshots directory.
This commit is just the front-end. The back-end, at time of this commit has not
been implemented.
The form allows users to upload 'Snapshots' to the website -- with the
intention of then restoring the website from that back-up.
The server needs to be restarted after restoring the website from a
Snapshot. This commit has code which establishes if the website is running on
localhost and informs the user to restart the server (most likely in SLIME)
manaully. If the website is running in prod. and using Systemd, the service will
need to be restarted that way (user doesn't have access to SBCL or SLIME in that
context). So, a Bash script will need to be written and that script will need
to be called using (most likely) utils:run-bash-command.
At the moment, I haven't got far enough into developing this website to have
established a Systemd service or running outside my local dev. machine. So, I
have left a TODO comment here stating the prod. side of the defroute is not
implemented yet.
This is part of a multi-part commit to port the string-is-nil-or-empty? function
from the utils package to the validation package. The code has a lot of
'utils:string-is-nil-or-empty?' dotted around so this took a few commits to
port. There is a chance I've missed it in some obsure places so don't be
surprised if you see a future commit relaying something similar to this one.
This route zips up the specified Snapshot and moves it to the /storage/media
directory. I was originally planning of having the user download the Snapshot at
this point but I decided to change how this works.
I decided to go with the 'zip up a Snapshot and move it to /storage/media'
because I didn't want to re-implement the 'download' functionality outsite of
the /storage features. Maintaining two 'download' sections is not something I
want to be doing -- that is what the /storage section is for (sort out the
downloading). Doing this way, also, adds another chance place for the site's
data to be recovered from.
I've changed the approach to how users deal with downloading Snapshots. Instead
of re-implementing the functionality for downloading files in the /storage
section of the site, the user now prep's the Snapshots (zips them up) and moves
them to the /storage/media directory. From there, users can download the zipped
file and I haven't had to re-implement or write additional code.
This differs from the other file/directory checks because it doesn't create a
directory when it can't find one (usual Common Lisp predicate behaviour with
files/directories).
This is the second part of porting string-is-nil-or-empty? from the utils
package to the validation package. The code between the validation and utils
package was already sorted in a previous commit. This commit to updates where
the web.lisp package calls it.
This is a port I've been meaning to do for a while now; I just haven't got
around to it until now. This commit doesn't refactor the code in web.lisp to
call the ported code from validation -- it's just the first step in the port.
This commit looks like it has more going on that is acutally does. The biggest
mis-directed blobs are the docstring comments I added to get-files-in-directory
and get-file-names. I just never got around to adding them until now.
I remove the format call in make-raw-path because I forgot to do so in another
commit. The code works with or without it which is why I missed it
previously. I'm removing here to clean the code up and before I get distracted
and forget.
The actual code which this commit is mostly for are the get-raw-directories and
get-directory-names. You shouldn't need to use these functions in the normal
operations of the site. They are mostly intended to be used for dealing with the
site's snapshots -- or any other directories outside of the /storage
directory. The snapshot management section of the site is part of the 'danger
zon' features -- hence the need to break-out of the usual '/storage directory'
features.
This package grabs disk information from the OS -- and can display it in human
readable form. Looking to create a 'Disk Info.' section on the dashboard page to
help users decide when they need to start deleting snapshot data or move to a
machine with a bigger disk.
At the time of this commit, no features have been implemented yet.
This directory is created during the site's first run. This addition to
.gitignore stops the commit history from getting clogged up with irrelevant data
during development.
The most notable ones are the 'copy' functions. The main intention here is to
provide the functionality needed by the snapshot package to help it take
programmatic snapshots of the website's data and database. At the time of
writing the 'restore from snapshot' functionality has not been implemented but
that is something these 'copy' functions will look to help with.
This is a variation on the create-timestamp-id used for generating a
timestamp-id for the Meilisearch database. This text-based timestamp takes the
form of YYYY-MM-DD_HH-MM-SS. The main intention of this function is to use is as
part of a directory name when generating a snapshot (of the website's data/DB).
This is part of the 'danger zone' section in the site-settings.html
template. The back-end for this feature is not implemented at the time of this
commit.
I will add to this as I add more snapshot features into the main website
code (I.E. HTML templates and routes in web.lisp). At the moment, this package
is a little island right now and doesn't integrate into the rest of the website
at all.
copy-directory is a package on quicklisp to copy files using the OS's native cp
command (useful for taking snapshots/back-ups of directories). The snapshot
package is for copying directories (I.E. taking snapshots) in /storage and the
site's DB.
It's never been and won't be used. It came as part of the 'make project' process
when generating a Caveman2 website -- just never got around to deleting until now.
This feature copies the selected file in /storage/media and builds it full
URL. The intention is to make it easier for users to copy the URL when the need
to paster it into one of the 'edit' pages (I.E. Pages and Archive sections) text
areas.
At the minute the code assumes its only copying and building URL for the files
listed on the 'Storage Index' page (/storage/manage defroute). If the website's
features expand in the future in this area, this function/feature will need to
be refactored.
The file-type contains 'image' so the filter assumed it was a .png or .jpg and
the image wouldn't render when it was a .svg file. This additional check to the
filter makes sure the svg.png (stock image file) is used when a thumbnail is
used in a HTML template.
I was going to start on making this function more robust and remove the
hard-coded nature of it but cleary I got distracted and never actually started
it. I know it will need to include the 'build-url' functions in the utils
package but until I get around to actually refactoring this function, I'm going
to leave the code commented out.
This includes the HTTP GET and HTTP POST requests (defroutes in web.lisp). This
is part of the 'danger zone' features because it can leave the website in an
un-recoverable state.
This template has the CSS and HTML already included with this commit. It's
usable but I'm guessing it will need tweaking when the site gets closer to going
into production.
Links point to sections for manaully deleting files in the /storage
directory (without database interaction) and deleting database entries (without
storage file interaction). These sections are marked as 'danger zone' because
they should be used carefully and only if the site's storage files and database
have become out-of-sync. with each other.
The back-end functionality has not been implemented yet.
This feature deletes all the user created content stored in the /storage
directory, the website's database (so User Accounts) and wipes the
Meilisearch database clear of the Archive Entries stored in it.
This is part of the 'danger zone' features and intension is to allow the site's
Admin. to clear out the website and start with a fresh clean install.
This function is part of the 'reset website' feature implemention. You should
only need to call this when you want to delete something outsite of the /storage
directory (I.E. the website's database).
This feature is part of the 'danger zone' section in the site's settings. This
feature clears the Meilisearch database (with this site's Archive Entries) and
re-populates it with the data from this website's (nera) database.
This commit establishes the 'danger zone' in the site's settings page. This will
need to be added to over time. This commit set-ups the 're-populate search DB'
feature but the back-end is not yet implemented.
The main feature is the repopulate-database function which clears out the
Meilisearch DB index containing this site's searchable information and
repopulates it with the site's nera.db information.
I, also, added a delete-index function (also in search package) but that is
mostly a convenience feature. It allows me to quickly delete any index in the
Meilisearch DB which I made by mistake (E.G. wrong name, change of plan) and
remove old indexes from other projects which are no longer in use (on local
dev. machine mostly).
I'm sure I will need to update this at some point. I didn't spend too much time
on it, just jotted things down as a I came across routes in web.lisp. The
Sitemap URL will need to change, the closer the site goes into production and an
domain name has been bought/finalised.
These functions are mostly aimed at the site's XML-generated site map. The piece
together the site's URL from lack's request struct. I don't know if there is a
pre-built string containing this information (I.E. http://localhost:5000 and
http://localhost:5000/testing) which is why I have written these functions.
When uploading a file to /storage the database stored the un-formatted name and
the file was stored with the formated name. This meant when anyone tried to
download or rename the file, the website would produce an error. This commit
fixes this and has the database and file storage system store the files name in
the formatted way (all lowercase with no whitespace).
This file has been in the repo. for a while -- I copied it over from my co-web
project. But, I hadn't touched it or integrated into this website until
now. The changes in this commit are mostly minor changes which bring the URL's
for the Meilisearch instance this website connects to and change the CSS classes
to match the ones used in this project (and not my co-web) project.
Because I copied over the code from my co-web project, the code in this file has
CSS classes referring to that project. This commit updates those classes to fall
in-line with the CSS/design of this website.
I will need to update this as I go along. I copied the code over from my co-web
project so the webpages have been rendering with that style/design until
now. This commit has removed as much of it as possible and added/updated the
style rules to fall in-line with the design of this website.
I will need to update this as I go along. I copied the code over from my co-web
project so the webpages have been rendering with that style/design until
now. This commit has removed as much of it as possible and added/updated the
style rules to fall in-line with the design of this website.
I was faffing in this file and had Emacs do a quick re-indentation (with
web-mode) enabled. I don't think I have touched this file since installing
web-mode.
This allows you to change the order the search results are returned in. The main
purpose why you would want to use this function in this context is to make sure
the list of results is ordered by the year the artworks where published/created.
This will need updating. I copied over a quick-list section from another
template. I'm off home after this commit (got one more commit to enter after
this). Thought I would get something in before I left, though.
Only 'Month' and 'Year' are used because 'Day' is not relevant -- at time of
writing. You might see an change to this form in a later commit if requirements change.
The publish date refers to when the artwork was publish which differs from the
'Created At' date. That refers to when the entry was added to the database.
This update is in the nera package. It is part of a refactoring of functionality
to have a seperate 'Publish' date and a 'Created At' date within this site's
database. The 'Created at' date refers to when the entry was added to the
database. The 'Publish' date is the date of the artwork.
This code is intended to be used mostly in the 'index' pages (Pages and
Archive). These pages are mostly going to act as a back-up for when the
Meilisearch service goes down or if the user has a poor internet
connection. This filtering behaviour allows the user to filter the entries in
the Index they are viewing (Pages or Archive). There are no images and no
repeated calls back to the server. Each index lists just the text (Titles,
publish info. Etc.) and from there the viewer can filter the results on the
page by entering text into the text box in the Index-base HTML templates.
From Nic's point-of-view, these Index pages will not be included in the
nav. menu but if the Meilisearch service goes down (at this site is still
operational), she can swap out the 'search' page for these (really it's just the
Archive Index) so people can still have some form of search/filtering ability
whilst viewing the website.
This defroute doesn't change anything relevant in the Meilisearch DB so it
doesn't need updating. I've left a comment (mostly for future me) to remind me
not to think I've missed a defroute and try to integrate the Meilisearch stuff
into it.
The defroute to update the thumbnail doesn't need to change but I added a
comment to make it clear in the future -- I can see me forgetting it doesn't
need updating and try to add code which doesn't need to exist.
I, also, did a bit of updating to the layout of the code is parts -- mostly when
setting the alert message.
The re-direct to /search when the user has set /search as the site's home page
is part of a list of other hard-coded re-directs in this site's '/' defroute.
The site now deletes the Archive Entry from the Meilisearch database alongside
the files in the /storage directory and the nera database.
These functions are helper functions to manage the Meiliseach database from
a Common Lisp perspective. The intention is to work them into the website's
back-end so the user can reset or re-populate the database from the website
without me (or someone else) having to SSH into the VM and do fix/restore things
manually. For now, they allow you to manage the database from SLIME.
This change is so the refinements on the seach page shows the month names
instead of thier numbers. This is because most people tend to work with month
names and not numbers in this context.
This is a helper function to convert '1' to 'January', for example. The intended
use for this is to work alongside the local-time package when generating the
month number from a timestamp.
This commit makes the header (site's name and logo) a link which points back to
the site's "/" (I.E. Home page/route). It, also, centralises the header and the
navigation menu (in the header). This is so the header doesn't look weird when
viewed on a mobile phone.
I removed the <hr> at the bottom of the file because the site has enough styling
applied to it to make the <hr> look out of place now. I can clearly
denote/identify where the site's (front-end) header and footer stops and starts.
I didn't realise the local-time system set 'Sunday' to '0' in its
timestamp-day-of-week function. I thought it was '7'. This commit changes the
check for '7' to '0' and adds a few comments to help identify which days the cond
form is checking against.
These files are provided by the Meilisearch project. This commit is larger than
usual because of this. The CSS files are copied over from my personal website's
repository so they will need modifying going forward. I've added them here as a
starting point.
This page is populated in this commit but is broken because it requires several
JavaScript files which have not be committed to the repository as of yet. This
commit is in preparation of adding those files.
The site now populates the Meilisearch database when the user creates an archive
entry. The Meilisearch needs to be set-up manually at this moment in time so
expect this to break easily if you haven't got Meilisearch working.
I copied most of this over from my personal website's repository. So, there are
bits of code which look a bit out of place in this context. With that said, the
code does run and just needs to be integrated in the defroutes in web.lisp.
I've removed the 'extends' blocks and built a completely seperated template from
the rest of the website. The template was not rendering properly because certain
parts of the website had not been set-up yet so the complete isolated template
was/is required.
I've, also, added extra options for the user to set during this first run
process which will be processed by the back-end. I've not put much work into
adding validation checks because it is a one-time thing (this page). You'll need
access to the server anyway -- at this point -- so a bit of manual correction of
mistakes will be easy to achieve. Deleting the database will be enough to
trigger the first run process again.
The conditions are added to the 'Site Logo' and 'Favicon'
sections/defroutes. The checks are to make sure a user doesn't try to set an MP4
file as the site's favicon or site's logo.
This update seperates the form previous version of the template (for updating
the user's display name and password) into two. This is because of a change in
the back-end defroutes. It's makes it easier on the back-end to update the
password and display name seperately with different HTTP POST requests (and HTML
form data).
The alert message was rendering under the dismiss button when viewed
on a small (phone) screen. The extra padding makes sure the message
remains clear of the button.
When the user wants to delete their account they must now enter their
username as part of the form they submit. This is so they don't
accidently delete thier account.
The default assets were part of the list in .gitignore so the site would produce
errors during the site's initial first run set-up. I've quickly added the files
to the repository but they will need work done to them because the files are
empty and the wrong default images. This commit is done from my computer in the
flat so the files added were to just fix the errors.
This filter is builds the path for the dashboard profile image. The
path points to a different icon in the /images/icons directory
depending on what time and day it is.
There is no major functionality addition with this code. It just a
little sprinkle of cuteness for the user of the site.
These images are will be displayed alongside the user's display name
on the dashboard. There are several images because different ones will
be displayed at different times of the day and week.
Because the amount of JavaScript I've written, it doesn't make sense
to separate things out into their own files yet. So, I've renamed the
file to main.js and will add the little sprinkles of JavaScript
here. If the amount of JavaScript grows, I will need to move things
out of here but that is a future problem.
This is a multi-file commit because the code is essentially the
same. Each HTML template has either had a 'quicklist' section added or
had links added to it.
'Quicklist' is just a section with a collection of links to other
parts of the website based on the context of the page/user's current
location.
I think I had a version of this route but I deleted it -- can't
remember if it wasn't needed or didn't work as intended at the
time. Anyway, this commit makes it part of the code-base (again).
The function provides the website to use the automatically generated
thumbnails -- when a user uploads the an image to /storage/media --
instead of the full-sized image. This should help reduce download
times if a list of uploaded image are several Mega Bytes and being
viewed at once -- like an index page for example.
These files are generated during the website's first-run process. They
don't need to be a actual hard-coded part of the repository. The way
the site is set-up, the user will either stick with the
defaults (generated on first-run) or upload their own personal files.
The automatically generated thumbnails are no longer stored in the
database. They are created, updated and deleted alongside it's main accompanying
image -- as a file in the /storage/media directory.
The route in web.lisp calls the recently created 'get latest'
functions in the nera package. The code is web should be fine but the
dashboard.html stuff is buggy and so is the back-end routes for
uploading deleting file in the /storage section of the website. This
is an end-of-session commit, though, so the bugs will have to be fixed
at a later time.
These functions haven't not been used much so I don't know how
reliable they are in their current forms. Expect some work needed on
them in the future.
I move the alert section to the /layouts/header.html template because
it was easier to get it to render between the logged-in user's site
header and the site's 'normal' header.
The site's side-menu (for logged-in users) still needs stuff adding to
it -- and tweaking -- but the base style, layout and whatnot is in
place.
I've moved/changed how I was using the /static directory (site-wide
snippet) so I can start adding in images and what have you again. I
didn't realise I had set Git to ignore the how /static directory.
I think I will need to swap out the string value 'success' with a
constant so things aren't as stringly-typed as this. With that said,
this is just a quick proof-of-concept. I can keep this around until I
build out this updated feature some more.
I hard-coded redirects to the pages which can't be deleted into the
site's index ('/' route). This allows them to be set as the home page
in the site's settings.
I, also, updated the data which is passed to
nera:update-nav-menu. This change is part of the Nav. Menu settings in
the site's settings.
The function now loops through the values passes to it and sets the
'enable-nav-menu- column in the database for the currently selected
page in the loop.
The nav. menu section sends a hidden value if a check box isn't
selected. This is in preparation for implementing the back-end part of
this feature.
I, also, removed the if-statements when selecting the home page in the
'Home Page' settings. Again, this in preparation for adjusting the
back-end functionality for this feature.
I'm changing the snippet to be stored as HTML instead of
JavaScript. I'm, also, storing the snippet in /storage/snippets
instead of /static. This makes it easier to hook it up to my Umami
instance in the future if Nic wants to do that.
From an end-user perspective, I don't think Nic will care about the
difference. She'll want the easiest option and uploading a single file
via the multi-upload form -- with no file name input -- is the easiest
way to go about this. I say this without actually speaking to her
about this so I might be wrong on this and need to go back in and
change things.
The code now removes the old thumbnail file, stores the new one and
updates the database entry. I found it easier to keep track of the
changes whilst developing by doing this.
I added a new route to get files from the /archive directory but
needed to expand on the original /storage/view/:slug route so I could
seperate out the two (/storage/media and /storage/archive)
directories.
I added a check to make sure the archive entry
requested (/edit/archive/:slug) exists and return a 404 if it doesn't.
These functions are to help with standardising on the naming formats
when storing files and keywords (for Meilisearch database). The
asciify and slugify functions are not enough. They either leave spaces
in the file names or the file extension gets lost in the standardising
process. Going forward, file names should look like
'this-is-an-example.png' instead of either 'this is an Example.png' or
'this-is-an-example-png'.
I was getting errors when trying to quickload the system because a
custom djula filter (defined in view.lisp) couldn't find one of the
specific ritherdon-archive packages/files. I can't remember which one
because I made the change earlier in the day and didn't commit the
change at the time.
Both templates aim to list out all the archives stored in the
system. The /user/archive.html template, also, includes admin/back-end
features like edit and delete links/controls.
This is part of an end-of-session commit. I'm currently working on the
/create/archive-entry section (most the HTTP POST request). I still
need to start the view archive, edit archive and delete archive
parts. I've not even looked at the Meilisearch stuff. For now, the aim
is to get the website's main database (nera.db) working and then
integrate the Meilisearch stuff in after that.
I still need to write the edit and delete functions (I.E. the 'U' and
'D' in 'CRUD') to have a basic CRUD system in place for this
section. I'm commiting this as an part of an end-of-session commit,
hence the partical amount of work done.
The only intended use for this function is to generate an Id. number
which will be used in the Meilisearch database and linking it to
Nera's database (I.E. this site's main database).
This is a rough sketching out of what the model/data needs to look
like. This model is what will be connecting the site's archive (Nic's
artwork entries) with the Meilisearch service -- running alongside
each other. I don't know how much this model is going to change but
expect it to in future commits.
When uploading a file, a thumbnail is made (if an image, using the
Image Magick program with Bash). This file is not stored in the
database. It is a file-system only thing. The reason for adding this
is some I can create HTML templates/defroutes which show a list of the
images in /storage/media without saturating the viewers bandwidth.
I need to work on this functionality a bit more. This is an end of
session commit. Started it and it works but needs expanding.
I could do with adding file-type checks and changing 'octet/stream' to
something like 'image/png' depending on the file-type (storage in
DB). This will stop the browser from downloading every file in
/storage/media and allow the files which can be viewed in the
browser (like images).
This is an end-of-session commit. I've got the route up and running
with the /user/storage HTML template rendering in the browser and
listing out the files in storage. I could do with adding a model and
storing the files meta-data in the database. This page could do with
rendering the images and placeholders (E.G.generic text file icon) for
non-image files.
The original code was very ham-fisted in how it dealt with storing
files -- based on their file-types. The changes made here improves on
it and the store-file (for both raw and /storage paths) functions now
accepts more file types because of it.
These files will be created and populated via the site first-run
set-up process. This should stop the commit history getting clogged up
with needless and irrelevant changes in these files.
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.
I was having trouble trying to get hermetic and mito-auth to work
together. I decided to just use normal mito and leave hermetic to the
authentication/authorisation stuff.
There was snippets of code in the code I liked. I'm going to keep it
around for a bit to see if I can work some of it in to the new
code. I'm most interested in the deployment code.
I tried it and I find it easier to work with Caveman2. I didn't
realise this templating program is built around Hunchentoot -- whereas
Caveman2 builds on top of. So, I'm moving the code to back to Caveman2
-- where I originally started. It looks like a waste of time but the
knowledge of having a look at the other stuff has been helpful.
This script adds a user to the database based on it's inputs (prompted
for the person running the script). The intention is to add a user to
the database easier (especially on a live production server with just
the CLI).
https://github.com/vindarel/cl-cookieweb (for GitHub Repo. and
instructions).
The reason for using this is because it makes it easier to run the
website as a standalone thing. You don't need to link it up to
Quicklisp's /local-project directory. It has scripts to help you build
the binaries and to run the website (as a standalone) thing. I, also,
hadn't use this 'cookie cutter' program before so it's a good time to
get my feet wet.
The admin. backend for Django isn't as easy to get to where I want it,
compared to Caveman2. The trade-off is Common Lisp isn't a mainstream
language so it does reduce the level of ease other might have when/if
they join the project.
I'm going to try this with Python and Django first. Because it's not
my personal project, it might be better to use a language which is
more mainstream. It should reduce the 'Bus Factor'.
