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.
