This is a rudimentary Django-based CMS which dynamically presents tarot-related content placed onto unconventional but familiar contexts such as hollywood film and historical biography. Our purpose is to overturn and reform the audience's perspective beyond all recognition. The author endeavours to reach out (or "appeal") to the broadest audience possible.

Here are Django apps I've created and what their purpose is:

• generators: When a web user clicks the 'random' button, it serves one of twenty two tarot cards arbitrarily. Each tarot card webpage includes:

  • A picture of the tarot card
  • The name of the card
  • Astrological Attribute
  • Alchemical Attribute
  • Intelligence
  • Hebrew Letter
  • Letter Meaning
  • Description of the symbolic meaning
  • The description applied to:
    • Galileo
    • FLOSS
    • St Paul the Apostle

  This app houses the most dynamic functionality of my whole website

• landings: Serves the landing/home page (the portal.html template). This app also serves the 'about' template which is a webpage which explains the basic who, what, when, why (or purpose) of the website in general (similar to the preface to a book)

• essays: Serves the article.html template which captures a curated list of the most high impact tarot cards and their application to Galileo and FLOSS (bound together simultaneously) along with a curated list of tart cards applied to St. Paul. This essays app also serves up static articles (without dynamic functionality) similar to a blog post - - for essays by the author on tarot applied to Forrest Gump and the war of ideas. This essays app even includes an 'objections' page for content involving anticipated rebuttals from my various audiences. This essays app also refers to a basic content_changelog.html template which enables the author to document changes made to essays or other content over time.

• accounts: This feature gives website visitors who land on the 'gateway' landing page to enter a passphrase to gain access the rest of the site.

For *nix:

$ virtualenv --python=python venv
$ source venv/bin/activate
$ pip install -r requirements.txt
$ python manage.py runserver

For handling, managing, and upgrading the latest packages, to construct a requirements.txt, we can leverage: $ pip-compile. To upgrade, use: $ pip-compile -U. pip will build the requirements.txt based on the paramaters established in requirements.in which will keep package versions pinned and updated. For more details on how to manage pacakges with best practices, including how to use pip-compile, head over to the Django Project forums in the topic titled: Best practices: Managing requirements.txt.

You will also need to install postgresql v12.3 natively in your operating system outside of the python virtual environment. To install postgresql on Manjaro/Arch, you cam use this:

$ sudo pacman -S postgresql postgresql-libs

The official Heroku docs cover provisioning Postgres, designating a primary database, sharing Postgres db's between applications, and more. This doc explains how to juggle/change/swap out one db instance for another.

This note to self I moved into it's own (private - hidden) gist titled Guide to backing up Postgres on Friday 9 April 2021. More work needs to be done. My next step will involve either (a) learning AWS S3 or (b) writing a custom Python script using multiple symlinks to automate the download of Postgres instances and mirror them up to my Digital Ocean droplet.

It's possible to run a remote AWS Postgres db locally. It's as straightforward as running:

(local venv) $ export DATABASE_URL='postgres://USER:PASSWORD@HOST:PORT/NAME'

whose DATABASE_URL you can source from the Heroku Dashboard. If you are havinng trouble determining the right 'colored' DB you can use:

(local venv) $ heroku addons --app tarot-prod

You can also use:

(local venv) $ heroku pg:info --app tarot-prod

These commands should reveal the name of the add-on to distinguish the db with 'lorem' content from the db with 'real' content.

It's also very important to note that when exporting a db locally, you need to do it inside the same terminal that the local dev server is running in. For this to work, you'll need to exit the currnet local dev server, unset the existing db, export the db, and then finally run the server again.

You can view the current db configuration (probably db.sqlite3 default) with:

(local venv) $ echo $DATABASE_URL

To remove or backout from using a remote Postgres instance and reintroduce db.sqlite3, this is the command you need:

(local venv) $ unset DATABASE_URL

PLEASE NOTE and to emphasize once more: It's important that you handle all of the above commands in the same terminal emulator. If you run export $DATABASE_URL in one terminal, and then have the server running in a different terminal, it won't work. Use all of the above commands in the same terminal that you are running the local server in.

In the Heroku Dashboard, here are some of the variables you need to change for it to work in the production enviornment:

• DJANGO_DEBUG : This config variable in production needs to be set to False to run the app, this will also resolve the check deploy issues
• ALLOWED_HOSTS : Set its value by adding multiple hosts as ( separating each host by a space) host1 host2 host3
• ADMIN_PATH : Set its value to make the admin path as secure as you prefer the best.
• HEROKU_POSTGRESQL_<color>_URL : postgres://USER:PASSWORD@HOST:PORT/NAME you can reset the PASSWORD variable on the fly by using:

  (local venv) $ heroku pg:credentials:rotate
  

  If you compare the postgres://USER:PASSWORD@HOST:PORT/NAME in the Heroku dashboard before and after redunning the Heroku 'rotate' command, most of the variables remain the same however the USER and PASSWORD will be different. This protects cards that I may have previously referred to publicly in the Issues section of this repo. More details can be gleaned from this Heroku help doc titled, How do I make sure my Heroku Postgres database credentials are correct? which I found by Googling: 'how to update postgresql credentials in heroku'.

If you accidentally upload duplicate tumbnails (generator app), Django will append a small hash to the .jpg and it won't parse when Django serves the tarot_key template. It's kind of a bug. The problem should only happen remotely on Heroku. If that happens (and it doesn't happen all the time), then the recourse is to use this command on Heroku: (local venv) $ heroku run python manage.py collectstatic -a tarot-testing --noinput --clear --no-post-process. Be sure to specify the right app (whether tarot-testing or tarot-prod). That will purge all static files with hashes. I don't completely understand why, but UmarGit and I went back forth on Upwork on June 14th, 2021.

This was an issue (#92) resolved on 9 April 2021 but which became an issue again on 14 May.

There seems to be three staticfiles directories declared inside settings.py. The one inside tarot_juicer/tarot_juicer/static is for development locally. The directroy tarot_juicer/staticfiles houses the static files on Heroku which will be intialized and created with the pgbounce buildpack in the cloud - - so there is no need for this directory locally. I'm not sure what tarot_juicer/static is for.

There are two heroku-cli app interfaces. The first heroku-cli app is installed locally for interacting between the local development environment and the remote server. The second heroku-cli app is installed remotely for interacting with itself. To install, you just navigate in Heroku settings for the app and click: “Add buildpack” and enter: https://buildpack-registry.s3.amazonaws.com/buildpacks/heroku-community/cli.tgz. Next go to Manage Account (settings - - top right corner of avatar icon). Then scroll down and select: “Regenerate API Key”. Next time you push changes and Heroku rebuilds everything, then heroku-cli should be installed. For future reference, you may use the official Heroku doc for managing authentication and API token storage.

I'm not sure what changed but one day the dev server began sponataneously complaining: "Error: You're accessing the development server over HTTPS, but it only supports HTTP" I had encountered this in the distant past. I can't recall the solution. But the solution today was to install a local SSL certificate using a guide titled, "How to run a local Django development server over HTTPS with a trusted self-signed SSL certificate." It was initially posted August 10th, 2021, so it is very recent (as of Januarny 2022 as a I write this). The guide targets macOS but there is a link to the GitHub page for the mkcert app that has an instructions for Arch-based distros using pacman whcih worked for me.

• is_protected switch / toggle to turn @login_required and LoginRequiredMixin protection on / off
  • I have no idea how to achieve that. This may require middleware.
• style and markup new gateway ? PARTIALLY completed
• implement Faravahar toggle [ with JINJA conditional logic ]
• implement Nuclear option [ JINJA conditional logic ]
• reduce account session handling features (like sign up et al) and render those templates inaccessible. ANSWER = Not in my code base as per: https://docs.djangoproject.com/en/4.2/topics/auth/default/#module-django.contrib.auth.views
• remove: "Warning Currently there is no database set to DATABASE_URL" notification at login
• Add Integer field annotation for "Timeout" in existing accounts options app to specify that it tracks time in "minutes" not "seconds" nor "hours". For more details on how to do this, you can search ChatGPT for: "django admin dashboard comment or label for integer fields"
• Purge 'accounts' app's Passphrase options/view
• Major refactor from "accounts" app to "controls" (This is big)
• Purge obsoleted "work_orders" app
• purge deleted and likely obsoleted db.sqlite3 instances BUT BE SURE TO KEEP the legit one: db.sqlite3

• There are 5 ways to make my Django project more secure. https://hackernoon.com/5-ways-to-make-django-admin-safer-eb7753698ac8
  • One of them is to: "Visual disntinguish environemnts". It's a great suggestion by color coding the Django admin panel. I should implement a color coded banner at the top of every web page when the Django Admin user is logged in but the "Nuclear" option (in accounts app) is toggled on blocking all other web vistors out because right now, if the Nuclear option is triggered, the the 'logout' link on the /portal page appears but clicking on it does nothing. This is because the ADmin User has access. To help elinate confusion, there should be a colour coded banner at the top of /portal and all the other pages on the website whent he Admin user is browsing and the Nuclear option is toggled.

"In a world where men do battle over whose version of God is most accurate, I cannot adequately express the deep respect and admiration I feel toward an organization in which men of differing faiths are able to break bread together in a bond of comradery, brotherhood, and friendship," - - On Freemasonry courtesy of Dan Brown in a 2009 interview as quoted on page 48-49 in Mark E Koltko-Rivera's (2011) Freemasonry: An Introduction (London England: Penguin Group)