website: removed outdated image API documentation

docs/website/Developers/API/api.md

@@ -10,8 +10,7 @@ The OSC website API exists to serve, create, modify, and delete dynamic resource
 1. Blog metadata and rendered HTML articles (documented in [Developers/API/blog](/docs/website/Developers/API/blog)).
 2. Passing contact messages to the SMTP mail server (documented in [Developers/API/contact](/docs/website/Developers/API/contact)).
 3. Serving the various editable forms (documented in [Developers/API/edit](/docs/website/Developers/API/edit)).
-4. Serving and storing blog images (documented in [Developers/API/images](/docs/website/Developers/API/images)).
-5. User authentication (documented in [Developers/API/users](/docs/website/Developers/API/users)).
+4. User authentication (documented in [Developers/API/users](/docs/website/Developers/API/users)).
 
 In the source code, each route occupies a separate file in the [routes folder](https://github.com/ufosc/Club_Website_2/tree/main/routes), and all routes are subsequently organized in [routes/api.js](https://github.com/ufosc/Club_Website_2/blob/main/routes/api.js).
 
@@ -46,7 +45,7 @@ router.put('/', (req, res) => { /* ... */ })
 
 ## Express Router
 
-The express router, part of the Expressjs framework, enables developers to create and export APIs modularly. Meaning, an API can be developed according to some relative path (e.g `/images`), imported into another router, and then served over some other, more abstract path (e.g `/api/images`). Consider the following example:
+The express router, part of the Expressjs framework, enables developers to create and export APIs modularly. Meaning, an API can be developed according to some relative path (e.g `/users`), imported into another router, and then served over some other, more abstract path (e.g `/api/users`). Consider the following example:
 
 ```js title="File A"
 const express = require('express')

docs/website/Developers/API/edit.md

@@ -6,7 +6,7 @@ sidebar_position: 4
 
 # Edit Route
 
-The edit route renders the 'edit' pages that enable admins to create and modify articles, images, and other users. They return templated EJS sites that automatically fetch the requested resource's data and render it into editable HTML forms.
+The edit route renders the 'edit' pages that enable admins to create and modify articles, and other users. They return templated EJS sites that automatically fetch the requested resource's data and render it into editable HTML forms.
 
 This set of routes is responsible for returning one of two possible options - both via the same EJS templates - for each form:
 
@@ -120,23 +120,3 @@ If the client is not authenticated, a 403 forbidden error will be returned.
 ```bash
 curl -XGET --cookie "jwt=<AUTH COOKIE>" 'https://ufosc.org/api/edit/user/<USER ID HERE>'
 ```
-
-## Upload new image: (GET) /api/edit/image
-
-This route returns the image upload form with no pre-filled fields. The form's template is implemented in [/views/edit-image.ejs](https://github.com/ufosc/Club_Website_2/blob/main/views/edit-image.ejs).
-
-Since images are minimally customizable, their modification form does not exist. Instead, users may delete an existing image and replace it by uploading a new one.
-
-This route is authenticated. It responds with an HTML page.
-
-### Request Parameters
-
-| Parameter    | Description            |
-|--------------|------------------------|
-| JWT (cookie) | (Required) Auth cookie |
-
-### Example
-
-```bash
-curl -XGET --cookie "jwt=<AUTH COOKIE>" 'https://ufosc.org/api/edit/image'
-```

docs/website/Developers/API/users.md

@@ -182,7 +182,7 @@ If the ID is valid but not longer exists, the following JSON object is returned:
 { "error": "ID does not exist" }
 ```
 
-To maintain database collection consistency, and prevent unexpected collision/behavior from renamed image IDs, modifying the ID parameter of users is prohibited. If a client attempts to send a JSON request body with an `id` or `_id` key, the following error will be returned:
+To maintain database collection consistency, and prevent unexpected collision/behavior from renamed user IDs, modifying the ID parameter of users is prohibited. If a client attempts to send a JSON request body with an `id` or `_id` key, the following error will be returned:
 
 ```json title="routes/blog.js"
 { "error": "Setting custom user ID is prohibited" }

docs/website/Developers/Databases/models.md

@@ -8,8 +8,7 @@ sidebar_position: 2
 
 The database's structure is defined by the following collections:
 1. Blogs (defined in [model/blog.js](https://github.com/ufosc/Club_Website_2/blob/main/model/blog.js))
-2. Images (defined in [model/images.js](https://github.com/ufosc/Club_Website_2/blob/main/model/images.js))
-3. Users (defined in [model/users.js](https://github.com/ufosc/Club_Website_2/blob/main/model/users.js))
+2. Users (defined in [model/users.js](https://github.com/ufosc/Club_Website_2/blob/main/model/users.js))
 
 :::note
 
@@ -19,13 +18,6 @@ To learn more about using models with MongooseJS, see [Using MongoDB](/docs/webs
 
 Model instances are created and saved to the database in each model's corresponding API route.
 * Blog posts are managed in [routes/blog.js](https://github.com/ufosc/Club_Website_2/blob/main/routes/blog.js).
-* Images are managed in [routes/images.js](https://github.com/ufosc/Club_Website_2/blob/main/routes/images.js).
 * Users are managed in [routes/users.js](https://github.com/ufosc/Club_Website_2/blob/main/routes/users.js).
 
 To learn more about routes, see [API & Routes](/docs/website/Developers/API/).
-
-:::tip Image Storage
-
-The images database collection only stores metadata. Physical images are stored on the hard disk to reduce latency. To learn more, see [Image Storage](/docs/website/Developers/Databases/image-storage).
-
-:::

docs/website/Developers/kubernetes.md

@@ -66,22 +66,6 @@ spec:
 	  # The amount of persistent storage to allocate.
       storage: 1Gi
 ---
-# A volume is a persistent store of data.
-# This is the volume for storing image uploads.
-apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: osc-website-volume-uploads
-  labels:
-    app: osc-website
-spec:
-  accessModes:
-    - ReadWriteOnce
-  resources:
-    requests:
-      # The amount of persistent storage to allocate.
-      storage: 1Gi
----
 # A deployment provides a declarative way to describe the desired state of
 # an application. In this case, the desired state is to have at least 1
 # replica of Mongodb and the OSC Website running on the node.