This is the source code for https://werefox.cafe, https://info.werefox.cafe, and possibly other subdomains in the future.
Go to file
2023-11-29 01:30:59 +00:00
src/info Added some verifiers and renamed the container. 2023-11-29 01:30:59 +00:00
tests This was completely unnecessary and took me hours, but I wanted to flex my one-liner skills... 2023-01-28 18:26:26 +00:00
.gitignore change Dockerfile to use requirements.txt, add Robot Framework files and change command to run test suites in specified dir as well as output in a seperate dir. 2023-01-21 20:48:07 +00:00
deploy.sh Added some verifiers and renamed the container. 2023-11-29 01:30:59 +00:00
docker-compose.yml Added some verifiers and renamed the container. 2023-11-29 01:30:59 +00:00
Dockerfile Updated deploy script, docker-compose, dockerfile, and many dependency updates. 2022-12-06 01:51:43 +00:00
LICENSE Templated out the identities pages, no longer linking externally. Added AGPL3 2021-04-26 15:55:28 +00:00
README.md Slight modification to test runner script, updated README. 2023-01-26 16:55:09 +00:00
run_tests.sh Slightly modified test runner script to specify test suite for debugging, implemented tests for info.werefox.cafe root page. 2023-01-27 21:53:20 +00:00

Source Code for werefox.cafe

Here's all the source code for the site I host on werefox.cafe.

(If the subdomain changes, I'll update the README)

Development

You can use the deploy.sh script to start up the container in development mode.

./deploy.sh dev

This will handle starting a new container of Next.js with all required packages for the site in development mode. You should use this if you're planning on running the site using production mode later so you can see changes to your code in real time and test any backend changes.

Keep in mind that you should never host this site in development mode publicly. This sentiment reflected in the documentation for Next.js.

Testing

It's in the preliminary stages right now, but if you want to try your hand at running automated browser tests yourself:

./run_tests.sh

That will start up a docker compose setup with a Selenium standalone server and a Python runner for the test script(s). I plan to add much more here in the future, like the ability to specify which test suites to run, what URL to test at, organizing output, etc.

You can also just bring up a selenium-standalone container with:

./run_tests.sh --debug-server

or

./run_tests.sh -s

Once that is up, you can also debug tests with the node container with:

./run_tests.sh --debug-node

or

./run_tests.sh -n

The latter of which will simply run all the robot tests in the tests/test_suite directory.

Production

You can also use the deploy.sh script to start up the container in production mode.

./deploy.sh build
./deploy.sh start

The build parameter will generate the necessary static assets for the site, including any static pages and JSON. The start parameter starts up a production server. If the build fails, you won't be able to start a production server. So, if you decide to issue something like ./deploy.sh build && ./deploy.sh start just keep that in mind.

Personalization (Forking)

You're absolutely free to fork this code and make some modifications for your own site! I simply ask that you not host something that looks like it's just my own personal site somewhere else, and that you link either yours or at least the original source code. Additionally, if you intend to keep Mutant Standard emoji, please do not forget to include the Creative Commons license statement.

pages/

The project itself is split into pages/, data/, and components/ mostly. Pages are used to define both the routes and the site pages themselves. They're the most high-level part of the site's structure, since they import data and code from data/ and components/ respectively.

data/

If you're mainly interested in editing the various text and such from the site, you're gonna be looking at the files in the data/ subdirectory. It's very likely you'll also want to make some changes to the components at some point if you're doing this, but if you just wanna mess around so you can get a better understanding of how things work together, this is a great place to start.

components/

Unless you are making major changes to a page, you likely will want to edit the code in components. This is where you can edit a lot of the JSX that's defining the different elements of each page. Think of it as editing sections of a template.

CSS

It's also likely that if you're editing data and components, you'll want to change the theming and styles of things. This project uses tailwindcss, which is quite unique amongst most CSS frameworks.

Without writing an intro to the framework itself, I'll give a brief summary. If you take a look into the components, you'll notice that tags tend to have a lot of class names. Tailwindcss uses these class names to apply specific styling to elements, rather than making sets of CSS files to define styling based on classes and ids.

If you want to change the color palletes of things, you should look at tailwind.config.js. This file can define quite a few other things throughout the CSS framework, but I'll leave the investigation of that to some reading through of their documentation.