Re: Ability to change LoginView inside custom AdminSite

[Dipankar]

Read documentation for customization. I hope you need to pass template
parameter and form class. That's all.

On Fri, May 15, 2020 at 7:44 PM Nikita Krokosh  wrote:

> Hello everyone.
>
>
> There's a way to set your own AdminSite class as said in docs:
>
>
> https://docs.djangoproject.com/en/3.0/ref/contrib/admin/#overriding-the-default-admin-site
>
>
> But I also want to change login view behavior.
>
> I want to replace *LoginView* in
>
> *django.contrib.admin.sites.AdminSite.login*
>
> method (by analogy with for example *login_form *parameter in the same
> *AdminSite* class).
>
>
> I need it to write custom logic in *form_valid* method, and it looks
> dirty and unnecessary to copy-paste whole login view code.
>
> Can project code be improved this way?
>
>
> Best Regards.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0a5f010a-df61-a7ce-e62f-281108c8dfd8%40gmail.com
> 
> .
>


-- 
Warm Regards,
Dipankar B.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFdBwp8-RKCY3mqXtq0sEqnBXL2pFNTZNJda_qpOQXCrM_UvQQ%40mail.gmail.com.

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

[אורי]

I very much prefer a slug "to-be-or-not-to-be-that-is-the-question"
than "be-or-not-be-question" (which doesn't make sense).
אורי
u...@speedy.net


On Wed, Apr 8, 2020 at 11:35 PM Andy Chosak  wrote:

> Automatic slug generation in ModelAdmin via prepopulated_fields
> 
> uses a urlify.js
> 
> file which, among other behaviors, removes certain stop words
> 
> from the slug. For example, a string like "To be or not to be, that is the
> question" will generate a slug "be-or-not-be-question", not
> "to-be-or-not-to-be-that-is-the-question" as one might expect. I’d like to
> solicit feedback on the idea of removing this logic so that slugs can
> contain these words.
>
> For reference, the current list is: a, an, as, at, before, but, by, for,
> from, is, in, into, like, of, off, on, onto, per, since, than, the, this,
> that, to, up, via, with.
>
> Django ticket #30538 
> mentions this behavior as part of a more general comparison between
> urlify.js and Python slugify
> .
> It was closed as wontfix due to reasons of backwards compatibility. Per the 
> triaging
> guidelines
> ,
> I’m making this post to solicit feedback on the more specific question of
> addressing stopword removal in the JS code only -- not to try to address
> any other differences in behavior between these two methods. There’s been
> quite a bit of discussion on generating slugs for non-English languages
> (for example #2282 ), and
> this post is not intended to reopen that discussion.
>
> The current list of stopwords being removed seems to have been the same since
> at least 2005
> 
> (the earliest code I can find including this logic). Some of these words
> feel a little unexpected, for example “before” and “since”. After 15 years
> it seems reasonable to revisit the list and consider whether it still makes
> sense.
>
> Was removal of these words introduced for SEO reasons? If so, is this
> still a recommended default behavior? In 2020, search engines like Google
> seem smart enough to interpret them properly. Here's
>  an arbitrary page that
> discusses this and includes a much longer list of what might be considered
> stopwords. As another datapoint, the popular WordPress Yoast SEO plugin
> used to remove stopwords, but stopped doing so
>  a few years back.
>
> Potentially outdated SEO concerns aside, does this behavior still align
> well with the needs and desires of Django users? Is this something this
> community would be open to revisiting? Thanks for your consideration.
>
> (One minor point on language support: allowing these words would help to
> resolve at least some of the unequal treatment given to English over other
> languages, for example #12905
> . See also wagtail#4899
> , from which much of this
> post has been copied, for an example of how this logic impacts a
> Django-based CMS.)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fb6c9596-951d-4102-91b5-b5fd9c8c6340%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeG3G_NCp%3DjGcGggMg1zCUMd-DPAZo2pEJgC5UaM__k4ww%40mail.gmail.com.

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

[Tim Graham]

I'm in favor of the change. It seems to me that most slugs I see these days 
have stop words in them and they read better because of that. I don't think 
JavaScript warnings would be helpful. A release note is sufficient. Admin 
users still get a preview of the slug and can edit it if needed.

On Friday, May 15, 2020 at 6:44:12 PM UTC-4, Scott Cranfill wrote:
>
> Does anyone else have an opinion on whether or not we should still be 
> removing these stopwords?
>
> Hopefully someone more involved in i18n can weigh in.
>>
>
> I'm not sure if there are any i18n concerns here. In fact, ceasing this 
> practice removes the impetus for the recurring issues being raised about 
> how this practice negatively affects the experience for users of other 
> languages, or doesn't remove words in their language, etc.
>
> Thanks for the suggested code, Adam. On the topic of deprecation, in 
> general: Andy I weren't really sure how to approach that for a 
> JavaScript-only change. We can't throw deprecation warnings in the Django 
> console like we could if we were talking about Python code, can we? I could 
> see adding some more aggressive messaging, maybe even in the Admin?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bd4e8c7d-4f7e-4c00-9e8b-49378eb261ee%40googlegroups.com.

Re: Proposal: django project name

[f.holop]

Christian González - Wed, 13 May 2020 at 22:13:34
> TL;DR: Django has no (builtin/explicit) settings variable like
> PROJECT_NAME. Should have.

4 of those were comments (i wish the project templates stopped doing that)

3 of those were env variables which a deployment can override with
an actual environment variable anyway...


introducing variables/constants into the settings/etc can help but
sometimes it also makes it more rigid and cluttered.  it's a balancing
act that has a different sweet spot for everyone.

but there is nothing stopping you from using one. i do.

some other potential uses:

- logging setup
- ADMINS
- FORMAT_MODULE_PATH

-f
-- 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2020051525.GC3895%40obiit.org.

Re: Reverting Django 3.1. to Django 3.0.6 raises "binascii.Error: Incorrect padding".

[f.holop]

Adam Johnson - Fri, 15 May 2020 at 17:53:21
> At least two of the major database servers that Django supports, PostgreSQL
> and MySQL, provide zero downgrade-ability. It's too hard for them to do.

while this is now officially true for both MariaDB and MySQL,
until recentlyish it was possible to downgrade them after carefully
reading changelogs.  This is now unsupported and even runtime errors
are generated.

AFAIK postgresql is/was always safe to upgrade/downgrade if staying on
the same major version.

having said that i think downgradability requires massive engineering
resources for very little return in case of a project like django.

long story short: never upgrade without reading changelogs, running the
testsuites, and deploying on test/staging first.  It's not simply a
matter of bumping a number in requirements.txt, although it has happened
many times that no other changes were required :}

-f
-- 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20200515231835.GB3895%40obiit.org.

Re: Proposal: Allow stopwords in slugs generated by ModelAdmin.prepopulated_fields

[Scott Cranfill]

Does anyone else have an opinion on whether or not we should still be 
removing these stopwords?

Hopefully someone more involved in i18n can weigh in.
>

I'm not sure if there are any i18n concerns here. In fact, ceasing this 
practice removes the impetus for the recurring issues being raised about 
how this practice negatively affects the experience for users of other 
languages, or doesn't remove words in their language, etc.

Thanks for the suggested code, Adam. On the topic of deprecation, in 
general: Andy I weren't really sure how to approach that for a 
JavaScript-only change. We can't throw deprecation warnings in the Django 
console like we could if we were talking about Python code, can we? I could 
see adding some more aggressive messaging, maybe even in the Admin?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9bae6eba-2046-4270-b16b-69fe2b2c8e87%40googlegroups.com.

Re: Proposal: django project name

[Christian González]

Hi Adam,
>
> TL;DR: Django has no (builtin/explicit) settings variable like
> PROJECT_NAME. Should have.
>
>
> I can see how it would be useful in several situations. But in most
> long-lived projects I've come across, the "project name" is different
> to the website name (or names, plural, if it has evolved into multiple
> brands). Additionally, there's already the ability for a "Site name"
> through the contrib.sites framework, and translations complicate the
> idea of a single name. I'm not sure /another/ axis of naming would
> make things easier. Sticking to Python imports and file paths to glue
> together things in code seems favourable.

Definitely, that's the problem. I didn't mean "Site name" - which
corresponds to maybe "project title" in my project. This would be
translatable too.

I meant a machine name, namely the python module which IS the main
project. Maybe name it DJANGO_PROJECT_MODULE etc.


> Wherever you place the template, users can already override it by
> creating one in their project with the same name, in an app that
> appears first in INSTALLED_APPS. There's a documentation page on this
> topic: https://docs.djangoproject.com/en/3.0/howto/overriding-templates/
Not possible. In my case, GDAPS already IS a reusable app (which enables
plugins for Django). So this app is included in INSTALLED_APPS already
in a certain position, and the whole application using this lib could
consist of plenty of plugins (which are Django apps too). GDAPS
dynamically collects them at server start and adds it to INSTALLED_APPS
- but yes, *after* GDAPS. so they can't override any of GDAPS' templates.
>
> Alternatively, you can tell users to install their own URL mapped to
> their own override template. It would only be one line of
> configuration, the same as using include() to include your URLconf.
> And it would allow users to serve your app at multiple URL's or with
> more complicated patterns.

That would be a possibility. But agian, only if the app providing this
urlpattern comes *before* my GDAPS framework in INSTALLED_APPS. which is
not possible except I inject all the plugins before GDAPS into
INSTALLED_APPS.

But that's my own implementation problem and should not be theme on this
list here.


The problem is that GDAPS does not know HOW the project GDAPS is a part
of will be named. And the only way I found a possibility was to make it
dynamic within GDAPS:
https://gitlab.com/nerdocs/gdaps/-/blob/master/gdaps/frontend/urls.py

So I need to know how the project is named.

And as I saw that Django just hardcoded this name when creating a new
project, and questions about how to get the Django project name out of a
project
(https://stackoverflow.com/questions/11179204/how-do-i-find-my-project-name-in-a-django-project)
end up in either taking ROOT_URLCONF[0] (which is bad IMHO, see possible
dynamic nature like https://code.djangoproject.com/ticket/31527).


So I thought that Django providing a project name (which IS the import
path of the main application) would be a good idea.

Anyway, my own project will require a PROJECT_NAME variable, because of
this template overriding problem.

Yours,

Christian

-- 
Dr. Christian González
https://nerdocs.at

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d67cacb5-6c62-8551-b8e9-16e55f644dbf%40nerdocs.at.


pEpkey.asc
Description: application/pgp-keys

Re: Reverting Django 3.1. to Django 3.0.6 raises "binascii.Error: Incorrect padding".

[Adam Johnson]

Hi Uri

Smooth upgrade-ability is hard.

Smooth downgrade-ability is even harder. It also imposes a tax on
development, and can slow the roll out of new features as they can need
roll out over multiple versions.

I agree both would be nice to have, but given the limited engineering
resources for Django, I think it should focus on smooth upgrade-ability.

At least two of the major database servers that Django supports, PostgreSQL
and MySQL, provide zero downgrade-ability. It's too hard for them to do.
They focus on smooth upgrade-ability. Given that these are produced by
bigger teams with vastly more resources, I don't feel confident Django can
come near matching them.

Thanks,

Adam

‪On Fri, 15 May 2020 at 15:03, ‫אורי‬‎  wrote:‬

> Hi,
>
> I submitted this ticket today and it was closed:
> https://code.djangoproject.com/ticket/31592
>
> I think Django should handle downgrading versions without
> raising exceptions. If objects (such as sessions) are invalid because of
> downgrading, they should be deleted automatically. It may happen that a
> user (website owner) downgrades Django and they would expect everything to
> keep working.
>
> And I have a question: Will authenticated users still be authenticated
> after upgrading or downgrading Django to a different version? We use
> persistent cookies for 30 years and I don't want to log out users if they
> don't log out themselves or delete their cookies. I had a problem when
> upgrading to a previous version of Django (2.1) that session cookies
> stopped working in the other website I have (a different domain name), and
> it persisted until I defined *SESSION_COOKIE_SAMESITE = None* in settings
> [https://stackoverflow.com/a/59315164/1412564]. Until then my production
> websites didn't accept logins to the other website.
>
> Thanks,
> Uri.
> אורי
> u...@speedy.net
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABD5YeEvwJGZrA-x8z%3D--jUeXE66%3D6SDvbH6Q0242gKz%2BktLRQ%40mail.gmail.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0eY%3DStGEB6r6NAP%2BcVyE6Q2rp2dcN_s9HCeoLwTcg3uw%40mail.gmail.com.

Re: Signal on management command exception

[Adam Johnson]

Yo-Yo Ma,

Typically I've edited manage.py to handle this use case:

def main():
# ...
try:
execute_from_command_line(sys.argv)
except Exception:
# whatever
raise

This doesn't capture programmatic calls via call_command() . But in my
experience that's rarely used out side of tests, and one can also write an
custom wrapper for call_command().

On Fri, 15 May 2020 at 16:22, François Freitag 
wrote:

> Hi Yo-Yo Ma,
>
> A subset of your use case should be handled by
> https://code.djangoproject.com/ticket/21429 -- BaseCommand should use
> logging instead of custom output wrappers.
>
> I’m actively working on it and hope to have it ready for Django 3.2. It
> allows configuring the reporting of exceptions for built-in management
> commands, but I don’t think it is an appropriate way to execute custom
> code on command error.
>
> Cheers,
> François Freitag
>
> On 5/15/20 5:12 PM, Yo-Yo Ma wrote:
> > Request exceptions have always been easy to manage, because you can use
> > middleware, and there is the built-in signal:
> > https://docs.djangoproject.com/en/3.0/ref/signals/#got-request-exception
> >
> > Problem:
> >
> > However, if you want to send data to e.g., Sentry or perform some other
> > action (logging, etc.) upon any Django management command error, there
> > aren't built-in facilities to deal with this. Even writing your own
> command
> > base class won't suffice, because that won't cover built-in or
> third-party
> > commands.
> >
> > Solution:
> >
> > I propose a "got_command_exception" signal, which would operate
> similarly
> > to "got_request_exception", except that it would pass in the management
> > command class instance as the `sender`, and the provided args/kwargs.
> Being
> > run inside of the exception handler would allow for
> logging.exception(...)
> > and other exc_info needs.
> >
> >
> > Due to the fact that all commands run through the same call_command
> > infrastructure, I think this is a good approach to solving the problem I
> > described.
> >
> > If a majority of folks think this is a good approach, I'll make a patch.
> >
> > Thoughts?
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2020d9ce-e6aa-6a6c-7cfd-851a836a5acc%40gmail.com
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0b-hpZmN89QT1LG_M3YUsC_%2BfeBA67WcOsvSjPcGRhGA%40mail.gmail.com.

Re: Signal on management command exception

[François Freitag]

Hi Yo-Yo Ma,

A subset of your use case should be handled by
https://code.djangoproject.com/ticket/21429 -- BaseCommand should use
logging instead of custom output wrappers.

I’m actively working on it and hope to have it ready for Django 3.2. It
allows configuring the reporting of exceptions for built-in management
commands, but I don’t think it is an appropriate way to execute custom
code on command error.

Cheers,
François Freitag

On 5/15/20 5:12 PM, Yo-Yo Ma wrote:
> Request exceptions have always been easy to manage, because you can use 
> middleware, and there is the built-in signal: 
> https://docs.djangoproject.com/en/3.0/ref/signals/#got-request-exception
> 
> Problem:
> 
> However, if you want to send data to e.g., Sentry or perform some other 
> action (logging, etc.) upon any Django management command error, there 
> aren't built-in facilities to deal with this. Even writing your own command 
> base class won't suffice, because that won't cover built-in or third-party 
> commands.
> 
> Solution:
> 
> I propose a "got_command_exception" signal, which would operate similarly 
> to "got_request_exception", except that it would pass in the management 
> command class instance as the `sender`, and the provided args/kwargs. Being 
> run inside of the exception handler would allow for logging.exception(...) 
> and other exc_info needs.
> 
> 
> Due to the fact that all commands run through the same call_command 
> infrastructure, I think this is a good approach to solving the problem I 
> described.
> 
> If a majority of folks think this is a good approach, I'll make a patch.
> 
> Thoughts?
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2020d9ce-e6aa-6a6c-7cfd-851a836a5acc%40gmail.com.

Signal on management command exception

[Yo-Yo Ma]

Request exceptions have always been easy to manage, because you can use 
middleware, and there is the built-in signal: 
https://docs.djangoproject.com/en/3.0/ref/signals/#got-request-exception

Problem:

However, if you want to send data to e.g., Sentry or perform some other 
action (logging, etc.) upon any Django management command error, there 
aren't built-in facilities to deal with this. Even writing your own command 
base class won't suffice, because that won't cover built-in or third-party 
commands.

Solution:

I propose a "got_command_exception" signal, which would operate similarly 
to "got_request_exception", except that it would pass in the management 
command class instance as the `sender`, and the provided args/kwargs. Being 
run inside of the exception handler would allow for logging.exception(...) 
and other exc_info needs.


Due to the fact that all commands run through the same call_command 
infrastructure, I think this is a good approach to solving the problem I 
described.

If a majority of folks think this is a good approach, I'll make a patch.

Thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f1950d49-c938-41a3-b93d-066ef387a54a%40googlegroups.com.

Ability to change LoginView inside custom AdminSite

[Nikita Krokosh]

Hello everyone.


There's a way to set your own AdminSite class as said in docs:

https://docs.djangoproject.com/en/3.0/ref/contrib/admin/#overriding-the-default-admin-site


But I also want to change login view behavior.

I want to replace *LoginView* in

*django.contrib.admin.sites.AdminSite.login*

method (by analogy with for example *login_form *parameter in the same 
*AdminSite* class).



I need it to write custom logic in *form_valid* method, and it looks 
dirty and unnecessary to copy-paste whole login view code.


Can project code be improved this way?


Best Regards.



--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0a5f010a-df61-a7ce-e62f-281108c8dfd8%40gmail.com.

Re: Proposal: django project name

[magdy maher]

thank you for reply



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, May 13, 2020 at 10:14 PM Christian González <
christian.gonza...@nerdocs.at> wrote:

> Hi all,
>
> I didn't find anything about that in the archive here, so I'd like to come
> to you with an idea which is either very dumb (please tell me) or I don't
> know why anyone hasn't thought about it...
>
> I'm starting a bigger project with a self-created plugin system (GDAPS,
> alrady mentioned). Working nicely, but I came across a few Django
> shortcomings which are sometimes easy to workaround, but could be done
> better: the django project name.
>
> TL;DR: Django has no (builtin/explicit) settings variable like
> PROJECT_NAME. Should have.
>
> Long version:
>
> If you have (like in my case) an application which is more than a single
> django app, and could have various 3rd party additions/plugins, there is no
> common sense of retrieving the overall "name" of the application. If you
> create a project using django-admin startproject myproject - the name
> says it, you name the project. It is written into various places, mostly
> comments etc.:
>
> foo/asgi.py:ASGI config for foo project.
> foo/asgi.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'foo.settings')
> foo/settings.py:Django settings for foo project.
> foo/settings.py:ROOT_URLCONF = 'foo.urls'
> foo/settings.py:WSGI_APPLICATION = 'foo.wsgi.application'
> foo/urls.py:"""foo URL Configuration
> foo/wsgi.py:WSGI config for foo project.
> foo/wsgi.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'foo.settings')
> manage.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE',
> 'foo.settings')
>
> But foo is no variable. Needers of this inofficial project name use
> workarounds like settings.ROOT_URLCONF[0] to get that name. But that's
> always a bit of a whacky feeling when I do it - doesn't seem like - "I'm
> sure this will be supported for the next 20 years".
>
> When it comes to frontends, it's worse. In my case, my GDAPS module
> enables a Vue.js frontend, which needs a index.html which loads Vue. This
> file is (in SPA apps) the only file which is rendered using Django
> templates. No problem, put in gdaps' templates directory and go. Works
> fine, as long as the user of GDAPS is fine with my shipped index.html and
> the corresponding pre-defined url path that renders that index file using
> TemplateView.
>
> If he wants to override that file using his own template (with maybe
> another font loaded etc.) I first thought I just change GDAPS to
> dynamically load the template in GDAPS' urls.py - but therefore it should
> know the name of the project it is a part of.
>
> I can do that using a setting named PROJECT_NAME and place a url
> definition like
>
> path("", 
> TemplateView.as_view(template_name=os.path.join(settings.ROOT_URLCONF[0],"index.html")),
>  name="app")
>
> into urls.py. So the user can place an index.html into foo/templates/foo/ and 
> it should work.
>
> But as said, this seems to me as - hey, ROOT_URLCONF[0] - really, this is the 
> project name?
> path("", 
> TemplateView.as_view(template_name=os.path.join(settings.PROJECT_NAME,"index.html")),
>  name="app")
>
> seems better to me.
> I first thought that Django could provide that as "builtin" setting, but 
> OTOH, explicit is better than implicit,
> so why not
> a) create a setting (which is created by django-admin createproject along 
> with the other parsed templates) named
> PROJECT_NAME o DJANGO_PROJECT_NAME
> or
> b) (because settings are not used in wsgi.py, manage.py etc.) create it 
> earlier in the process - or does it have to be written at more than one 
> places?
> This would violate DRY.
>
> Please tell me what you think about that.
>
> Yours,
> Christian
>
> --
> Dr. Christian Gonzálezhttps://nerdocs.at
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/37527e26-4e21-2684-5766-145441c6ae50%40nerdocs.at
> 
> .
>


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe 

Reverting Django 3.1. to Django 3.0.6 raises "binascii.Error: Incorrect padding".

[אורי]

Hi,

I submitted this ticket today and it was closed:
https://code.djangoproject.com/ticket/31592

I think Django should handle downgrading versions without
raising exceptions. If objects (such as sessions) are invalid because of
downgrading, they should be deleted automatically. It may happen that a
user (website owner) downgrades Django and they would expect everything to
keep working.

And I have a question: Will authenticated users still be authenticated
after upgrading or downgrading Django to a different version? We use
persistent cookies for 30 years and I don't want to log out users if they
don't log out themselves or delete their cookies. I had a problem when
upgrading to a previous version of Django (2.1) that session cookies
stopped working in the other website I have (a different domain name), and
it persisted until I defined *SESSION_COOKIE_SAMESITE = None* in settings [
https://stackoverflow.com/a/59315164/1412564]. Until then my production
websites didn't accept logins to the other website.

Thanks,
Uri.
אורי
u...@speedy.net

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeEvwJGZrA-x8z%3D--jUeXE66%3D6SDvbH6Q0242gKz%2BktLRQ%40mail.gmail.com.

Re: Django Version 3.2 Roadmap

[Carlton Gibson]

OK, thanks thus far all. I've bumped the final release date to April 6 
2021. 

(I left the other dates as were: a handful of extra days over the weekend 
there will be a nice to have when they arrive :)

C.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6466cc57-ffe1-44ee-afb6-161e38154226%40googlegroups.com.