Redirect issue when used with Mezzanine 1.4.16

[moltra]

I am working on a site using Mezzanine 1.4.16. When I enable debug_toolbar, I start getting redirect errors. The django_redirect table is totally empty, but with debug_toolbar enabled it is used for some reason.

I get the below information when I have the debug_toolbar enabled.

Page not found (404)
Request Method: GET
Request URL:    http://127.0.0.1:8000/blog/test/ncis/
No BlogPost matches the given query.

This is the SQL generated by debug_toolbar when it is enabled and I try and go to page.

  default
2.00 ms (3 queries)
    Query   Timeline    Time (ms)   Action
    -   
SELECT "django_session"."session_key", "django_session"."session_data", "django_session"."expire_date" FROM "django_session" WHERE ("django_session"."session_key" = '71c98ic7cqae1awd4k6v11pa6zm1hvhd' AND "django_session"."expire_date" > '2013-12-23 17:23:14.738000' )
100.0%
2.00    
Sel  Expl
Connection: default
C:\django\mezz\lib\site-packages\mezzanine\core/middleware.py in process_response(234)
  "site_id": current_site_id(),
C:\django\mezz\lib\site-packages\mezzanine\utils/sites.py in current_site_id(33)
  site_id = request.session.get("site_id", None)
    -   
SELECT "django_site"."id", "django_site"."domain", "django_site"."name" FROM "django_site" WHERE "django_site"."domain" LIKE '127.0.0.1:8000' ESCAPE '\'
0%
0.00    
Sel  Expl
Connection: default
C:\django\mezz\lib\site-packages\mezzanine\core/middleware.py in process_response(234)
  "site_id": current_site_id(),
C:\django\mezz\lib\site-packages\mezzanine\utils/sites.py in current_site_id(45)
  site = Site.objects.get(domain__iexact=domain)
    -   
SELECT "django_redirect"."id", "django_redirect"."site_id", "django_redirect"."old_path", "django_redirect"."new_path" FROM "django_redirect" WHERE ("django_redirect"."site_id" = 1 AND "django_redirect"."old_path" = '/duck-dynasty/' )
0%
0.00    
Sel  Expl
Connection: default
C:\django\mezz\lib\site-packages\mezzanine\core/middleware.py in process_response(238)
  redirect = Redirect.objects.get(**lookup)

This is what I have installed in the virtualenv

mezz) C:\django\mezz\website>yolk -l
Django          - 1.5.5        - active
Mezzanine       - 1.4.16       - active
Pillow          - 2.2.1        - active
South           - 0.8.4        - active
bleach          - 1.2.2        - active
django-appconf  - 0.6          - active
django-compressor - 1.3          - active
django-debug-toolbar - 1.0          - active
filebrowser-safe - 0.2.31       - active
grappelli-safe  - 0.2.23       - active
html5lib        - 0.95         - active
oauthlib        - 0.6.0        - active
pip             - 1.4.1        - active
pytz            - 2013.8       - active
requests-oauthlib - 0.3.3        - active
requests        - 1.2.3        - active
setuptools      - 0.9.8        - active
six             - 1.4.1        - active
sqlparse        - 0.1.10       - active
yolk            - 0.4.3        - active

[aaugustin]

I'm not sure I understand your explanation. Are you saying that a page of your site displays correctly without the toolbar but returns a 404 not found with the toolbar?

The redirects table isn't used by the debug_toolbar. It's used by Mezzanine as shown in your traceback and in the Mezzanine source code:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/core/middleware.py#L236-L261

[aaugustin]

I don't know where to start with the information available in the ticket :-/ It could be a middleware ordering issue.

[moltra]

What other information do you need?

[moltra]

yes the page displays correctly without the toolbar, but gives a 404 error when I try and view the page with debug_toolbar enabled.

From: Aymeric Augustin
Sent: Monday, December 23, 2013 12:49 PM
To: django-debug-toolbar/django-debug-toolbar
Cc: moltra
Subject: Re: [django-debug-toolbar] Redirect issue when used with Mezzanine 1.4.16 (#509)

I'm not sure I understand your explanation. Are you saying that a page of your site displays correctly without the toolbar but returns a 404 not found with the toolbar?

The redirects table isn't used by the debug_toolbar. It's used by Mezzanine as shown in your traceback and in the Mezzanine source code:
https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/core/middleware.py#L236-L261

—
Reply to this email directly or view it on GitHub.

---

This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[moltra]

I have commited what I have setup in my virtualenv and you can look at it at https://github.com/moltra/mezz . admin name is mark and password is password if you want to run it and see the error yourself.

From: Aymeric Augustin
Sent: Monday, December 23, 2013 12:50 PM
To: django-debug-toolbar/django-debug-toolbar
Cc: moltra
Subject: Re: [django-debug-toolbar] Redirect issue when used with Mezzanine 1.4.16 (#509)

I don't know where to start with the information available in the ticket :-/ It could be a middleware ordering issue.

—
Reply to this email directly or view it on GitHub.

---

This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[stephenmcd]

I can confirm this issue - DebugToolbarMiddleware.process_view prevents other middleware from running, which wasn't the case prior to DDT 1.0

[stephenmcd]

Extra background:

Mezzanine will automatically configure DDT if available - in which case it puts DDT's middleware to the top of the middleware order. I don't recall the reasoning for this, and since it does this explicitly I'm certain there was a specific reason for it at some point, but that code is several years old so I can't recall.

Now prior to DDT 1.0, DebugToolbarMiddleware.process_view did not actually return a response, which would allow other middleware after it in the middleware order to still run. However now in DDT 1.0 DebugToolbarMiddleware.process_view returns a response preventing middleware ordered after it from executing.

Unrelated to DDT, but the reason for the above description around 404s being generated is that Mezzanine actually depends on its own middleware executing to correctly identify content to load, and if that doesn't happen a 404 response is returned.

I'll be changing the setup code in Mezzanine to put DebugToolbarMiddleware at the end of the middleware ordering, which will resolve the issue in Mezzanine at least - however I wouldn't be surprised if there are further reports of DDT 1.0 breaking other projects that previously have worked fine without DebugToolbarMiddleware being specified last in the middleware order.

[stephenmcd]

Further, this appears to be a duplicate of #497

[aaugustin]

@stephenmcd Thanks a lot for the detailed explanation! It's very helpful.

(I had tried to run the project provided by @moltra but couldn't make it work; settings didn't seem to be correct.)

In fact before 1.0 the DDT would execute each view twice, once under profiling in process_view (but the generated response wasn't returned) and once normally. This resulted in duplicates as soon as a view wasn't idempotent.

I can't really blame the middleware ordering on Mezzanine as the DDT's automatic setup code also puts the middleware in first position: https://github.com/django-debug-toolbar/django-debug-toolbar/blob/master/debug_toolbar/models.py#L43-L46

Anyway, this is indeed a duplicate of #497, and I will copy relevant parts of this comment over there.