enoren5 / tarot_juicer Goto Github PK

Under these conditions, when:

1. authentication is enabled (in AdminDashboard) using the ‘accounts’ feature
2. entering credentials (enter whatever, even fake) and then
3. clicking the ‘Register’ button
   The result: Django throws an “AttributeError at /register”. Full traceback here.

The traceback points to line 44 in accounts.views.py where the context dictionary variable is declared. Although beyond that, I am not sure what the traceback is referring to.

See here: https://tarot-testing.herokuapp.com/

The staging pipeline needs to become accessible and usable.

When I push my changes to the testing location on Heroku. The logs state:

$ heroku logs --tail -a tarot-testing
2021-05-14T19:29:40.000000+00:00 app[api]: Build started by user [email protected]
2021-05-14T19:30:39.975328+00:00 app[api]: Deploy 3679a8b2 by user [email protected]
2021-05-14T19:30:39.975328+00:00 app[api]: Release v17 created by user [email protected]
2021-05-14T19:30:42.313473+00:00 heroku[web.1]: State changed from crashed to starting
2021-05-14T19:30:48.927265+00:00 heroku[web.1]: Starting process with command `bin/start-pgbouncer-stunnel gunicorn tarot_juicer.wsgi`
2021-05-14T19:30:51.433054+00:00 app[web.1]: bash: bin/start-pgbouncer-stunnel: No such file or directory
2021-05-14T19:30:51.505341+00:00 heroku[web.1]: Process exited with status 127
2021-05-14T19:30:51.588131+00:00 heroku[web.1]: State changed from starting to crashed
2021-05-14T19:30:51.591718+00:00 heroku[web.1]: State changed from crashed to starting
2021-05-14T19:30:52.000000+00:00 app[api]: Build succeeded
2021-05-14T19:31:00.595004+00:00 heroku[web.1]: Starting process with command `bin/start-pgbouncer-stunnel gunicorn tarot_juicer.wsgi`
2021-05-14T19:31:03.910565+00:00 app[web.1]: bash: bin/start-pgbouncer-stunnel: No such file or directory
2021-05-14T19:31:04.012041+00:00 heroku[web.1]: Process exited with status 127
2021-05-14T19:31:04.131484+00:00 heroku[web.1]: State changed from starting to crashed
2021-05-14T19:31:05.404710+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/" host=tarot-testing.herokuapp.com request_id=26e6046d-b4b4-48c6-99c4-a62e58e1b89e fwd="99.239.208.191" dyno= connect= service= status=503 bytes= protocol=https
2021-05-14T19:31:05.956303+00:00 heroku[router]: at=error code=H10 desc="App crashed" method=GET path="/favicon.ico" host=tarot-testing.herokuapp.com request_id=1de1172f-654e-4366-9959-36daa1401ab6 fwd="99.239.208.191" dyno= connect= service= status=503 bytes= protocol=https

When prod breaks, how do I enable Django to temporarily show debugging data to help me troubleshoot when prod breaks?

I tried switching the DEBUG config environment variable in the Heroku Admin Dashboard from “False” to “True” (which had no effect).

Steps to reproduce the issue:

1. From the ‘portal’ landing page, visit the ‘card at random’ link. That should take you to the tarot_key template. All the data you see is entered using the generators app.
2. Next, when you click on the red “Card At Random” button, Django should be serving another tarot card from the generators app, but instead the web browser draws a 404 saying ‘page not found’.

I am expecting Django to serve one of the other generator entries such as: http://127.0.0.1:8000/tarot_key/1# or http://127.0.0.1:8000/tarot_key/12# however instead the web address bar indicates: http://127.0.0.1:8000/tarot_key/%7B%%20url%20'tarot_key_with_number'%20generator_number=next_card_number%20%'%7D which is completely broken.

There was a similar 404 error discussed in Issue #75 and PR #78. It might be related. I believe there were discussions in other Issues and PR's but I can't locate them right now.

For the Admin Dashboard: How do we enable a timeout when the admin user (or any user) makes 3 incorrect attempts? What recourse would the admin user (myself) have if I got locked out? Like how would I unlock myself?

When a web visitor clicks “Logout?” (at the bottom of portal.html template), the user returns to gateway.html. But when the web visitor in their web browser enters, http://127.0.0.1:8000/portal , the web visitor is routed to portal.html without having to enter the passphrase. This is a security risk. Instead, on gateway.html, the web visitor should always be required to enter a passphrase even if they have entered a valid passphrase successfully in the past.

Heroku offers an interesting feature to take a remote db from the cloud (located on aws) and mirror it to a local dev server, without having to handle/download/install the silo manually. John Elder explains how to do this at this unlisted YT video here. Part of the process as John Elder explains there involves copying and pasting the environment variable DATABASE_URL (under Credentials) from the Heroku dashboard.

Here is John Elder’s source code in his repo on GitHub specifically at line 88.

I have begun working with what I have learned from that tutorial in a separate branch titled: ‘content-edit-with-cloud-db’ which is tracked and available on my repo.

I have temporarily commented out the prior DATABASES variables in my settings.py and replaced it with this:

DATABASES = {
   'default': {
       'ENGINE': 'django.db.backends.postgresql_psycopg2',
   }
}
 
DATABASES['default'] = dj_database_url.config(default='postgres://xkdbsiijoknylq:c9f9d6cdb11bb69b34ba65ce4bb845cf1d14f905f1aba539d5ecd6515f1da19d@ec2-54-84-98-18.compute-1.amazonaws.com:5432/dcjnf0h34cfsc5')
 
db_from_env = dj_database_url.config(conn_max_age=600)
DATABASES['default'].update(db_from_env)

I was careful to run:

$ python manage.py makemigrations
$ python manage.py migrate
$ python manage.py makemigrations

ProgrammingError at /
column accounts_authtoggle.enable_protection does not exist
LINE 1: SELECT "accounts_authtoggle"."id", "accounts_authtoggle"."en...

This is the traceback in full: https://pastebin.com/Y8eGH57m

This bug/feature needs to be fixed. My local dev server should be able to run while using the Heroku (aws) db URL.

Ultimately, once the above feature is implemented, the next step will be to implement a conditional to control 3 different db cases (options). Django settings.py will check and use (in this order):

1. Heroku postgres (aws) locally. If this doesn’t exist, Python will move on to check and use:
2. db.sqlite3 locally. If this doesn’t exist, then Python will move on to check and use:
3. Heroku db (aws) remotely

I need a web analytics solution which:

1. is free
2. shows web visitor ip address, location (country), web browser, operating system, native screen resolution, and time spent on specific pages. Piwik/Matomo has this feature.
3. is easy to set up

Matomo meets all the criteria but Matomo is strictly for LAMP stacks. My project isn't a VPS LAMP stack. My project is deployed to Heroku. Is there any way to achieve Matomo's feature (described above) with other free/easy to set up services? Google Analytics is free and easy, but it doesn't have the web visitor tracking feature that Matomo has.

What other options are there out there that are easy to implement and shows data like in the screenshot I shared above?

I am expecting my site to have very little daily traffic. But when I share a link to a blog post with a close personal friend privately over email or Facebook, I'd like to be able to see which web pages they've viewed and for how long until they closed his web browser window or navigated away. This is the extent of my needs. For my purposes, I am uninterested in analyzing 'conversions' or tracking 'sales' figures.

If Google Analytics has a plugin which meets my needs, then your task will be to set it up and implement it!

I’m learning how to handle Postgres instances by backing them up and restoring them on Heroku for a Django project (a small rudimentary CMS). The amount of data is a few hundred kilobytes because it's just text that I am storing in my my db. I'm practicing backups and restores just to learn for fun.

I realize this is loosely related to Python/Django, but it does fall into the general category of development / programming. I hope my post is welcome here.

I downloaded the binary data to my local machine using this particular section of the Heroku doc.

The next step was to create an AWS account, including setting up Access Keys which I located in the dashboard and entered them into my local dev environment. I named my bucket. I uploaded the binary to S3.

I’ve made it all the way to the end of Heroku’s import Postgres guide.

I install the awscli package with pip which enabled me to presign my s3 bucket (which succeeded).

I am right at the final step of importing my backup to Heroku Postgres. I am so close!

My traceback at this point indicates that Heroku is expecting an HTTP 200 (request has succeeded) but instead it receives an HTTP 400 (can’t process) ‘due to the source URL being inaccessible’. This points towards the restrictive permissions in place on my AWS S3 bucket.

You can find my traceback in full at the bottom issue.

With regards to my AWS S3 bucket, in the dashboard, the main Permissions switch relevant here is the “Block all public access” option. Whether this checkbox is enabled or disabled (I carefully tried both), I encountered the same HTTP 200/400 in my traceback. This is where I believe the issue is.

I’m not sure what else to try. I’m also a little concerned that with the vast number of variables available for Amazon’s S3 service, I don’t know how I might share or export my configuration nicely for you people to take a closer look. What other information could I provide to better help you people help me?

Here is the restore command I am using:

$ heroku pg:backups:restore 'https://postgres-restore-tarot-juicer.s3.amazonaws.com/2021June25_8801def6-27e0-4b88-875b-842be5704f0b\?X-Amz-Algorithm\=AWS4-HMAC-SHA256\&X-Amz-Credential\=AKIAY6KWYZACZM3OX2O6%2F20210625%2FOhio%2Fs3%2Faws4_request\&X-Amz-Date\=20210625T111617Z\&X-Amz-Expires\=3600\&X-Amz-SignedHeaders\=host\&X-Amz-Signature\=d56d7156537e03b7714c76e51f23eac9b08753a31b963818708d86cc77787f31' HEROKU_POSTGRESQL_SILVER --remote heroku --app tarot-prod --confirm tarot-prod

 ›   Warning: heroku update available from 7.50.0 to 7.54.1.
Starting restore of https://postgres-restore-tarot-juicer.s3.amazonaws.com/2021June25_8801def6-27e0-4b88-875b-842be5704f0b\?X-Amz-Algorithm\=AWS4-HMAC-SHA256\&X-Amz-Credential\=AKIAY6KWYZACZM3OX2O6%2F20210625%2FOhio%2Fs3%2Faws4_request\&X-Amz-Date\=20210625T111617Z\&X-Amz-Expires\=3600\&X-Amz-SignedHeaders\=host\&X-Amz-Signature\=d56d7156537e03b7714c76e51f23eac9b08753a31b963818708d86cc77787f31 to postgresql-lorem-1... done

Use Ctrl-C at any time to stop monitoring progress; the backup will continue restoring.
Use heroku pg:backups to check progress.
Stop a running restore with heroku pg:backups:cancel.

Restoring... !
 ▸    An error occurred and the backup did not finish.
 ▸    
 ▸    waiting for restore to complete
 ▸    pg_restore finished with errors
 ▸    waiting for download to complete
 ▸    download finished with errors
 ▸    please check the source URL and ensure it is publicly accessible
 ▸    
 ▸    Run heroku pg:backups:info r039 for more details.

Right at the end there, it recommends to use this info command:

$ heroku pg:backups:info r038
 ›   Warning: heroku update available from 7.50.0 to 7.54.1.
 ›   Error: Multiple apps in git remotes
 ›     Usage: --remote staging
 ›        or: --app tarot-testing
 ›     Your local git repository has more than 1 app referenced in git remotes.
 ›     Because of this, we can't determine which app you want to run this command against.
 ›     Specify the app you want with --app or --remote.
 ›     Heroku remotes in repo:
 ›     tarot-prod (heroku)
 ›   tarot-testing (staging)
 ›
 ›     https://devcenter.heroku.com/articles/multiple-environments

This feature that I have started needs to be completed. To describe the feature, the whole website needs to be password protected in two separate ways:

1. The first way involves web visitors who land on the top level home page and select the red ‘Register’ hyperlink to create their own username and password. For testing purposes I’ve already created some fake credentials. You can test the current feature by entering this username: ‘testuser1’ and this password ‘testuser1’.
2. The second way involves web visitors who enter a universal ‘pass phrase’ into the without a corresponding username requirement. This is much less secure but I am curious to see it implemented anyways to give me something to learn from. One glaring issue I can identify already is that the ‘passphrase’ variable post request declaration inside accounts/views.py within the index function at line 80 is the problem area.

I’ve already got a basic username and password authentication scheme and logic inside the accounts app’s views.py. The major issue right now is even when a user enters the incorrect credentials or no credentials at all, the user is still able to traverse down to http://127.0.0.1:8000/tarot_key/19 .This webpage (and all other web pages) should be restricted to web users who have either entered a valid username/password or correct passphrase (without a username).

Using the tarot at random button raises the following error:

Environment:
Request Method: GET
Request URL: http://localhost:8000/at_random

Django Version: 2.2.9
Python Version: 3.5.2
Installed Applications:
['essays.apps.EssaysConfig',
'landings.apps.LandingsConfig',
'generators.apps.GeneratorsConfig',
'work_orders.apps.WorkOrdersConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles']
Installed Middleware:
['django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware']

Template error:
In template /home/sanip/Development/tarot_juicer/templates/base.html, error at line 0
no such table: generators_generator
1 : {% load static %}
2 :
3 : <!doctype html>
4 :
5 :
6 :
7 :
8 :
9 :
10 :

Traceback:

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/backends/utils.py" in _execute
84. return self.cursor.execute(sql, params)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/backends/sqlite3/base.py" in execute
383. return Database.Cursor.execute(self, query, params)

The above exception (no such table: generators_generator) was the direct cause of the following exception:

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/core/handlers/exception.py" in inner
34. response = get_response(request)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/core/handlers/base.py" in _get_response
115. response = self.process_exception_by_middleware(e, request)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/core/handlers/base.py" in _get_response
113. response = wrapped_callback(request, *callback_args, **callback_kwargs)

File "/home/sanip/Development/tarot_juicer/generators/views.py" in at_random
13. return render(request, 'generators/at_random.html', context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/shortcuts.py" in render
36. content = loader.render_to_string(template_name, context, request, using=using)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/loader.py" in render_to_string
62. return template.render(context, request)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/backends/django.py" in render
61. return self.template.render(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/base.py" in render
171. return self._render(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/base.py" in _render
163. return self.nodelist.render(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/base.py" in render
937. bit = node.render_annotated(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/base.py" in render_annotated
904. return self.render(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/loader_tags.py" in render
150. return compiled_parent._render(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/base.py" in _render
163. return self.nodelist.render(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/base.py" in render
937. bit = node.render_annotated(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/base.py" in render_annotated
904. return self.render(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/loader_tags.py" in render
62. result = block.nodelist.render(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/base.py" in render
937. bit = node.render_annotated(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/base.py" in render_annotated
904. return self.render(context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/template/defaulttags.py" in render
308. if match:

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/models/query.py" in bool
278. self._fetch_all()

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/models/query.py" in _fetch_all
1242. self._result_cache = list(self._iterable_class(self))

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/models/query.py" in iter
55. results = compiler.execute_sql(chunked_fetch=self.chunked_fetch, chunk_size=self.chunk_size)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/models/sql/compiler.py" in execute_sql
1133. cursor.execute(sql, params)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/backends/utils.py" in execute
99. return super().execute(sql, params)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/backends/utils.py" in execute
67. return self._execute_with_wrappers(sql, params, many=False, executor=self._execute)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/backends/utils.py" in _execute_with_wrappers
76. return executor(sql, params, many, context)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/backends/utils.py" in _execute
84. return self.cursor.execute(sql, params)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/utils.py" in exit
89. raise dj_exc_value.with_traceback(traceback) from exc_value

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/backends/utils.py" in _execute
84. return self.cursor.execute(sql, params)

File "/home/sanip/.virtualenvs/tarot/lib/python3.5/site-packages/django/db/backends/sqlite3/base.py" in execute
383. return Database.Cursor.execute(self, query, params)

Exception Type: OperationalError at /at_random
Exception Value: no such table: generators_generator

When a web visitor accesses http://127.0.0.1:8000/, Django needs to serve the templates/gateway.html. This is how it needs to look: https://imgur.com/qzcyPjS

Only when the web visitor enters a correct passphrase will Django then take the client to templates/portal.html. To accomplish all of that, you’ll need to:

• completely remove username/password combo functionality (which is already commented out in templates/gateway.html) as well as contained inside accounts/views.py. This all needs to be replaced.
• retain passphrase functionality

I’m trying to deploy my Django project to Heroku. I’m following along with the official Heroku doc titled, “Concurrency and Database Connections in Django”.

The Python module I am working with is dj_database_url which I have imported at the top of my settings.py. Near the bottom of the guide (above), they recommend using this line:

DATABASES['default'] = dj_database_url.config(conn_max_age=600, ssl_require=True)

That breaks my dev server (db.sqlite) locally resulting in this traceback: https://pastebin.com/uLZpA6R4

The project deployed on Heroku is broken with this traceback (postgres): https://pastebin.com/RSB8xc6M

dj_database_url needs to be properly configured to use sqlite locally (http://127.0.0.1:8000/) and postgres remotely (https://tarot-juicer-next-iter.herokuapp.com/).

What is wrong with line 102 in settings.py?

edit: grammar

1. The existing check box in Admin Dashboard (used to turn gateway or no gateway on/off) into a radio button instead.
2. An additional radio button option needs to be created for Auth toggle to swap HTML comments lines 18-23 with lines 25-35 in the gateway.html template. As a result, the gateway page will swap out image “Kittens” placeholder vs the other “santa” static file.
3. Implement a ‘nuclear’ option (radio button) to disable the entire passphrase HTML form on the gateway.html template. When turned on, it looks like it is now. But when turned off, instead of a text box to enter the passphrase, there is just an h3 which says: “Access Refused”. Although when a Django Admin user is logged into the Admin Dashboard, they should be able to still access the portal page and descend down into the rest of the website while all other web visitors are locked out.

Inside my .gitignore, line #’s 65 reads:

db.sqlite3

Yet the db.sqlite3 binary continues to be present inside the parent source folder and is still tracked when changes are made to the database. I Googled ‘gitignore not working’ which turns up a popular SO question titled “Gitignore not working” which suggests invoking:

git rm -rf --cached . 
git add .

I did exactly that but db.sqlite3 is still not ignored even though it should be.

Why is db.sqlite still being tracked?

It should be hidden.

There are two environment issues that need to be fixed.

Issue 1.

Here is the DATABASES environment variable inside my settings.py (lines 92-108):

SELECTED_DB = ""

VALUE = os.getenv('SELECT_DB')

if VALUE == "0":
   SELECTED_DB = "HEROKU_POSTGRESQL_SILVER_URL"
elif VALUE == "1":
   SELECTED_DB = "HEROKU_POSTGRESQL_NAVY_URL"

DATABASES = {
   'default': dj_database_url.config(
       env=SELECTED_DB,
       default='sqlite:///'+os.path.join(BASE_DIR, 'db.sqlite3'),
       conn_max_age=600)
   }

print(DATABASES)

'SELECT_DB' is an environmental variable (dictionary) declared inside Heroku’s dashboard which is paired with the value specified as an integer, either 1 or 0. On the next line, if the VALUE is 0, then dj_database_url.configures the db to be HEROKU_POSTGRESQL_SILVER_URL. If the value is 1, then dj_database_url.configures the db to be, HEROKU_POSTGRESQL_NAVY_URL. These are references to Postgres URIs which are also formed as configuration variables showing inside the Heroku dashboard. The first “SILVER” db contains Lorem Ipsum placeholder content and the second “NAVY” db contains meaningful blog content posted by the end user. This is my general understanding of what is going on here.

The problem with all of the above is that Heroku Postgres supports flexible and dynamic on-the-fly provisioning for creating, spinning up, spinning down, swapping around different apps, backing up, and restoring db silos. As you can read at that heading in the Heroku guide it says that to initialize (create) a fresh db, in the Heroku shell, you run: (local venv) $ heroku addons:create heroku-postgresql:hobby-dev

To view my current Postgres db addon composition and structure, you can use this command:

(local venv)  $ heroku pg:info
 ›   Warning: heroku update available from 7.47.11 to 7.47.12.
=== HEROKU_POSTGRESQL_NAVY_URL, DATABASE_URL
Plan:                  Hobby-dev
Status:                Available
Connections:           0/20
PG Version:            12.5
Created:               2021-01-09 20:43 UTC
Data Size:             10.0 MB
Tables:                21
Rows:                  110/10000 (In compliance)
Fork/Follow:           Unsupported
Rollback:              Unsupported
Continuous Protection: Off
Add-on:                postgresql-real-1

=== HEROKU_POSTGRESQL_ROSE_URL
Plan:                  Hobby-dev
Status:                Available
Connections:           0/20
PG Version:            13.2
Created:               2021-02-26 17:21 UTC
Data Size:             7.9 MB
Tables:                0
Rows:                  0/10000 (In compliance) - refreshing
Fork/Follow:           Unsupported
Rollback:              Unsupported
Continuous Protection: Off
Add-on:                postgresql-adjacent-58092

=== HEROKU_POSTGRESQL_SILVER_URL
Plan:                  Hobby-dev
Status:                Available
Connections:           0/20
PG Version:            12.6
Created:               2020-11-19 10:32 UTC
Data Size:             9.6 MB
Tables:                21
Rows:                  84/10000 (In compliance)
Fork/Follow:           Unsupported
Rollback:              Unsupported
Continuous Protection: Off
Add-on:                postgresql-lorem-1

To designate a primary database, you can use this command:

(local venv) $ heroku pg:promote HEROKU_POSTGRESQL_SILVER_URL (or whichever other db name is available as it appears in the list above). Here in the command line is where I should swap out / switch between databases and not statically coded inside settings.py (like it currently is in my first snippet above).

With the newly created ROSE db instance, the settings.py is out of date. I would need to add another elif condition which specifies a SELECTED_DB (as described above) as "HEROKU_POSTGRESQL_ROSE_URL" with a value of 2, and then add that config variables inside the Heroku dashboard manually. That’s not ideal, right? The db environmental variable should allow the Heroku sysadmin to change between db’s using the (local venv) $ heroku pg:promote <db name>

Issue 2:

I should be able to import (access) remote aws Postgres db’s locally by specifying the remote URL in settings.py in this format: postgres://USER:PASSWORD@HOST:PORT/NAME. This feature is described in John Elder’s Udemy course specified here.

This feature was actually already implemented in PR #79 but was lost and removed in subsequent PR’s (#80. #81, #82). This needs to be re-implemented. I tried implementing it myself just now by removing the VALUE/SELECTED switches and replacing them with this:

DATABASE_URL = "" # since this is the default handle as you can see above in the output for the command: $ heroku pg:info

DATABASES = {
   'default': dj_database_url.config(
       env=DATABASE_URL,
       default='sqlite:///'+os.path.join(BASE_DIR, 'db.sqlite3'),
       conn_max_age=600)
   }

But this throws an OperationalError.

To summarize, here is the takeaway:

The DATABASES environmental variable needs to be reconfigured inside settings.py to essentially enable:
1. the Heroku sysadmin to swap db’s using the $ heroku pg:promote command rather than updating settings.py every time a new db is spinned up/down.
2. the web developer to reference the remote db locally

“St Paul” content is empty when the remote Postgres DB is exported locally across all generator entries. Why is it not showing?

In the Admin Dashboard, for the "Description" box and "St Paul" box, the placeholder lorem ipsum content appears perfectly in db.sqlite3 in both. But on Heroku with Postgres, only the "Description" box content appears while the "St Paul" box content is absent (even though both are clearly showing in the Admin Dashboard). It's strange.

Django is serving a 500 error which you can see by visiting either of these two links:
http://tarot-testing.herokuapp.com/
https://tarot-prod.herokuapp.com/

Since DEBUG is set to False, it's not specific what the issue is. Below is the traceback in my terminal when trying to make migrations and migrate.

Your task is to resolve these configuration errors and report back here with what you did to resolve the configuration.

Here is the output:

$ heroku run python manage.py makemigrations -a tarot-prod

 ›   Warning: heroku update available from 7.50.0 to 7.54.1.
Running python manage.py makemigrations on ⬢ tarot-prod... up, run.1667 (Hobby)

Mode:  Secure !! 


Database Config:  {'default': {'NAME': 'd9eds0cfpna1li', 'USER': 'illaqljonmjula', 'PASSWORD': '3ffb301d551dd2d3033d0994d22e4836373bb1b1e16f205b81606aa057a6bb60', 'HOST': 'ec2-3-231-241-17.compute-1.amazonaws.com', 'PORT': 5432, 'CONN_MAX_AGE': 600, 'ENGINE': 'django.db.backends.postgresql_psycopg2'}} 

System check identified some issues:

WARNINGS:
accounts.AuthToggle: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the AccountsConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
accounts.PassPhrase: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the AccountsConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.BibliographyArticle: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.ContentChanges: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.CuratedSlashdot: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.CuratedWatchtower: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.EssayArticle: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.ObjectionsArticle: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
generators.Generator: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the GeneratorsConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
landings.AboutContent: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the LandingsConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
landings.EssayList: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the LandingsConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
No changes detected

Here is: $ heroku run python manage.py migrate -a tarot-prod

 ›   Warning: heroku update available from 7.50.0 to 7.54.1.
Running python manage.py migrate on ⬢ tarot-prod... up, run.2824 (Hobby)

Mode:  Secure !! 


Database Config:  {'default': {'NAME': 'd9eds0cfpna1li', 'USER': 'illaqljonmjula', 'PASSWORD': '3ffb301d551dd2d3033d0994d22e4836373bb1b1e16f205b81606aa057a6bb60', 'HOST': 'ec2-3-231-241-17.compute-1.amazonaws.com', 'PORT': 5432, 'CONN_MAX_AGE': 600, 'ENGINE': 'django.db.backends.postgresql_psycopg2'}} 

System check identified some issues:

WARNINGS:
accounts.AuthToggle: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the AccountsConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
accounts.PassPhrase: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the AccountsConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.BibliographyArticle: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.ContentChanges: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.CuratedSlashdot: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.CuratedWatchtower: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.EssayArticle: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
essays.ObjectionsArticle: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the EssaysConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
generators.Generator: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the GeneratorsConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
landings.AboutContent: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the LandingsConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
landings.EssayList: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
        HINT: Configure the DEFAULT_AUTO_FIELD setting or the LandingsConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.
Operations to perform:
  Apply all migrations: accounts, admin, auth, contenttypes, essays, generators, landings, sessions
Running migrations:
  No migrations to apply.

The Admin middle-ware implemented in PR #117 (originally to resolve Issue #111), needs to be extended so that when accounts / Nuclear option is switched on, it now shows a 256px tall banner with large font that says: "Admin Only Access" at top of every web page (all templates) which informs the Admin that only they are logged in and only they have access to the website and that everyone else is restricted.

https://DN.com successfully redirects to https://www.DN.com, which is great. But http://DN.com or http://www.DN.com does not redirect to https://DN.com. How do I ensure that when a web visitor enters my address without https: (only http), it successfully re-directs to the ssl address?

My Domain Name registrar is through Google.

When setting up my DN, I followed these two guides:

• https://devcenter.heroku.com/articles/custom-domains
• https://stackoverflow.com/a/56919434/6095646

Admin Dashboard banner (at login and after login) which indicates which PostgreSQL DB is active on Heroku.
Check out: $ heroku pg:info --app tarot-prod (copied below).

The Django Admin Dashboard sign on page (as well as after having successfully logged in) needs a banner to notify/indicate the user which DATABASE_URL is in use, as well as the Add-on name.

For example, if HEROKU_POSTGRESQL_NAVY_URL/ postgresql-real-1 is promoted as active and in use, then Admin Dashboard needs to say that in the form of a banner

Here are all the PostgreSQL DB's currently available for my project:

$ heroku pg:info --app tarot-prod
=== DATABASE_URL, HEROKU_POSTGRESQL_SILVER_URL
Plan:                  Hobby-dev
Status:                Available
Connections:           0/20
PG Version:            12.7
Created:               2020-11-19 10:32 UTC
Data Size:             8.2 MB
Tables:                0
Rows:                  0/10000 (In compliance)
Fork/Follow:           Unsupported
Rollback:              Unsupported
Continuous Protection: Off
Add-on:                postgresql-lorem-1

=== HEROKU_POSTGRESQL_NAVY_URL
Plan:                  Hobby-dev
Status:                Available
Connections:           2/20
PG Version:            12.7
Created:               2021-01-09 20:43 UTC
Data Size:             9.5 MB
Tables:                21
Rows:                  113/10000 (In compliance)
Fork/Follow:           Unsupported
Rollback:              Unsupported
Continuous Protection: Off
Add-on:                postgresql-real-1

=== HEROKU_POSTGRESQL_PUCE_URL
Plan:                  Hobby-dev
Status:                Available
Connections:           0/20
PG Version:            13.3
Created:               2021-03-20 17:37 UTC
Data Size:             8.2 MB
Tables:                0
Rows:                  0/10000 (In compliance)
Fork/Follow:           Unsupported
Rollback:              Unsupported
Continuous Protection: Off
Add-on:                postgresql-animate-93816

1. For the accounts app, the Admin in the AdminDashboard should be able to view a list of current active web visitor sessions in progress. The admin should have an option to terminate a single web visitor session (kick them back out to gateway.html requiring them to re-enter their passphrase).
2. When the Admin user unchecks the AuthToggle object box that should terminate all active web visitor sessions and all current web visitors should be automatically kicked out (redirected back to gateway.html) and be required to enter their passphrase again.

Lines 16-20 in the bibliography.html template read:

This in turn causes each new line to stagger as it appears when Django serves the template like this: https://imgur.com/grjpOpS

This behaviour (where each line staggars automatically in the bibliography) needs to be replicated for when Django serves watcthower.html where the bibliography is presented at the bottom of that template.

Django throws CSRF 403 Forbidden intermittently. It’s difficult to reproduce every time. It only happens in production, never locally while testing. This issue requires:

1. An answer to explain: Why is this happening?
2. Ensure that it doesn’t happen going forward

I’m experimenting with swapping different PostreSQL DB instances in and out on Heroku. I’ve got one instance for Lorem Ipsum content and the other instance for meaningful, quality blog content. The first DB was provisioned by a previous freelancer which works well. It is populated with placeholder content.

Now I am trying to spawn a fresh DB from scratch and reconfigure. I’ve got it mostly set up but Django is throwing a Programming Error and I have no clue why. Here is the full error. Here is the main description of the error:

ProgrammingError at /admin/generators/generator/
relation "generators_generator" does not exist
LINE 1: SELECT COUNT(*) AS "__count" FROM "generators_generator"

So far I’ve used Heroku’s official doc explaining how to set up a PostreSQL DB (specifically the provisioning section). I also read “Managing Add-ons”.

To experiment with this new DB instance today, I also leveraged the console log provided by the previous freelancer for the prior Issue (#57). Here it is.

Here are all the terminal commands I used in sequence in a pastebin. As you can see in there, I made a deliberate effort to migrate and make migrations (twice).

What am I missing?

edit: grammar correction

When website visitors submit credentials to register for the first time, rather than immediately gaining access to site contents, they must now be presented with the template inside templates/accounts/pending.html which is just a basic page that says: “Pending approval” in heading tags.

The AdminDashboard should then present a list of users who have attempted to create login credentials. Once the admin approves the user’s application (by flipping a bool checkbox), the user must be automatically sent an email informing them that they have been approved informing them that they can now access the website.

There must no longer be a default username/password combo defined inside settings.py. (at the bottom). Instead the usernames and passwords need to be submitted in the register.html template.

• Write and deploy separate settings.py configuration files, one for production and another for the local dev environment. The remote production settings.py must have:
  • /admin/ (dashboard) path renamed to something obscure
  • debug turned to False remotely but True locally
  • ALLOWED_HOSTS must be an environmental variable as defined in settings.py. In testing locally, ALLOWED_HOSTS can be ['*'] but in prod ALLOWED_HOSTS is hidden as specified as config vars in the Heroku dashboard
• requires SSL connections with dj_database_url.config() parameter
• enable timeout mechanism for Admin Dashboard login page so that if someone enters a username/pass combo incorrectly 20 (not 3) times, they have to wait 1 hour.
• resolve all of these other warnings:

(heroku) $ python manage.py check --deploy
WARNINGS:
?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS setting. If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems.
?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True. Unless your site should be available over both SSL and non-SSL connections, you may want to either set this setting True or configure a load balancer or reverse-proxy server to redirect all connections to HTTPS.
?: (security.W009) Your SECRET_KEY has less than 50 characters or less than 5 unique characters. Please generate a long and random SECRET_KEY, otherwise many of Django's security-critical features will be vulnerable to attack.
?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions.
?: (security.W016) You have 'django.middleware.csrf.CsrfViewMiddleware' in your MIDDLEWARE, but you have not set CSRF_COOKIE_SECURE to True. Using a secure-only CSRF cookie makes it more difficult for network traffic sniffers to steal the CSRF token.

When Django serves the watchtower.html template, the bibliography (referred to as biblio_obj.biblio) - - it is empty. Here are the relevant lines from templates/essays//watchtower.html template:

Here is the class object declared inside the essays/models.py:

I’ve narrowed down the problem to essays/views.py at line number 34 in this context:

That’s my best effort at telling Django to serve the bibliography text content for the essays app. It’s not working as I expect. I am expecting the biblio content to appear at the bottom of the web page. Instead, it is empty.

The experimental code with the problem described above can be found on the remote branch titled meta-and-biblio-work located here.

When adding a thumbnail for a generator, K0.jpg (“The Fool”) and K21.jpg (“The World”) are getting renamed with a small hash appended to the end which causes Django to serve an empty thumbnail. I understand that the reason why is because inside the /static/img/thumbnails directory there is a duplicate thumbnail already named K0.jpg and K21.jpg. . The solution locally is to manually enter the thumbnails directory and delete all the duplicate K0.jpg and K21.jpg’s (including the ones with the hashes) and then locate the generator inside the Admin Dashboard and re-upload it. However in production on Heroku in the cloud, the static directory is delegated out to whitenoise which is a wrapper to integrate static files hosted on AWS. So I can’t selectively delete static files.

In the context of Heroku and AWS, how do I manually remove duplicate thumbnail static files?

When a visitor lands on https://localhost:8000/article/all_content_dump/, I am expecting Django to serve /templates/essays/all_content_dump.html as specified at line 13 in /essays/urls.py. However right now, Django returns a 404. This needs to be corrected.

The other three lines inside that same urls.py need to route correctly as well:

• 'article/objections/'
• 'article/content_changelog/',
• 'article/bibliography/'

Document all error messages / tracebacks you encounter while deploying to Heroku with PostgreSQL

You may need to explain what you did / changed to resolve each error / traceback.

When you are done, you must share your entire shell command input/output history in a pastebin

You may also need to answer any potential questions I may have to clarify why a certain command was necessary.

Correct 404 Page not found at these web addresses:

• https://tarot-juicer-next-iter.herokuapp.com/article/watchtower
• https://tarot-juicer-next-iter.herokuapp.com/article/slashdot

It says: “Article does not exist” when they actually do exist.

Current state: https://imgur.com/a/UMAUEQ4

Mock up (new feature): https://imgur.com/a/iP0WksK

The buttons need to appear the same at all resolutions (not just mobile resolutions, but desktop resolutions as well).

The arrow glyphs need to be nicer than HTML defaults.

I created a feature branch which is already tracked remotely on GitHub in the branch named: add-prevs-next-buttons .

_alerts.html partial: Was originally written when bootstrap was used to position, theme and colorize it. Without bootstrap this time, I need the alert to disappear after a 15 second timer or until the web user clicks the “X” button. Right now there is no timer and clicking the “X” button doesn’t do anything.

The PostgreSQL db (currently deployed remotely on Heroku) needs to be inflated with “Lorem Ipsum” placeholder content. There is currently an automation script in the scripts/ directory in the root source code tree which already inflates db.SQLite3 locally which is excellent. But this script needs to now be modified to inflate the remote Heroku PostreSQL db as well.

To emphasize, it would be great to have a working PostgreSQL db locally but for this issue, the goal is to have this automation script inflate the remote db on Heroku. Heroku has a helpful "Add Contributor" feature which enables team members like you to experiment and play with settings on the remote host. It's safe if it breaks or doesn't work because everything is still in testing status - - nothing is in production.

1. Right now it isn’t working as intended. See here: https://youtu.be/X1hw6lEjsV8 As you can see in that video, whether the box is checked or unchecked, it is always protected by the gateway template. Instead, only when the option box is checked, the site should be protected by the passphrase gateway page and when the option box is unchecked, landing on http://127.0.0.1:8000/ should route to http://127.0.0.1:8000/portal.
2. The language for the auth toggle object needs to be renamed. Instead of “Active”, it needs to say: “Enable Protection?”. And rather than “AuthToggle object (12)”, it should say: “Options”.
3. When the site is not protected by the gateway:
   • The ”Logout?” link on the http://127.0.0.1:8000/portal template should disappear
   • “Home” on the partials/_navbar.html element should also disappear

For the gateway’s passphrase feature, right now there is only one passphrase. It is declared inside settings.py at line #172. This needs to become dynamic so that the Admin user from the Dashboard should:

• be able to add multiple passphrases (potentially dozens, maybe even hundreds)
• have the ability to “turn on” a check box to specify that a given passphrase is valid and to turn off to invalidate a passphrase.

The passphrase should no longer reside inside settings.py. Instead, passphrases need to be determined by the admin in the AdminDashboard for this accounts app. The default passphrase is blank, meaning that when the SQL server is set up for the first time, there is no passphrase and no website visitor can enter.

At narrow mobile-size resolutions, when Django serves the tarot_key template and when the web user selects the red ‘show/hide album’ button, the pixel spacing between the carousel and the two red buttons needs to increase. Line 561 in tarot_key.css currently reads: margin-top: 50px; The buttons are positioned correctly when the tarot_key template is served. However when the web user selects the red ‘Show / Hide Album’ button, the spacing between the carousel images and the red buttons is way too large. So in my attempt to fix this, I adjust line 561 to: margin-top: -18px;. This corrects the button-carousel spacing when toggled but when untoggled, that in turn causes the navbar menu to overlap and partially conceals the red buttons. How do I adjust the margin spacing to reposition properly at all window widths and with the button toggled / untoggled?

The ‘accounts’ app needs a button in the Admin Dashboard which enables the super user to toggle the entire authentication app (‘gateway’ page) on or off. When the Admin switches the button ‘on’, the username/password/passphrase combo on the gateway page is required. But when the admin switches the Admin toggle button off, web users landing on the top level ‘gateway’ page (which is referred to within the ‘index’ function located inside the new ‘accounts’ app I created) redirects to portal, skipping authentication all together. To summarize, I need an Admin button to toggle authentication protection ‘on’ or ‘off’. So there should be two modes: ‘protected’ (authentication required) and unprotected (authentication not required). When switched off, when web users who land on the homepage, Django should serve the ‘portal’ template instead of the ‘gateway’ template.

With the latest push of the master branch deployed to Heroku, Django throws a
ProgrammingError at /. It’s because there is missing default data for the account toggle bool. Full traceback here. You can see it here in its current state on our remote deployment of the project using PostgreSQL: https://tarot-juicer-in-production.herokuapp.com/

I believe this is a problem both when testing remotely and locally. To reproduce the error, simply try generating an db.sqlite3 binary from scratch for the first time. One solution is to manually enter the row data using a GUI tool such as sqlite browser or by entering the data in the sqlite shell. But this needs to be fixed.

It’s also important to understand that a previous freelancer explains how to use this accounts_authtoggle feature by describing that a management command is required. To use it, simply invoke $ python manage.py create_fake_authenticated_user inside the project directory which automatically creates a user instance with the credentials provided in settings.py. Using this passphrase as declared inside settings.py, web visitors can enter it to gain access to the site.

The JavaScript carousel album slider (for the tarot_key template) is ‘jammed’. The expected behavior is to scroll all the way back and forth from beginning to end. However right now it only budges a little bit.

The issue is better demonstrated at narrower resolutions (especially mobile)

Incorrect (on about page): https://i.imgur.com/0x2HrWL.jpg
Correct (on tarot_key page): https://i.imgur.com/DZa1JLx.jpg

The Creative Commons thumbnail should appear on the about page like it already does on the tarot_key page.

When Dango serves the watchtower.html template, the blockquote parses correctly, as it appears in this pic here: https://i.imgur.com/8nIm6oH.jpg
To experiment and see for yourself, here is the location on my website on my testing pipeline on Heroku: https://tarot-testing.herokuapp.com/article/watchtower/

But when Django serves the tarot_key.html template, the CSS doesn’t parse: https://i.imgur.com/IgtUxR7.jpg
For your reference, here is the page on my site where the template being served (is parsing incorrectly): https://tarot-testing.herokuapp.com/tarot_key/1

Why is the blockquote not parsing when Django serves the tarot_key.html template and could you fix this?

Here is the HTML:

<blockquote class="scholar"><p class="quoted">Aenean tristique justo vel tristique faucibus. Pellentesque congue eleifend quam, posuere finibus urna tincidunt et. Pellentesque finibus congue dapibus. In enim felis, vulputate eu mauris ut, tincidunt fringilla metus. Integer vitae egestas sem, in euismod ipsum. Cras iaculis euismod convallis. Proin ac gravida odio. Nullam aliquet non arcu non accumsan. Fusce tempor enim sit amet pulvinar aliquam. Morbi nisl quam, vehicula ac porttitor et, finibus nec nulla. Sed rutrum ultricies gravida. Curabitur dapibus lacus a enim consequat elementum.</p></blockquote>
<small class="reference">(Anonymous 1615) </small>

Targeting those elements and classes, here is the CSS from tarot_key.css:

 blockquote {
    border: 1px solid #999;
    page-break-inside: avoid;
  }

  blockquote > .scholar {
    width: 80%;
    font-family: "Domine", "Oxygen Mono", monospace, Cambria, "Hoefler Text",
      Utopia, "Liberation Serif", "Nimbus Roman No9 L Regular", Times,
      "Times New Roman", serif;
    font-size: 80px;
    color: #6c6c6c;
    text-align: justify;
    font-style: italic;
    padding: 25px;
    font-weight: bold;
    quotes: "\201C""\201D""\2018""\2019";
    box-shadow: 1px 2px 3px black;
  }
  .scholar p {
    font-family: "Domine", "Oxygen Mono", monospace, Cambria, "Hoefler Text",
      Utopia, "Liberation Serif", "Nimbus Roman No9 L Regular", Times,
      "Times New Roman", serif;
    margin: 0 auto;
    color: white;
    width: 80%;
    /*background-image: linear-gradient(-100deg, black 0%, gray 100%);*/
    padding: 1em;
    border-radius: 5px;
    /*box-shadow: 1px 2px 3px black;*/
  }

  .reference {
    display: block;
    font-size: 0.875em;
    /* margin-right: 3cm;*/
    margin: auto;
    text-align: center;
    /* margin-right: 2em;*/
    margin-top: 25px;
    background: rgba(0, 0, 0, 10%);
    border-radius: 5px;
    color: white;
    box-shadow: 1px 2px 3px black;
    width: fit-content;
  }

For prod, add custom default pages for:

• 404: <h1>Page does not exist </h1>
• 500: <h1>Server error </h1>

You don’t need to worry about designing / styling them. I will do this. Just establish the basic functionality.

Heroku offers an interesting feature to take a remote db from the cloud (located on aws) and mirror it to a local dev server, without having to handle/download/install the silo manually. John Elder explains how to do this at this unlisted YT video here. Part of the process as John Elder explains there involves copying and pasting the environment variable DATABASE_URL (under Credentials) from the Heroku dashboard.

Here is John Elder’s source code in his repo on GitHub specifically at line 88.

Like John Elder explains, my local dev server should be able to run while using the Heroku (aws) db URL.

The next step will be to implement conditional logic in settings.py to control 3 different db cases (options). Django settings.py will check and try to use (in this order):

1. Heroku postgres (aws) locally. If this doesn’t exist, Python will move on to check and try to use:
2. db.sqlite3 locally. If this doesn’t exist, then Python will move on to check and try to use:
3. Heroku db (aws) remotely

Issue #77 replaces Issue #73.

Static thumbnails (generators model) is not showing when Django serves tarot_keys.html template.

You can view the issue by navigating here: https://tarot-juicer-next-iter.herokuapp.com/tarot_key/8#
and then selecting the red: “Show/Hide Album” button. As you can see, the thumbnails aren’t parsing.

Here is a screenshot pointing out the issue: https://i.imgur.com/cPWfmwI.jpg

I tried running collect static in my heroku shell with $ python manage.pt collectstatic which produces this error:

File "/app/.heroku/python/lib/python3.9/site-packages/django/contrib/staticfiles/management/commands/collectstatic.py", line 138, in collect raise processed whitenoise.storage.MissingFileError: The file 'css/compass/css3' could not be found with <whitenoise.storage.CompressedManifestStaticFilesStorage object at 0x7f0dc9b58d90>. The CSS file 'css/tarot_key.css' references a file which could not be found: css/compass/css3
Please check the URL references in this CSS file, particularly any relative paths which might be pointing to the wrong location. The specific object with the issue is declared at line 12 in generators/models.py: tarot_card_thumbnail = models.ImageField(upload_to='thumbnails/')

This error needs to be corrected.

There should be a control button option showing inside the Django Admin Dashboard which swaps one db (production content) out for another (placeholder content) which enables the Django admin superuser to toggle between either one on the fly.

The carousel tarot cards appear in random order. Instead they should ascend in sequential order (0 through 21) accomplished by using the number class object specified in generators/models.py

When Django serves gateway.html:

• There is a red passphrase error banner that appears at the top by default. Instead, the default configuration should be no red banner at all.
• When a web visitor enters an incorrect passphrase, the red banner should be triggered saying: “Invalid credentials”. That is is already implemented and working. However the problem with that right now is it just sits there permanently. Instead it should disappear after 5 seconds (timer). I believe this can be achieved with some JS.
• There is a gap between the left border of the browser window and where the red banner begins. Instead, the red banner should extend all the way to the edge of the browser window (right now there is a gap): https://imgur.com/a/PeZEhcB
• Why does the image and web contents not scale at mobile resolutions? When emulating mobile screen size in Chrome Tools, all the content becomes really tiny. The kitten image and text should remain large enough to see at mobile resolutions without having to use Bootstrap.

publish/unpublish toggle button in Admin Dashboard for the ‘essays’ app for article function in ‘essays/views.py’. The new ‘is_published’ class object will be defined inside essays/models.py at line 12. That is where the Bool belongs.