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?
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 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.
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 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 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 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.
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).
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 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.
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.
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.
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.
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.
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.
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 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.