Allow admin users to alter text on Home and/or About page

[whikloj]

The Libraries' users are thinking about making pages with information in Drupal and providing direct links to the Login page. The thinking is this would make continued maintenance easier.

That is certainly possible and we would then make use of Django's logout redirect, but I wondered if Django/Python might make changes to the About page (and possibly the Home page) from within the tool feasible.

Not sure if this is desirable from a NCTR point-of-view, but thought I would suggest it.

[danloveg]

Sounds like you're thinking of moving certain templates to the database. I'd take a look at this project:

https://django-dbtemplates.readthedocs.io/en/latest/

Looks like you add its template loader to the loaders section of the Django settings. You don't need to remove the old loaders so I think this means you could still work with the templates on the filesystem, or in the database.
https://django-dbtemplates.readthedocs.io/en/latest/overview/#usage
https://docs.djangoproject.com/en/dev/ref/templates/api/#loader-types

It looks as if the default templates could be kept, but you can also override them in the database from the admin. Would that fit the bill for libraries? I'd be interested to see if this also applies to the email templates.

I do think this is a useful feature, especially if it means the site doesn't have to be re-deployed for a small change. Want to give the django-dbtemplates integration a shot?

[whikloj]

That looks like a beautiful project, I will give it a try and see what I can figure out. 👍

[whikloj]

Sooo, that project looks like it might have been abandoned. There are a variety of issues that I'm hitting, most of which have been solved by others but the PRs have either not been merged (access cache), or they have been merged (six moved out of django) but there has not been a new version cut since the 3.0 one which is 3 years old.

I opened an issue (121) on their tracker to see if anyone is alive over there, but if you want to use it we might need to fork the repo and fix it. Which then makes you the next best option (which can come with a following of wants).

My users still seem to want to use the University's Drupal instance to make the pages, so I might have to just remove some menu items in the end anyways.

I'll wait a bit and see if anyone responds to that issue, but you might want to think about what you'd like to see happen for this project.

[danloveg]

Hmm, okay. That's too bad the project seems abandoned.

So, when you say they want Drupal to make the pages, what do you mean by that? Would it just make sense for you to redirect the / and /about paths to external URLs outside of the transfer app?

If you wanted to go that route, you could change the home and about pages from TemplateView to plain view functions, and return an HttpResponseRedirect to the page you want (see here).

The new view functions would look like this:

# views.py
from django.http import HttpResponseRedirect

def external_index(request, redirect_url=None):
    return HttpResponseRedirect(redirect_url)

If you wanted to get fancy, you could replace the pages conditionally based on a setting.

# settings.py

INDEX_OVERRIDE = 'https://some.other.site.ca/'

# urls.py
from functools import partial

...

if settings.INDEX_OVERRIDE:
    index_path = path('', partial(views.external_index, redirect_url=settings.INDEX_OVERRIDE), name='index')
else:
    index_path = path('', views.Index.as_view(), name='index')

urlpatterns.append(index_path)

...

And if you wanted to be able to swap the path out with a different one without changing an environment variable, you could make a database model with the URLs for the overridden pages.

[whikloj]

Yeah I'm not sure what we'll do yet.

They will be maintaining pages in Drupal and will therefore be more familiar with the framework. I'm not sure how much changing there will actually be.

I appreciate the redirect advice, gives me more options to give them.

[whikloj]

I did some work on your suggestion of looking at a tool like Wagtail for the other issue of altering form elements. That could also apply to this issue, so I thought I'd tag it here.

I was able to somewhat integrate it. You can see the work here.

Major issues are that once you replace a url with a page then you can't seem to use the url function to reference it, you can see that I replaced things like {% url 'recordtransfer:index' %} with / and {% url 'recordtransfer:about' %} with /about to catch them in the wagtail framework. Not sure how you feel about that.

The other thing is pre-populating. You'd want to pre-setup a site and the default Home and About pages to be generated and ready to go on first use. Not relying on the user to populate them.

Anyways, work in progress but if you have a chance to look at it I would appreciate it.

[danloveg]

Good to know, Wagtail doesn't seem to really be fitting the bill. I think what we really want is for the site to be able to function as it is without any major changes (to urls or otherwise), but just slip in admin-edited templates if they define them.

Do you think there's value in including the django-dbtemplates project in this project and fixing its issues? If you do think so, I can look at fixing the errors and making it work with the application.

[whikloj]

I'm not sure, I never really got a chance to play with it. If you think it's worth it I can try to make a branch with the necessary PRs merged in and see if I can get it going.

[whikloj]

Ohhh now I remember. I do have a branch I wanted to test, but I was unclear how to get it installed in the python virtual environment so it replaces the existing one?

[danloveg]

Here's a relevant stack overflow for that:
https://stackoverflow.com/a/35998253/18183601

[whikloj]

Oh dbtemplates is pretty nice and easily fits this use case. You do need to understand a bit of how the templates work, but if you know the template names you can load one from the filesystem into the database and then edit it.

However for the editing individual forms elements you'd have to create full templates for each form with all the fields so each would be editable.

I'm going to try that next week, but here is a comparison if you want to try out dbtemplates too.
master...whikloj:issue-64

[whikloj]

Just thinking out loud, but if we could alter the dbtemplates admin page to list the existing templates on the filesystem, it would make it more user friendly. Of course, too user friendly and someone could break their site.

[whikloj]

Okay...so I think django-dbtemplates is the simplest solution to make alterations to page templates.

It is definitely not as user friendly as the wagtail editor, but it is nice and small. Perhaps some sort of live preview could be added to the template page to make it a little easier to edit the templates

Question is how do you want to handle the fact that the default project seems dead in the water. Include via git, publish under a different name?

[whikloj]

Or....join jazzband and see if you can help clear the logjam there. I fear doing that as I am not a seasoned Python/Django developer. But perhaps you are interested.

[whikloj]

Ooops

[danloveg]

The simplest way to incorporate django-dbtemplates would just be for us to copy the code into our repository and work on everything all in one place. That being said, if it were ever to be used in a different Django project, we'd have to make a separate repo, so maybe it does make sense to fork it to the NCTR's GitHub. I really don't want to deal with devs who aren't maintaining the project, and having to beg for pull requests to be merged. Doing the work ourselves is our best bet.

I haven't had a chance to look at your dbtemplates fork yet, but were there a lot of changes you had to make to make it work?

[whikloj]

Not really I just merged one of the existing PRs and made a slight change to fix the tests not that we necessarily care about that.

[danloveg]

I've just forked django-dbtemplates, and integrated into a branch in the repo. It looks really simple, but you're right that there isn't a clear indication of what templates already exist and which can be overridden.

I have a simple idea: lets make a migration that populates the templates that are editable so they appear in the admin by default. That doesn't require any changes to the code - but I think it'd be useful to see the default template on the filesystem. This would be a simple change to the code - I could add a view in the admin that loads the content of the template. What might be possible instead of a live preview of the template would be a "preview template" view.

[danloveg]

Check out the dbtemplates branch here:
https://github.com/NationalCentreTruthReconciliation/Secure-Record-Transfer/tree/dbtemplates

I made a migration to populate the templates that won't completely break the site by editing them. I didn't include the transfer forms, the profile page, or the sign up form.

I also enabled CodeMirror, which lets you edit the templates with syntax highlighting. There were some issues with that, so I fixed them in the NCTR's custom django-dbtemplates fork.

I also had the thought - some of these templates are only a small part of the site, so a live preview (or any preview) wouldn't make sense. It doesn't make sense to preview just the footer, for example. There would only be a certain subset of the templates that could be previewed - it may or may not be valuable if it's only for a few. Let me know your thoughts on that. WordPress gets around this by not actually applying the complete styles in the live editor.

[danloveg]

If you want to have the live preview or preview capability added to the administrator, please create a new issue and I'll address it in the dbtemplates repo.

https://github.com/NationalCentreTruthReconciliation/django-dbtemplates

It doesn't appear that you're able to create issues in a forked repo, so we'll have to keep the issues here in this repository.