Re: Weird date math bug?

Also, if you are developing this application for use within the USA, be sure that you are not capturing or storing data that would fall under the HIPAA definition of personal medical data. If it does, your legal compliance responsibilities and liabilities will skyrocket.

I'm not a lawyer, so I can't say for sure whether or not these data fields would be considered under HIPAA, but a compromise of medical data is extremely expensive, and I believe you can be held personally liable in some cases, even if developing for an employer.

https://www.hhs.gov/hipaa/for-professionals/index.html

If not in the US, there may be other regulations.

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciViwO0%2BkQh2sxRvapTxR8S-0P24s0CNFibNjT85pzKugg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird date math bug?

A few tips on your code:

def get_latest_chemo(self):
chemo = ChemoRegime.objects.filter(patient=self).latest('stop_date')

class ChemoRegime(models.Model):
patient = models.ForeignKey(Patient, on_delete=models.CASCADE)

Use the related manager here. To make it readable, use:

class ChemoRegime(models.Model):
patient = models.ForeignKey(Patient, on_delete=models.CASCADE,
related_name='chemo_regimes')

class Patient(models.Model):
def get_latest_chemo(self):
return self.chemo_regimes.latest('stop_date')

When providing properties for use in templates, make them properties -
makes the template more readable:

@property
def latest_chemo(self):
return self.chemo_regimes.latest('stop_date')

{{ patient.latest_chemo }}

Similarly you can abstract active regimes:

class ChemoRegime(models.Model):
@property
def is_active(self):
return self.stop_date is None

{% if chemo.is_active %}<span class="badge
badge-primary">Current</span>{% endif %}


Of course, latest_chemo, should really be this if
active and non-active regimes can be mixed:

@property
def has_active_chemo(self):
return self.chemo_regimes.filter(stop_date__isnull=True).count() > 0

@property
def latest_chemo(self):
if not self.chemo_regimes.count():
return None
if self.has_active_chemo:
return self.chemo_regimes.latest('start_date')
return self.chemo_regimes.latest('stop_date')

Hope this helps :)

On Fri, Sep 1, 2017 at 7:22 AM, Lachlan Musicman <datakid@gmail.com> wrote:
> On 1 September 2017 at 14:57, James Schneider <jrschneider83@gmail.com>
> wrote:
>>
>> I'm guessing that ChemoRegime.regime_age() contains line 95.
>>
>> ChemoRegime defines the stop_date field with null=True and blank=True. I'm
>> guessing this is because patients may not have yet stopped treatment, so
>> they have no stop_date.
>>
>> With that in mind, self.stop_date may be None in Python (and Null in the
>> DB). Subtracting None from a real datetime.date object is not supported.
>>
>> Ensure that stop_date has a date value before doing date math with it.
>>
>> -James
>>
>
> I am so embarrassed. Thank you James, spot on.
>
> cheers
> L.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscribe@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAGBeqiM-kY1br4bzb5yWVEOCnXhcYd3ZoV8bUey1nJoS1iNWuQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
Melvyn Sopacua

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Bgw1GUaMHkuwG9YU-G_7fLo3vWt-5xd7BW_%3DwwOYL_qeUGJiA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird date math bug?

I am so embarrassed. Thank you James, spot on.

cheers

L.

No worries. I've stuck my foot in my mouth more than once on this list.

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciW3mzcCq%3DhQPOHL%2B6f3nOKU%3D%2B8vKjiAXDe8Sq1HW2QCzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird date math bug?

On 1 September 2017 at 14:57, James Schneider <jrschneider83@gmail.com> wrote:

I'm guessing that ChemoRegime.regime_age() contains line 95.

ChemoRegime defines the stop_date field with null=True and blank=True. I'm guessing this is because patients may not have yet stopped treatment, so they have no stop_date.

With that in mind, self.stop_date may be None in Python (and Null in the DB). Subtracting None from a real datetime.date object is not supported.

Ensure that stop_date has a date value before doing date math with it.

-James

I am so embarrassed. Thank you James, spot on.

cheers

L.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAGBeqiM-kY1br4bzb5yWVEOCnXhcYd3ZoV8bUey1nJoS1iNWuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird date math bug?

On Aug 31, 2017 9:44 PM, "Lachlan Musicman" <datakid@gmail.com> wrote:

Sorry, let me start again:

Yay, I'm not the only one that does it! Lol...

<snip>

class ChemoRegime(models.Model):
    patient = models.ForeignKey(Patient, on_delete=models.CASCADE)
    chemotype = models.ForeignKey(ChemoType, on_delete=models.CASCADE)
    start_date = models.DateField(null=True, blank=True)
    stop_date = models.DateField(null=True, blank=True)

    def regime_age(self):
        age = timezone.now().date() - self.stop_date
        return age.days

<snip>

But in the browser:

Exception Type:     TypeError
Exception Value:    

unsupported operand type(s) for -: 'datetime.date' and 'NoneType'

Exception Location:     ./patients/models.py in regime_age, line 95

line 95 is         age = timezone.now().date() - self.stop_date

What am I doing wrong?

cheers

L.

I'm guessing that ChemoRegime.regime_age() contains line 95.

ChemoRegime defines the stop_date field with null=True and blank=True. I'm guessing this is because patients may not have yet stopped treatment, so they have no stop_date.

With that in mind, self.stop_date may be None in Python (and Null in the DB). Subtracting None from a real datetime.date object is not supported.

Ensure that stop_date has a date value before doing date math with it.

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXMOY5Mx5C91e0sXasXKa-f5mCga%2BDtf29AtQDaL1sqUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Weird date math bug?

Sorry, let me start again:


Is there a weird date math bug in Django 1.11.4? I say weird because surely not?

I can't see any tickets in the tracker, but I'm definitely seeing it in production.

Using postgresql:


models.py

class ChemoType(models.Model):
    name = models.CharField(max_length=50, unique=True)

class Patient(models.Model):
    chemo_regimes = models.ManyToManyField(
        ChemoType,
        through='ChemoRegime',
    )  
    def get_latest_chemo(self):
        chemo = ChemoRegime.objects.filter(patient=self).latest('stop_date')
        return chemo

    def get_latest_chemo_age(self):
        chemo = ChemoRegime.objects.filter(patient=self).latest('stop_date')
        return chemo.regime_age()

class ChemoRegime(models.Model):
    patient = models.ForeignKey(Patient, on_delete=models.CASCADE)
    chemotype = models.ForeignKey(ChemoType, on_delete=models.CASCADE)
    start_date = models.DateField(null=True, blank=True)
    stop_date = models.DateField(null=True, blank=True)

    def regime_age(self):
        age = timezone.now().date() - self.stop_date
        return age.days




In django_extension's shell plus:

>>> p = Patient.objects.get(id=1)
>>> p.get_latest_chemo()
<ChemoRegime: Gemcitabine>
>>> p.get_latest_chemo_age()
12
>>> p.get_latest_chemo_age
<bound method Patient.get_latest_chemo_age of <Patient: test-1>>
>>> type(p.get_latest_chemo_age())
<class 'int'>




In the template

          {% for patient in object_list %}
            <tr>
                   <td><a href="{{ patient.get_absolute_url }}">{{ patient }}</a></td>
                   <td>{{ patient.get_latest_chemo_age }} ago</td>
            </tr>




But in the browser:

Exception Type:     TypeError
Exception Value:    

unsupported operand type(s) for -: 'datetime.date' and 'NoneType'

Exception Location:     ./patients/models.py in regime_age, line 95

line 95 is         age = timezone.now().date() - self.stop_date

What am I doing wrong?

cheers

L.

------
"The antidote to apocalypticism is apocalyptic civics. Apocalyptic civics is the insistence that we cannot ignore the truth, nor should we panic about it. It is a shared consciousness that our institutions have failed and our ecosystem is collapsing, yet we are still here — and we are creative agents who can shape our destinies. Apocalyptic civics is the conviction that the only way out is through, and the only way through is together. "

Greg Bloom @greggish https://twitter.com/greggish/status/873177525903609857

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAGBeqiMoZXiwUhL-gL1uPzOw%3DC4JfoDZnfOFs6Qys4HU7RZV%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Weird date math bug?

Is there a weird date math bug in Django 1.11.4? I say weird because surely not?

I can't see any tickets in the tracker, but I'm definitely seeing it in production.

Using postgresql:

class Patient(models.Model):

------
"The antidote to apocalypticism is apocalyptic civics. Apocalyptic civics is the insistence that we cannot ignore the truth, nor should we panic about it. It is a shared consciousness that our institutions have failed and our ecosystem is collapsing, yet we are still here — and we are creative agents who can shape our destinies. Apocalyptic civics is the conviction that the only way out is through, and the only way through is together. "

Greg Bloom @greggish https://twitter.com/greggish/status/873177525903609857

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAGBeqiMPy_7DU-DVrZYypp9aDAqRJS4dDbAt-33cy0MeUYLjFg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A lot of Problems with Migrating (conceptual)

Thanks Melvyn, good to know. I'll keep that in mind

On Thursday, August 31, 2017 at 9:19:57 AM UTC-6, Melvyn Sopacua wrote:

There are two main principles to remember about Django migrations in early development stage:

1) Make migrations often and coherent.

   Typically, if you change something about a model, make a migration.

   When you want to cover multiple models in one migration, there should be

   a good reason for it. If you can't think of it, don't.

2) When the design is flawed, don't add to the problem by creating another

   migration. Instead roll back, remove the migration file(s), alter the

   design and make a new migration.

The second principle is often overlooked and by applying the first, the

"damage" is minimized.

Rolling back is done by adding a migration number to the `migrate` management

command and it will roll back to the point including that migration.

Once you freeze the model design, feel free to squash some or all migrations

into one file if things got a little big.

On Wed, Aug 30, 2017 at 12:16 AM, Alexander Joseph <alexander...@gmail.com> wrote:

Thanks James,

I'm actually starting over from scratch instead of actually refactoring so the accounts app is the only real app I have so far. I actually did delete the database and just apply migrations to the newly created database and it worked ok. I'd like to get better at fixing these migration problems though since I'll probably run into a lot of them and wont be able to delete the database once I have data.

Do you think it would have been better to run migrations for the specific accounts app? I thought it wouldnt matter much since accounts is my only app I have so far.

My new structure so far looks like this

business_management/

    business_management/

        accounts/

            migrations/

            __init__.py

            admin.py

            forms.py

            models.py

            tests.py

            views.py

        static/

        templates/

    config/

        settings/

            __init__.py

            base.py

            local.py

            production.py

        __init__.py

    docs/

        (developer documentation)

    requirements/

        (requirements.txt files)

    utility/

        (shell scripts)

    manage.py

    .gitignore

On Tuesday, August 29, 2017 at 3:35:21 PM UTC-6, James Schneider wrote:

On Tue, Aug 29, 2017 at 7:13 AM, Alexander Joseph <alexander...@gmail.com> wrote:

I'm not specifying the app level, I'm just running "python manage.py makemigrations --settings=config.settings.local"  and  "python manage.py migrate --settings=config.settings.local"

I'm not modifying the migrations files and I dont have an app with the label of admin, thats just the built-in admin. Thanks

I know you were doing a lot of refactoring. Did you rename the accounts app after performing an initial migration (applying an old migration with the old app name structure)? It sounds like your DB and your migration files might be out of sync. If you don't have any production data, I would recommend deleting and recreating the entire database, and deleting and recreating your migrations so that all the migrations are run in the correct order.

If you do have data you want to keep, then very likely you now have a ton of work to do writing custom migrations to sync everything back up manually. 

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/0686084f-1d5a-4f61-823e-7d84c58f317c%40googlegroups.com.

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

--

Melvyn Sopacua

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7b2eba67-bb19-4ba0-9d3d-7277da32f8be%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django-channels get the json post on connect

I have this in routing.py for django-channels

channel_routing = [

   # Wire up websocket channels to our consumers:

   route("websocket.connect", ws_connect),

   route("websocket.receive", ws_message),

]

and the ws_connect looks like this

@channel_session

def ws_connect(message, key):

    # Accept connection

    message.reply_channel.send({"accept": True})

and when the page loads this socket connection is made correctly

<script type="text/javascript">

// Note that the path doesn't matter for routing; any WebSocket

// connection gets bumped over to WebSocket consumers

socket = new WebSocket("ws://" + window.location.host + "/chat/");

socket.onmessage = function(response) {

   console.log(response.data);

}

socket.onopen = function() {

   socket.send({"test":"data"});

}

// Call onopen directly if socket is already open

if (socket.readyState == WebSocket.OPEN) socket.onopen();

</script>

I want to start testing if I can have a background process running from this, so I set a test json input to socket.send however I haven't found anything on the documentation, apologies if I missed it. How to access this info in ws_connect it should be in message same way there's request I believe.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/375ec390-a4fb-4112-a378-3a1d1a56eb6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is some problem in field options 'null'?

The document says to avoid null=True for character fields,

because they both "mean the same thing": there is nothing

in there.

They are however different and this is why Django returns

None:

- Empty character fields are considered a value

- NULL character fields are not

This is important in unique constraints:

Two rows with empty string are forbidden

Two (or more) rows set to NULL are allowed.

On Sat, Aug 26, 2017 at 2:09 PM, Jinwen <toonowujinwen@gmail.com> wrote:

I read the document about field options 'null'.

It is said that.

If True, Django will store empty values as NULL in the database. Default is False.

Avoid using null on string-based fields such as CharField and TextField. If a string-based field has null=True, that means it has two possible values for "no data": NULL, and the empty string.

Then I try make a field have "null=True", just save it to database.

like that.

>>> from backend.models import Scrapyd as S

>>> s = S()

>>> s.comment

>>> type(s.comment)

<class 'NoneType'>

>>> s.save()

>>> b  = S.objects.all().last()

>>> b

<Scrapyd: Scrapyd object>

>>> b.comment

>>> type(b.comment)

<class 'NoneType'>

What my question is why the value not like the document said is empty string ''?

I am confused.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1b239340-78d6-4df2-a12d-9531dfe7912d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Melvyn Sopacua

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Bgw1GWiq7jR4ptTLp%2Bj%3DLDboXcKvCuNXL_g8vp6YioqmJuOjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: trying to create allauth SignupForm subclass for customization....

The answer lies in the fact that you are getting a Django configuration exception and not an ImportError.

The solution: https://github.com/pennersr/django-allauth/issues/826

The reason: https://github.com/pennersr/django-allauth/blob/master/allauth/account/forms.py#L197

So, there is an import loop / inheritance problem: Allauth's SignupForm makes itself a child of your custom form and you're trying to become it's child.

On Tue, Aug 29, 2017 at 5:13 AM, Alexander Joseph <alexander.v.joseph@gmail.com> wrote:

Hello, I'm trying to add some additional fields to the allauth signup form (first_name and last_name). I'm thinking the best way to do this is to create a allauth SignupForm subclass and add my own fields (very new to django so please let me know if I'm going about this wrong)

I added

ACCOUNT_SIGNUP_FORM_CLASS = 'accounts.forms.UserCreateForm'

to my base settings file

and here is my accounts.forms.py...

from django.contrib.auth import get_user_model

from allauth.account.forms import SignupForm

from django import forms

class UserCreateForm(SignupForm):

    class Meta:

        fields = ("first_name", "last_name", "email", "username", "password1", "password2")

        model = get_user_model()

        

    def __init__(self, *args, **kwargs):

        super().__init__(*args, **kwargs)

        self.fields["first_name"].label = ''

        self.fields["first_name"].widget.attrs["placeholder"] = "First Name"

        self.fields["last_name"].label = ''

        self.fields["last_name"].widget.attrs["placeholder"] = "Last Name"

        self.fields["email"].label = ''

        self.fields["email"].widget.attrs["placeholder"] = "Email"

        self.fields["username"].label = ''

        self.fields["username"].widget.attrs["placeholder"] = "Username"

        self.fields["password1"].label = ''

        self.fields["password1"].widget.attrs["placeholder"] = "Password"

        self.fields["password2"].label = ''

        self.fields["password2"].widget.attrs["placeholder"] = "Confirm Password"

for some reason I keep getting the error ...

django.core.exceptions.ImproperlyConfigured: Error importing form class accounts.forms: "cannot import name 'SignupForm'"

Not sure why. Obviously there is a SignupForm in allauth.account.forms.py, seen here... 

https://github.com/pennersr/django-allauth/blob/master/allauth/account/forms.py

I dont know what I'm doing wrong. Any help you can give is much appreciated

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ea79940e-0549-4ffa-802f-e72214d4ebe2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Melvyn Sopacua

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Bgw1GXd5rekiPZO-c%3DzPK0yyw_L2XKTKv82n6uzrtgKTKK68g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: A lot of Problems with Migrating (conceptual)

There are two main principles to remember about Django migrations in early development stage:

1) Make migrations often and coherent.

   Typically, if you change something about a model, make a migration.

   When you want to cover multiple models in one migration, there should be

   a good reason for it. If you can't think of it, don't.

2) When the design is flawed, don't add to the problem by creating another

   migration. Instead roll back, remove the migration file(s), alter the

   design and make a new migration.

The second principle is often overlooked and by applying the first, the

"damage" is minimized.

Rolling back is done by adding a migration number to the `migrate` management

command and it will roll back to the point including that migration.

Once you freeze the model design, feel free to squash some or all migrations

into one file if things got a little big.

On Wed, Aug 30, 2017 at 12:16 AM, Alexander Joseph <alexander.v.joseph@gmail.com> wrote:

Thanks James,

I'm actually starting over from scratch instead of actually refactoring so the accounts app is the only real app I have so far. I actually did delete the database and just apply migrations to the newly created database and it worked ok. I'd like to get better at fixing these migration problems though since I'll probably run into a lot of them and wont be able to delete the database once I have data.

Do you think it would have been better to run migrations for the specific accounts app? I thought it wouldnt matter much since accounts is my only app I have so far.

My new structure so far looks like this

business_management/

    business_management/

        accounts/

            migrations/

            __init__.py

            admin.py

            forms.py

            models.py

            tests.py

            views.py

        static/

        templates/

    config/

        settings/

            __init__.py

            base.py

            local.py

            production.py

        __init__.py

    docs/

        (developer documentation)

    requirements/

        (requirements.txt files)

    utility/

        (shell scripts)

    manage.py

    .gitignore

On Tuesday, August 29, 2017 at 3:35:21 PM UTC-6, James Schneider wrote:

On Tue, Aug 29, 2017 at 7:13 AM, Alexander Joseph <alexander...@gmail.com> wrote:

I'm not specifying the app level, I'm just running "python manage.py makemigrations --settings=config.settings.local"  and  "python manage.py migrate --settings=config.settings.local"

I'm not modifying the migrations files and I dont have an app with the label of admin, thats just the built-in admin. Thanks

I know you were doing a lot of refactoring. Did you rename the accounts app after performing an initial migration (applying an old migration with the old app name structure)? It sounds like your DB and your migration files might be out of sync. If you don't have any production data, I would recommend deleting and recreating the entire database, and deleting and recreating your migrations so that all the migrations are run in the correct order.

If you do have data you want to keep, then very likely you now have a ton of work to do writing custom migrations to sync everything back up manually. 

-James

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/0686084f-1d5a-4f61-823e-7d84c58f317c%40googlegroups.com.

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

--

Melvyn Sopacua

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Bgw1GVEqNVRDvZuUn_3o02ZvL_vZJctBqbVNdfFCcmfMwPMuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Testing file upload via a form?

​In the documentation of the test client it is all spelled out how to test file uploads.

​

​

On Tue, Aug 29, 2017 at 8:48 PM, Derek <gamesbook@gmail.com> wrote:

(Python 3.5 and Django 1.10)

I am trying to test a Django form that enables a required file upload.

The form is very simple and includes a field that looks like:

    upload_file = forms.FileField()

The corresponding test to try and check the upload:

def test_form_validation_with_file(self):

    fake_file = ContentFile(b'''Some file content''')

    fake_file.name = 'fake.xls'

    suf_file = SimpleUploadedFile('suf.xls', b'''this is text''')

    data = {

        'upload_file': suf_file,

    }

    form = forms.RequestForm(data=data)

    self.assertTrue(form.is_valid())

The form validation fails i.e. it does not seem to recognise that file data has been suppplied.

I have also tried with the  "fake_file" for the data but without success.

Any help or pointers appreciated.

Thanks

Derek

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAF1Wu3OTCbnw4o749YUz-Pa1-Uo9jkGkd1KybB5rSLnp3eAMDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Melvyn Sopacua

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Bgw1GVt-pwLwdTx_0m2nj-uy0A%3DBQh8L1aeFNnraMCAy%3DP-iw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Link to download a file

Hi guys, I need some help to insert a link to download a file. In a view I read data from a csv file and I show them in a table in a template. Under the table I need to insert, when there are data, 

a link similar as Download data and when user click it, he download the datafile, previously I wrote the same data in a csv file. You can see a part of interested view and the template to show data. 

In the code doesn't download anything.

views.py 

listafile = os.listdir('static/dati')

        fileok=[]

        context={}

        i=0

        for file in listafile:

            inizio=str(file[0:4]).strip()

            if inizio==anno:   

                fileok.append(file)

            elif inizio=='coun':

                contaf=str(file[6:10]).strip()

                if contaf==anno:

                    fileok.append(file)

            else:

                pass #print "File NON trovato", inizio, anno

        

        for nomefile in fileok:

            nomedato=str(nomefile[5:-4]).strip()

            if nomedato==tipodati:

                path2file=str(("static/dati/"+str(nomefile)).strip())

                with open(path2file) as f:

                    for line in f:

                        riga = line.split(";")

                        if riga[0]==cciaa:

                            context[i]=line

                            i=i+1

        #print "context", context

        d2 = {  k:v.split(";") for k,v in context.items() }

        j=0

        datilist={} 

        field_names = ['Provincia CCIAA', 'Data Ora', 'Numero REA', 'Forma Giuridica', 'Count dati']

        f=open('static/tmp/dati.csv', 'w') 

        writer = csv.writer(f) #questa definisce la variabile writer usata x scrivere i dati nel file csv!!!

        writer.writerow(field_names)

        while j<len(d2):

            datilist[j]=[d2[j][0], d2[j][3], d2[j][5], d2[j][7], d2[j][10].rstrip(), ''] #

            writer.writerow(datilist[j])

            j=j+1      

        

        return render_to_response('showdata.html', context_instance=RequestContext(request, {'dictdati': datilist} )) 

    

    else:

        return render_to_response('home.html', context_instance=RequestContext(request, {'var': d} ))

def showdata(request):

    return render_to_response('showdata.html', context_instance=RequestContext(request, context))

showdata.html

<div class="container">

        <div class="jumbotron">

        <h1>Statistiche Dkey</h1>

        <p>Ecco in forma tabellare i dati richiesti..</p>

  

        <form method="post" action="/getdata/">

            <style>

              table { width: 90%; background-color: #FFFFFF; color: #000000; }

              th, td { width: 4%; }

            </style>

    

              <table border="0" cellspacing="0" cellpadding="0" align="center">

                <thead>

                <tr>

                  <th>Nome</th>

                  <th>Data_Ora</th>

                  <th>Numero</th>

                  <th>Forma</th>

                  <th>Count</th>

                         

                </tr>

                </thead>

                <tbody>

                 

                <tr> 

                      

                  {% for key, item in dictdati.items %}   

                     

                      {% for idx in item %} 

                        {% if idx != '' %}                     

                          <td>{{ idx }}</td>

                        {% else %}

                        <tr><td></td></tr>

                        {% endif %}

                      {% endfor %}  

                 

                  {% endfor %}    

                <tr>

                </tbody>

              </table>

        </form>

        <p><a href="{{ MEDIA_URL }}/dati.csv">Download dei dati</a><p>

        </div>

    </div> <!-- /container -->

Can someone give me some suggestion? Other posts didn't aided me. 

Thanks.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3e7a5919-f176-4789-a4dc-158e3bc906ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bizarre URL behaviour after deploying

You may have a reverse proxy on port 80 that incorrectly rewrites
/(.*) to / both ways.

On Thu, Aug 31, 2017 at 2:10 PM, Bernd Wechner <bernd.wechner@gmail.com> wrote:
> Tom,
>
> So I did a quick test now before retiring after all. And I am pulling my
> hair out now. If I restart lighttpd on port 8000 (the last step to apparent
> convergence) it works. I access both development and webserve sites on:
>
> http://127.0.0.1:8000/
>
> with server local browsers (Chrome on the dev server and Lynx on the
> webserver for lack of a desktop). And they both now have links to:
>
> http://127.0.0.1:8000/list/Player
>
> and the link serves properly on both sites!
>
> Aaargh. Simply moving the web server from port 80 to port 8000 and the
> problem went away. I could tear my hair out here. Again, a small step closer
> to pinning a cause, but not much close to understanding the reason. The site
> wants to run on 80 not 8000.
>
> So I guess more empirical tests on the morrow or weekend will include moving
> runserver onto port 80 (after checking my dev box doesn't have something
> listing there already ;-) to see if it develops the problem) and a close
> look at the code to see if I can find any port dependencies?
>
> I call Twilight Zone of this so far.
>
> Remember, this:
>
> http://127.0.0.1/Leaderboards/list/Player
>
> also works consistently on port 80, that is the menu presents that URL from
>
> <a href="{% url 'list' 'Player' %}">Players</a>
>
> and it serves that URL albeit it serves all URLS
>
> http://127.0.0.1/whatever/list/Player
>
> identically.
>
> And on port 8000 that menu presents the URL:
>
> http://127.0.0.1:8000/list/Player
>
> and serves it.
>
> The only difference is one config line in lighttpd.conf:
>
> server.port = 80
>
> vs
>
> server.port = 8000
>
> with a a lighttpd restart ("sudo /etc/init.d/lighttpd restart") between.
> Some code paths differ based on port it seems,
>
> I'll go find a wall to bang my head on now ;-).
>
> Regards,
>
> Bernd.
>
>
> 'Tom Evans' via Django users wrote:
>
> On Thu, Aug 31, 2017 at 2:09 AM, Bernd Wechner <bernd.wechner@gmail.com>
> wrote:
>> Daniel,
>>
>> Yes, I have deployed, that is the problem in a sense. URLs are clean in
>> dev
>> and suddenly contain an app_name when deployed.
>>
>> Not sure what you mean by configuration? The Django settings are here:
>>
>> https://github.com/bernd-wechner/CoGs/blob/master/CoGs/settings.py
>>
>> The rest of the config is uwsgi under lighttpd, but none of that is likely
>> to impact the appearance of an app_name in my URLs all of a sudden. I
>> don't
>> mind sharing the config files, but it's a distraction I fear.
>
> I think you will be surprised.
>
> I'm surprised your diagnosis doesn't point you at this straight away,
> if the URLs are correct on one site but incorrect on another site, and
> both sites run the exact same python/django code, then the error is
> certainly in the bits that are different.
>
> Cheers
>
> Tom
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscribe@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/862e89bd-19ab-1a20-9fcc-8f5152eed92d%40gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
Melvyn Sopacua

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Bgw1GUnbnTcqA4TjQTHyOEuy_bZKSDTSsLWfhs8vymPFYneBA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bizarre URL behaviour after deploying

Tom,

So I did a quick test now before retiring after all. And I am pulling my hair out now. If I restart lighttpd on port 8000 (the last step to apparent convergence) it works. I access both development and webserve sites on:

    http://127.0.0.1:8000/

with server local browsers (Chrome on the dev server and Lynx on the webserver for lack of a desktop). And they both now have links to:

    http://127.0.0.1:8000/list/Player

and the link serves properly on both sites!

Aaargh. Simply moving the web server from port 80 to port 8000 and the problem went away. I could tear my hair out here. Again, a small step closer to pinning a cause, but not much close to understanding the reason. The site wants to run on 80 not 8000.

So I guess more empirical tests on the morrow or weekend will include moving runserver onto port 80 (after checking my dev box doesn't have something listing there already ;-) to see if it develops the problem) and a close look at the code to see if I can find any port dependencies?

I call Twilight Zone of this so far.

Remember, this:

    http://127.0.0.1/Leaderboards/list/Player

also works consistently on port 80, that is the menu presents that URL from

    <a href="{% url 'list' 'Player' %}">Players</a>

and it serves that URL albeit it serves all URLS

    http://127.0.0.1/whatever/list/Player

identically.

And on port 8000 that menu presents the URL:

    http://127.0.0.1:8000/list/Player

and serves it.

The only difference is one config line in lighttpd.conf:

    server.port                 = 80

vs

    server.port                 = 8000

with a a lighttpd restart ("sudo /etc/init.d/lighttpd restart") between. Some code paths differ based on port it seems,

I'll go find a wall to bang my head on now ;-).

Regards,

Bernd.


'Tom Evans' via Django users wrote:

On Thu, Aug 31, 2017 at 2:09 AM, Bernd Wechner <bernd.wechner@gmail.com> wrote:  > Daniel,  >  > Yes, I have deployed, that is the problem in a sense. URLs are clean in dev  > and suddenly contain an app_name when deployed.  >  > Not sure what you mean by configuration? The Django settings are here:  >  >     https://github.com/bernd-wechner/CoGs/blob/master/CoGs/settings.py  >  > The rest of the config is uwsgi under lighttpd, but none of that is likely  > to impact the appearance of an app_name in my URLs all of a sudden. I don't  > mind sharing the config files, but it's a distraction I fear.    I think you will be surprised.    I'm surprised your diagnosis doesn't point you at this straight away,  if the URLs are correct on one site but incorrect on another site, and  both sites run the exact same python/django code, then the error is  certainly in the bits that are different.    Cheers    Tom    

Re: Bizarre URL behaviour after deploying

server.modules = (
"mod_access",
"mod_accesslog",
"mod_alias",
"mod_compress",
"mod_redirect",
"mod_rewrite",
"mod_scgi",
)

# Configure the logs (on USB drive)
accesslog.filename = "/mnt/passport/log/lighttpd/access.log"
accesslog.format = "%t %h %V %u \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
server.errorlog = "/mnt/passport/log/lighttpd/error.log"

# Debugging info sent to the errorlog if enabled
#debug.log-request-header = "enable"
#debug.log-condition-handling = "enable"

server.document-root = "/var/www/html"
server.upload-dirs = ( "/var/cache/lighttpd/uploads" )
server.pid-file = "/var/run/lighttpd.pid"
server.username = "www-data"
server.groupname = "www-data"
server.port = 8000

index-file.names = ( "index.php", "index.shtml", "index.html", "index.lighttpd.html" )
url.access-deny = ( "~", ".inc" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

compress.cache-dir = "/var/cache/lighttpd/compress/"
compress.filetype = ( "application/javascript", "text/css", "text/html", "text/plain" )

# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

$HTTP["host"] == "bernd.wechner.info" {
server.document-root = "/var/www/html/bernd.wechner.info"
}

$HTTP["host"] == "hitch-hiking.info" {
server.document-root = "/var/www/html/hitch-hiking.info"
}

$HTTP["host"] == "leaderboard.space" {
url.rewrite-once = ( "^/favicon\.ico$" => "/static/favicon.ico" )

$HTTP["url"] =~ "^/static/" {
server.document-root = "/var/www/html/leaderboard.space"
} else $HTTP["url"] !~ "^/static/" {
scgi.protocol = "uwsgi"
scgi.server = ( "/" => (( "socket" => "/var/run/lighttpd/uwsgi.socket-0", "check-local" => "disable" )), )
}
}

$HTTP["host"] == "127.0.0.1" {
url.rewrite-once = ( "^/favicon\.ico$" => "/static/favicon.ico" )

$HTTP["url"] =~ "^/static/" {
server.document-root = "/var/www/html/leaderboard.space"
} else $HTTP["url"] !~ "^/static/" {
scgi.protocol = "uwsgi"
scgi.server = ( "/" => (( "socket" => "/var/run/lighttpd/uwsgi.socket-0", "check-local" => "disable" )), )
}
}

Daniel,

it's a red herring. I agree, that's where I'd suspect the issue lies, but I'm still confident it's a red herring. But because I'm stuck even the seemingly impossible needs to be revisited I guess. It's hard to share everything about a webservers config of course in an email, but there are two files of relevance attached if it helps.

lighttp.conf is the lighttp configuration which talks to uwsgi, and uwsgi.ini is the uwsgi config that loads the django app and serves it (over a unix domain socket to lighttpd). The former is incomplete as it has includes (it gets complicated fast I guess), but the relevant section is in fact repeated to serve the domain name and the 127.0.0.1 URL as I was just testing a convergence plan after reading Tom's suggestion below (and rather than read up on "or" conditional in lighttpd confs I just duplicated the block verbatim for now.

Regards,

Bernd.

Daniel Roseman wrote:

On Thursday, 31 August 2017 10:51:22 UTC+1, Tom Evans wrote:

On Thu, Aug 31, 2017 at 2:09 AM, Bernd Wechner <bernd....@gmail.com> wrote:
> Daniel,
>
> Yes, I have deployed, that is the problem in a sense. URLs are clean in dev
> and suddenly contain an app_name when deployed.
>
> Not sure what you mean by configuration? The Django settings are here:
>
>     https://github.com/bernd-wechner/CoGs/blob/master/CoGs/settings.py
>
> The rest of the config is uwsgi under lighttpd, but none of that is likely
> to impact the appearance of an app_name in my URLs all of a sudden. I don't
> mind sharing the config files, but it's a distraction I fear.

I think you will be surprised.

I'm surprised your diagnosis doesn't point you at this straight away,
if the URLs are correct on one site but incorrect on another site, and
both sites run the exact same python/django code, then the error is
certainly in the bits that are different.

Cheers

Tom

Yes. Especially as the problem doesn't seem to be "an app name in my urls" but "a random prefix in my urls". We do need to see the lighttpd and uwsgi configs.

--

DR.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/92ba18a5-4332-493b-a268-928e1f5feabc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bizarre URL behaviour after deploying

Tom,

I will credit you there with stating the obvious in a sense, that I was reluctant to accept. Because it seems frankly impossible. But when nothing seems possible, we do need to revisit the "apparently" impossible, so I pulled a sweet trick and tried identical code in devlopment and deployment.

That required an upgrade to Django on development as it had 1.11.2 and the webserver deployed on had 1.11.4 so now both have 1.11.4.

Then I tweaked settings.py so it runs the Development settings on the Webserver.  Essentially the only bit of varied code between the two instances in in settings.py and reads:

ALLOWED_HOSTS = ["127.0.0.1", "leaderboard.space"]

import platform
HOSTNAME = platform.node()

if HOSTNAME == WEBSERVER:
    print("Django settings: Web Server")
else:
    print("Django settings: Development Server")
    DEBUG = True

And I see "Django settings: Development Server" echoed by runserver when it starts and by uwsgi on the web server.

And so now the only difference remaining is that the dev server uses:

    http://127.0.0.1:8000/

and the webserver:

    http://leaderboard.space/

Now when I test on both sites, the problem goes away! So you are on the money my friend! Now there's a menu link say for listing players and it looks respectively like:

http://127.0.0.1:8000/list/Player
http://leaderboard.space/list/Player

Where the latter (without DEBUG = True) links to:

http://leaderboard.space/Leaderboards/list/Player

and that problem goes away just by using DEBUG = True.

Which does not explain it, but pinpoints the cause. I would still love to understand how that is not a Django bug and how to lose that URL snippet without being in DEBUG mode.

BUT, ain't there always a but, although the menu link lost the app_name from the URL It now works on the Development server (i.e. lists players in the database) and on the web server dumps with 404:

Page not found (404)

Request Method:	GET
Request URL:	http://leaderboard.space/list/Player
Raised by:	Leaderboards.views.view_List

Using the URLconf defined in CoGs.urls, Django tried these URL patterns, in this order:

1. ^$ [name='home']
2. ^admin/
3. ^login/$ [name='login']
4. ^logout/$ [name='logout']
5. ^fix [name='fix']
6. ^unwind [name='unwind']
7. ^check [name='check']
8. ^rebuild [name='rebuild']
9. ^kill/(?P<model>\w+)/(?P<pk>\d+)$ [name='kill']
10. ^list/(?P<model>\w+) [name='list']
11. ^view/(?P<model>\w+)/(?P<pk>\d+)$ [name='view']
12. ^add/(?P<model>\w+)$ [name='add']
13. ^edit/(?P<model>\w+)/(?P<pk>\d+)$ [name='edit']
14. ^delete/(?P<model>\w+)/(?P<pk>\d+)$ [name='delete']
15. ^leaderboards [name='leaderboards']
16. ^json/game/(?P<pk>\d+)$ [name='get_game_props']
17. ^json/leaderboards [name='json_leaderboards']
18. ^static\/(?P<path>.*)$

The current path, Player, didn't match any of these.

You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False, and Django will display a standard 404 page.

again I would love to know how that is not a Django bug, because it says "http://leaderboard.space/list/Player" does not match "^list/(?P<model>\w+) [name='list']" which it does on the Development server (understandably, as it does visually here).

Hmmm ... a little closer to seeing what's happening, a little, but not much closer to understanding what is happening alas. And now, code is identical, only the URL is different, and

So trying to converge even that difference, I access it on the webserver (which is a server, and hence lacks GUI, but lynx to the rescue) and I can navigate to http://127.0.0.1 and I see the site and click on the Players link and get:

 Request Method: GET
    Request URL:   http://127.0.0.1/list/Player
     Raised by:    Leaderboards.views.view_List

   Using the URLconf defined in CoGs.urls, Django tried these URL patterns, in this order:
    1. ^$ [name='home']
    2. ^admin/
    3. ^login/$ [name='login']
    4. ^logout/$ [name='logout']
    5. ^fix [name='fix']
    6. ^unwind [name='unwind']
    7. ^check [name='check']
    8. ^rebuild [name='rebuild']
    9. ^kill/(?P<model>\w+)/(?P<pk>\d+)$ [name='kill']
   10. ^list/(?P<model>\w+) [name='list']
   11. ^view/(?P<model>\w+)/(?P<pk>\d+)$ [name='view']
   12. ^add/(?P<model>\w+)$ [name='add']
   13. ^edit/(?P<model>\w+)/(?P<pk>\d+)$ [name='edit']
   14. ^delete/(?P<model>\w+)/(?P<pk>\d+)$ [name='delete']
   15. ^leaderboards [name='leaderboards']
   16. ^json/game/(?P<pk>\d+)$ [name='get_game_props']
   17. ^json/leaderboards [name='json_leaderboards']
   18. ^static\/(?P<path>.*)$

   The current path, Player, didn't match any of these.

   You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False,
   and Django will display a standard 404 page.

Now runserver is using port 8000 and lighttpd is using port 80, but to converge those will have to wait till the morrow I think (I have to lighttpd on port 8000 or runserver on port 80) and my guess is no change.

I note that Django knows it's running under runserver because when running under runserver it runs fine without ALLOWED_HOSTS set and on the web server if that is missing it bombs. To wit, Django knows its context and can be and probably is it seems following different code paths internally based on that context.

Hmmm ...

The bother is, on the deployment server it's not easy to debug (uwsgi is loading and running django).

Regards,

Bernd.

'Tom Evans' via Django users wrote:

On Thu, Aug 31, 2017 at 2:09 AM, Bernd Wechner <bernd.wechner@gmail.com> wrote:  > Daniel,  >  > Yes, I have deployed, that is the problem in a sense. URLs are clean in dev  > and suddenly contain an app_name when deployed.  >  > Not sure what you mean by configuration? The Django settings are here:  >  >     https://github.com/bernd-wechner/CoGs/blob/master/CoGs/settings.py  >  > The rest of the config is uwsgi under lighttpd, but none of that is likely  > to impact the appearance of an app_name in my URLs all of a sudden. I don't  > mind sharing the config files, but it's a distraction I fear.    I think you will be surprised.    I'm surprised your diagnosis doesn't point you at this straight away,  if the URLs are correct on one site but incorrect on another site, and  both sites run the exact same python/django code, then the error is  certainly in the bits that are different.    Cheers    Tom