created: 2024-11-15 05:20 tags: - daily-notes

Friday, November 15, 2024

<< Timestamps/2024/11-November/2024-11-14-Thursday|Yesterday | Timestamps/2024/11-November/2024-11-16-Saturday|Tomorrow >>

🎯 Goal

• [x] Actually solve the password reset problem for real.

🌟 Results

• Actually solved the password reset problem for real this time
• Resolved the Blog Details Footer Issue
• Resolved the iFrame not rendering issue
• Started working on resolving the 400 Error Page Handling issue
• Updated my Local Version to include a version of the production PostgreSQL database.

🌱 Next Time

• Configure pages for 400 Errors / site maintenance by working on the Handle 400 Error Pages issue

📝 Notes

Yesterday I thought I fixed the password reset issue but for some reason my form is always invalid. Found out about the django-mailer package which may be useful for sending email Asynchronously in the future.

Ended up consulting the Django Documentation to try to figure out why the hell I couldn't validate these forms. Specifically, I found the PasswordResetConfirmView Class code here.

I was able to FINALLY find this stack overflow post which solved my error. During the dispatch of the request in the PasswordResetConfirmView Django View the user's token is validated. During that process an Attribute called self.validlink is marked as True if the token was validated successfully and False if it was unsuccessful. Therefore, I was able to use this in my template to conditionally display Django Template code (templates/password_reset_confirm.html) whether the link was valid or not:

{% if validlink %}
    ...
{% else %}
    ...
{% endif %}

Now I get this page rendered if the token is validated during dispatch:

--redacted--

and I get this page if I give some invalid token:

--redacted--

I pushed changes to Production then validated that the workflow operated correctly in production (it did!!). FINALLY!

Ok NOW I can work on fixing the Blog details footer issue which should be interesting because I started working on this one before actually fixing the password reset issue, so it will be a learning experience with Git.

The main idea here is with the Blog App's Django View. Specifically in the BlogDetailView class of the blog/views.py file, I'm getting the queryset of all blog posts instead of all active blog posts:

def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        current_post_id = self.object.id

        # Get the chronologically adjacent posts of our current post
        ordered_posts = self.get_queryset()
        index_reference = next((i for i, post in enumerate(ordered_posts) if post.id == current_post_id), -1)

        context['previous_post'] = ordered_posts[index_reference - 1] if index_reference > 0 else False
        context['next_post'] = ordered_posts[index_reference + 1] if index_reference < len(ordered_posts) - 1 else False

        # Filter out the current post for other lists
        context['least_popular_posts'] = [post for post in Post.objects.all().order_by('num_comments') if post.id != current_post_id]
        context['all_posts_list'] = [post for post in Post.objects.all().order_by('-date_published') if post.id != current_post_id]
        return context

This was messy, and thankfully ChatGPT suggested a much more elegant solution that involved filtering on the Django QuerySet object directly:

def get_context_data(self, **kwargs):
        context = super().get_context_data(**kwargs)
        current_post = self.object

        # Get previous and next active posts efficiently
        context['previous_post'] = (
            Post.objects.filter(is_active=True, date_published__lt=current_post.date_published)
            .order_by('-date_published')
            .first()
        )
        context['next_post'] = (
            Post.objects.filter(is_active=True, date_published__gt=current_post.date_published)
            .order_by('date_published')
            .first()
        )

        # Get other lists efficiently
        context['least_popular_posts'] = (
            Post.objects.filter(is_active=True)
            .exclude(id=current_post.id)
            .order_by('num_comments')[:10]
        )
        context['all_posts_list'] = (
            Post.objects.filter(is_active=True)
            .exclude(id=current_post.id)
            .order_by('-date_published')[:10]
        )
        return context

This is a far better solution than my original. Pushed changes to Production and moved on.

Next I wanted to solve the MIME Error, looks like another Static Files rendering issue where A Fort Minor Solution can't find its proper files. The weird thing is it works on my local. this may have something to do with the iframe tag used to force the graphs into place there...

Sure enough, I'm getting the following error in the dev tools console:

Blocked script execution in '<URL>' because the document's frame is sandboxed and the 'allow-scripts' permission is not set.

All I needed to do was adjust the iframe tags to have the property of sandbox="allow-scripts", so that they looked like:

<iframe src="your-url.html" sandbox="allow-scripts"></iframe>

within the actual blog post itself. I'll need to update my database really quick via the pgadmin restore procedure:

heroku pg:backups:capture --app dimmin

Then found the backup number with

heroku pg:backups --app dimmin

This can then be downloaded via:

heroku pg:backups:download b008 --app dimmin

And hooked up to my pgadmin database via

pg_restore -h "localhost" -p "5432" -U "postgres" -d "dimmin-staging" -v "latest.dump"

However this didn't seem quite right... For instance, one of my blog post images was still surrounded by the <div> tags that I explicitly removed. I can see that isn't the case in my production database.

Turns out I can add the simple --clean flag after -v to delete any tables before re-creating them which works much better for me. Therefore, the full workflow for updating the PostgreSQL DB is:

heroku pg:backups:capture --app dimmin
heroku pg:backups:download b001 --app dimmin
pg_restore -h "localhost" -p "5432" -U "postgres" -d "dimmin-staging" -v --clean "latest.dump"

Now that my database was up to date, I had a better version of the backup in my local. I wanted to quickly look for a potential 400 Error page template and found my original one in my travel drive. I also found a contact form which I'll include for future use to allow people to contact me.

I checked out a new Git Branch to start handling 400 Error pages more gracefully to solve the Handle 400 Error Pages issue.

Notes created today

List FROM "" WHERE file.cday = date("2024-11-15") SORT file.ctime asc

Notes last touched today

List FROM "" WHERE file.mday = date("2024-11-15") SORT file.mtime asc

(Template referenced from Dann Berg, can be found here)