CODEWITHSUNDEEP
pythondjangodjango-cms
Plamen Nikolov
Plamen Nikolov

Reputation: 4187

Django 1.10 & Django-cms 3.4.4 - NoReverseMatch for some browsers

I stumbled across on a very strange issue. The dev env is Django 1.10 & django-cms 3.4.4. When I try to load localhost in Chrome & Firefox everything works fine, but if I try to open it in Safari, it fails with NoReverseMatch at / and it fails with random urls. I also tried to 

curl http://localhost:8000/

and it works fine. Also tried on Windows and different browsers and it fails for some browsers with the same error. Does someone have any idea what could be the issue? Thanks!

P.S.

Reverse for 'model' with arguments '(u'bmw',)' and keyword arguments '{}' not found. 0 pattern(s) tried: []

It seems that it doesn't load any urls at all. 0 patterns tried means there is nothing loaded I guess?

Upvotes: 0

Views: 92

Answers (1)

Plamen Nikolov
Plamen Nikolov

Reputation: 4187

I think I found it. Long story short

The default cms is configured to use English as primary language, but I want my primary language to be Bulgarian. I configured the CMS to support both languages and I've made Bulgarian to be default and English is disabled. Then I got rid of the i18n_patterns() wrapper in urls.py to get rid of the /en/ /bg/ etc prefixes. So far so good. The admin site works great. There is only one language - Bulgarian, there are pages and custom apps attached to them. When I load the front end with wrong url on Safari just to see all the supported URLs, I can't see any applications attached and urls for them. If I do the same with Chrome - it shows urls for all attached applications. It turns out that Chrome loads the Bulgarian page configuration and all the configured applications, but Safari loads the English page which is disabled and there are no attached applications to it.

My first guess was the Accept-Language header. Safari uses Accept-Language: en, but other browsers send bg. I tried to tamper the data, but nothing happened. Then I noticed there is a django_language cookie being used by the LocaleMiddleware that actually determines the language. When I disabled the middleware, everything worked like a charm.

Thanks!

Upvotes: 2

Related Questions