Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

[Jamesie Pic]

On Mon, Feb 25, 2019 at 10:39 PM Jamesie Pic  wrote:
> component = dict(
> template_name='django/forms/widgets/textarea.html',
> script='your/textarea.js',
> style='your/style.css'
> )

Actually do NOT try this, for static i think the more efficient
refactor would be to enable widgets and things to touch
request.static.scripts and request.static.styles, so that scripts that
you load in your parent template would not be re-added by the widgets.
At the same time, programing perimeter for widget statics would
increase since this would no more reduce it to a declarative
structure.

And maybe you want to try to change from templates to python rendering
functions, if not for transpiling or performance, performance, maybe
just for easier reuse across python code in general. But then you
would use a python library that

FTR GDAPS is also having research on this as we speak :
https://gitlab.com/nerdocs/gdaps/issues/2

Have fun

-- 
∞

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18G0897i333BgRmcOur5bGGceuAy7ak6XN%3DZ2rmOuW7MQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.2 and the watchman reloader

[Tom Forbes]

I have a small PR here to remove the “watchman unavailable” message, whilst
keeping the one that specifies which reloader we are using:
https://github.com/django/django/pull/11025.




On 21 February 2019 at 20:52:29, Claude Paroz (cla...@2xlibre.net) wrote:

Le jeudi 21 février 2019 21:43:43 UTC+1, Tom Forbes a écrit :
>
> Hey Claude,
> Thanks for your feedback on the feature, I fully agree with you. I think
> we should remove that warning message about the missing package. I will
> make a PR to do that.
>

I'm not completely sure it's a good idea to entirely remove the message.
Maybe just telling the used reloader would be fine.


> Regarding creating another reloader: it should not be that difficult to do
> at all since we have all the other pieces in place. In theory it's just
> implementing a class with single generator method.
>
> If people agree I would like to use the 'watchdog' package for this rather
> than the pyinotify library as it would be quicker to implement, a lot nicer
> to work with and is easier to test.
>

++1, watchdog is better maintained, looks like pyinotify is dead. Tell me
if you need help, even if you seems a lot more knowledgeable than me on the
subject.

Thanks.

Claude


> On Thu, 21 Feb 2019, 19:56 Claude Paroz,  wrote:
>
>> Le jeudi 21 février 2019 19:48:31 UTC+1, Dan Davis a écrit :
>>>
>>> Claude,
>>>
>>> I've tested a Django based application on 2.2b1 without watchman on
>>> Windows, it does tell you about watchman, but it doesn't fail to run.
>>> Apparently, it falls back to the old way of reloading.   Is this not the
>>> behavior on Debian/Ubuntu?
>>>
>>
>> Yes it is. I would say this is still a slight regression in two ways:
>>
>> - no messages told you the reload method was not optimal before. So now
>> people will try to "fix" their system, more than before.
>> - for Debian-based systems, you could improve the reloading performance
>> by installing system or pip packages in 30 seconds. Now you have to spend
>> 30 minutes to search how watchman can be installed and to compile the
>> package (+ you have to care yourself for any security issue).
>>
>> Claude
>> --
>> 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-develop...@googlegroups.com.
>> To post to this group, send email to django-d...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-developers/b059553a-e25e-4d90-beed-
>> bf7e0f797305%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/6de70f64-9bbb-4017-bd10-c85e94ae08d0%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFNZOJOOELOoSEGGx9LrMryrYFhqm%2Bzd_PPZ-ztarjiZyR%2Bvnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

[Jamesie Pic]

Also in Django maybe try to change things like:

class Textarea(Widget):
template_name = 'django/forms/widgets/textarea.html'

With

component = dict(
template_name='django/forms/widgets/textarea.html',
script='your/textarea.js',
style='your/style.css'
)

Or something component='your.favorite.TextArea', then you could also hack
django.forms.widgets.component to change the default rendering at the
project level. Maybe then distribute more exciting component objects that
accepts this dict interface in pip packages that could work with any python
framework.

Anyway, keep on pursuing your dream stack, always happy to read some
exciting discussions on this matter ;)

Have a great day

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op191PpSz_EZT8H-zSz5cgePAD-j%3DBHQQfCvT0KTgVyJQrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Test database, --keepdb parameter, and migrations

[Dan Davis]

There are a cluster of issues that I find difficult to resolve as a user, 
and as a Django developer, I think there is potential to make them easier 
through features in Django itself. I'm interested in hearing better 
work-arounds than I use now, but I'm more interested in helping clarify how 
the product, e.g. Django, can get better at supporting these scenarios 
"out-of-the-box".  What I am hoping for is a conversation, not a simple bug 
report.

"out-of-the-box" Django supports a --keepdb argument.  In many of my 
environments, I'd like to make this the default in my environment, but I 
see no *Good* way to do that unless I wrap the test management command, and 
change the default of the keepdb parameter.Many developers use 
django-nose or pytest-django to gain additional capabilities, but REUSE_DB=1 
for django-nose and --reuse-db for pytest work differently than --keepdb.  
 I just filed https://github.com/pytest-dev/pytest-django/issues/704 on 
pytest-django about that.

It would be nice if "out-of-the-box" Django supported some way to make "
keepdb" the default. and some way to override it if it were the default.  
 Another way to do that would be to make the "CREATEDB" argument of Oracle 
more general and to support it on other databases.

Another work-around for me would be to overwrite the "migrate" management 
command to add a "--testdb" option so that it could run migrations on the 
test database explicitly, or to write my own "testmigrate" management 
command.

Suppose my database settings include this:

'external': {
'ENGINE': 'django.db.backends.oracle',
'NAME': 'EXTERNAL',
'USER': external_username,
'PASSWORD': external_password,
'TEST': {
'CREATE_DB': False,
'CREATE_USER': False,
'NAME': 'EXTERNAL',
'USER': external_username,
'PASSWORD': external_password,
 }
 }

This is almost like the below:

'external': {
'ENGINE': 'django.db.backends.oracle',
'NAME': 'EXTERNAL',
'USER': external_username,
'PASSWORD': external_password,
'TEST': {
'MIRROR': 'external',
 }
 }

The user of these sort of capability needs to understand database routers, 
or meta options that are similar.   But that may not be enough - entering 
"./manage.py migrate --database external" would try to migrate the 
database, but running tests will always attempt to migrate the database.  
Perhaps we need better documentation for "MIRROR",  because it is clearly 
intended for situations where there are read/write database aliases and 
read replica databases, not for read-only external databases that are used 
during tests.

I've fixed this by monkey patching the database creation in a test runner, 
very similarly to how pytest-django and django-nose do, but that has a code 
smell that suggests that Django "out of the box" should have some 
capabilities, maybe in the database router, that prevent migrations for 
even the DJANGO_MIGRATIONS table.

Another thing that could be done is to provide a cleardb management 
command  that supports a "--testdb" option, and removes all the 
definitions, including DDL, for users unable to drop and recreate their 
database.  This also supports user who have been running with --syncdb, and 
now they wish to make migrations, or they've made a bunch of migrations and 
they wish to start fresh and clean things up.  How to clean up on a 
per-backend basis is a bit complicated, and a place where Django doesn't 
hide the RDBMS sufficiently and users end-up working through tools such as 
Toad or SQL Developer to clean things up.

Thoughts?   Has this come up before?





-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f39c92c1-512a-4e7b-83d1-ae688adabc81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Florian Apolloner]

Hi Tobias,

I think a cache of something like a day will most certainly not hurt 
anyone. If the need arises we can still manually purge the cache as needed.

Cheers,
Florian

On Sunday, February 24, 2019 at 1:00:50 AM UTC+1, Tobias McNulty wrote:
>
> Hi all,
>
> An implementation question has come up regarding cache lifetime (see this 
> PR ). Right now, 
> the whole site (including docs) has the site-wide Django cache enabled 
> ,
>  
> with a timeout of 5 minutes 
> .
>  
> A couple docs views (search_suggestions 
> 
>  
> and search_description 
> )
>  
> views have longer timeouts set (to 1 hour and 1 week, respectively).
>
> Once released, the vast majority of Django docs won't change much, except 
> for the release notes section and any (likely minor) related updates to the 
> docs themselves. To get the most benefit out of a CDN, it would obviously 
> be desirable to set the timeout to something greater than 5 minutes.
>
> At the same time, there are moments when a quick update to the docs *is* 
> desired, and waiting an hour or more for any cached pages to expire may 
> cause significant confusion, for example, in conjunction with a security 
> release for which stubbed (non-final) release notes may have already been 
> pushed out and cached.
>
> I see two main options at this point (which could even be combined):
>
> 1) Invalidate the whole cache (or at least some key release notes URLs) 
> any time there's a docs build that has changes. It would be pretty easy to 
> piggyback off of the existing business logic for avoiding a rebuild 
> 
>  
> if the git checkout hasn't changed (in the update_docs management command).
> 2) Pick subsections of the docs (e.g., for anything matching 
> '///releases/*' and perhaps the development docs) that would 
> keep a shorter cache timeout of 5-10 minutes. All URLs not specifically 
> requiring this special treatment would get a longer timeout, perhaps 
> somewhere between 1 and 24 hours.
>
> So, some questions for the list:
>
> * Are there sections of the docs besides '///releases/' and 
> '//dev/' that might update frequently and merit some combination of 
> invalidation and/or a shorter cache time? And what's a good cache timeout 
> for such pages?
> * How long are we comfortable waiting for *other* (not frequently 
> updated) pages to timeout, in the event they do change?
>
> Tobias
>
> On Fri, Feb 15, 2019 at 7:13 AM Tobias McNulty  > wrote:
>
>> Thanks for sharing the results.
>>
>> I did manage to get a domain set up with working SSL, in case you want to 
>> use it: https://django-docs.global.ssl.fastly.net/en/2.1/
>>
>> Tobias
>>
>> On Thu, Feb 14, 2019, 11:49 PM Cheng C >  wrote:
>>
>>> Thanks for the test site, Tobias. 
>>>
>>> Tested from Melbourne, Australia: 
>>>
>>> https://docs.djangoproject.com/en/2.1/
>>> Average Ping: 268ms
>>>  Browser: 22 requests, 238KB transferred, Finish: 2.72s, 
>>> DOMContentLoaded: 1.37s, Load: 1.68s
>>>
>>> https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/
>>> Average Ping: 28ms
>>>  Browser: 22 requests, 240KB transferred, Finish: 947ms, 
>>> DOMContentLoaded: 627ms, Load: 910ms
>>>
>>> Tested on Chrome with "Disable cache" checked, and no render issue was 
>>> found.
>>>
>>> On Friday, February 15, 2019 at 2:09:09 PM UTC+11, Tobias McNulty wrote:

 Adam, is there another provider you would recommend instead, that does 
 not require changing DNS providers? FWIW, python.org does in fact use 
 Fastly:

 $ host www.python.org
 www.python.org is an alias for dualstack.python.map.fastly.net.
 dualstack.python.map.fastly.net has address 151.101.248.223
 dualstack.python.map.fastly.net has IPv6 address 2a04:4e42:2f::223

 Fastly did write back to say they're happy to help, though there's a 
 contract which I guess the DSF would need to review and sign, if it's 
 acceptable.

 In the meantime, feel free to give this a try and let me know if you 
 see any issues: 
 https://docs.djangoproject.com.global.prod.fastly.net/en/2.1/ (Not for 
 permanent use, obviously; you'll get a cert warning, and some pages will 
 redirect you back to https://docs.djangoproject.com.)

 To keep this thread from getting too noisy, you can find me (tobias1) 
 in #django-dev on FreeNode.

 Cheers,
 Tobias

 On Thu, Feb 14, 2019 at 8:26 AM Adam Johnson  wrote:

> I have not had great experience with Fastly in the past and 

Re: Password reset emails in combination with click tracking do not work with Intelligent Tracking Prevention on Safari for iOS 12 and macOS Mojave

[Florian Apolloner]

Hi Collin,

it is not (just) about links, it is mainly about stylesheets/js. But we can 
set a header on that view: 
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy 
This should work for every browser != IE/Edge.

Cheers,
Florian

On Friday, February 22, 2019 at 9:35:53 PM UTC+1, Collin Anderson wrote:
>
> I wouldn't mind just rolling back the security fix (or maybe making a 
> straightforward way to enable/disable the behavior). We could instead 
> encourage people to use  on any links (from the 
> password rest page) to untrusted urls.
>
> On Friday, February 22, 2019 at 5:03:01 AM UTC-5, Henrik Ossipoff Hansen 
> wrote:
>>
>> Just wanted to chime in and say we also experienced this issue. We ended 
>> up having to revert the security fix that was added to the view in Django 
>> just to avoid the flood of customers reporting they couldn't reset their 
>> passwords on our apps anymore - so I'm assuming this affects a lot of users 
>> out there.
>>
>> torsdag den 21. februar 2019 kl. 14.48.45 UTC+1 skrev Mat Gadd:
>>>
>>> You can see this in action yourself using Chrome's Dev Tools. Open Dev 
>>> Tools, then their Settings, and turn on "Auto-open DevTools for popups". 
>>> Then, click any link in the Gmail web app. You'll see you go via 
>>> google.com/url?q=original_url_here. Since they're doing this with 
>>> JavaScript, the links look like they're going to open the real URL, but 
>>> they *don't.*
>>>
>>> On Thu, 21 Feb 2019 at 10:44, Mat Gadd  wrote:
>>>
 Exactly that, yes. We've disabled all click tracking that we can, but 
 Gmail has its own redirect which causes Safari's privacy features to kick 
 in. (Some?) Gmail users are unable to use the password reset emails.

 On Thursday, 21 February 2019 01:03:54 UTC, Philip James wrote:
>
> Mat, are you saying you're seeing Safari still blocking, even with 
> click tracking turned off, because GMail itself is inserting a redirect?
>
> PJJ
> http://philipjohnjames.com
>
>
> On Wed, Feb 20, 2019 at 4:46 AM Mat Gadd  wrote:
>
>> We're also now seeing Gmail users complain that the password reset 
>> links don't work, even after we disabled click tracking. It seems that 
>> Google are inserting their own click tracking into users' emails, which 
>> is… 
>> weird?
>>
>> The markup of links is transformed to the following (where … is our 
>> original URL):
>>
>> https://www.google.com/url?q=…;>Link text here
>>
>> Gmail is a *huge* provider of emails, and they make up around 54% of 
>> our user base. Anyone using the Gmail web app can no longer reset their 
>> password simply by clicking the link in the email. 
>>
>> On Wednesday, 23 January 2019 12:51:22 UTC, Perry Roper wrote:
>>>
>>> It would appear that this affects a large number of users. We're 
>>> also experiencing this in the following configurations.
>>>
>>> - Mailgun click tracking enabled + Safari 12.0 on MacOS or any 
>>> browser in iOS 12
>>> - Clicking the link in the Gmail app or web app (Mailgun click 
>>> tracking disabled) + Safari 12.0 on MacOS or any browser in iOS 12.
>>>
>>> All iOS 12 browsers and MacOS Safari users using the Gmail app, or 
>>> in any email client if the site they are requesting a password from 
>>> uses 
>>> link tracking.
>>>
>>> On Thursday, 22 November 2018 20:43:15 UTC+7, Mat Gadd wrote:

 Hi all,

 I raised a ticket  
 regarding this and was directed here to discuss the topic. The summary 
 is 
 that the combination of using click-tracking redirects (which are 
 popular 
 with a variety of email providers) with the Django contrib.auth 
 password 
 reset views does not work in Safari on macOS and iOS as of the latest 
 major 
 versions.

 It took me quite a long time to work out what was happening, so I 
 wanted to at least raise a ticket where other people might find it, 
 but was 
 also hoping to start a discussion around how else the problem could be 
 mitigated. An option to disable the internal token redirect might be 
 useful, but that then re-opens the token up to being leaked via the 
 HTTP_REFERER header.

 Regards,
  - Mat

>>> -- 
>> 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-develop...@googlegroups.com.
>> To post to this group, send email to django-d...@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers
>> .
>> To view this discussion on the web 

Re: Signals - Need a signal after annotations are added

[samarth parashari]

django signal are work like database trigger.

On Sun, Feb 24, 2019 at 12:35 PM Mike Brown  wrote:

>  I think this is a request for a signal that fires after those attributes
>> have been added to the model instances.
>>
>
> Yes.
>
>
> On Saturday, February 23, 2019 at 12:08:43 PM UTC-8, Mike Brown wrote:
>>
>> I have a situation where I need a signal for when a model object is fully
>> instantiated.
>>
>> Currently, there are signals for pre_init and post_init. However, when
>> post_init is fired,
>> the object is not fully 'initialized' in the sense that annotations have
>> not yet been added to the object.
>>
>>
>> In django.db.models.query there is class ModelIterable(BaseIterable)
>>
>> In this class there is code to run a query and then apply annotations.
>>
>> Should there be a new signal added to Django that is fired after the
>> annotations are complete and the object is fully instantiated?
>>
>> Maybe a signal called 'instantiation_complete'?
>>
>>
>> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/8081596b-26c8-4380-b292-2ba1e77ae61a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGQzZJV-vvChvDy8n60qgkSc-J-a56AJABC8anpSXZ2QM7q%2BVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.