Argthtjtr

I have a Django app that resolved urls correctly as of a few days ago but no longer does so. Looking at my git log nothing pertaining to urls changed, but all of a sudden is appears Django is not loading urls for the application in question.

The debug page shows the app is installed (though it's last in the load order, if that matters). The behavior I'm seeing implies that Django is either ignoring or overriding only some parts of the app's urls.py file though-- some urls defined by the app in the same urls.py file do load!

Namespacing: While it would likely make short work of the issue, I'm trying to override existing non-namespaced urls and cannot refactor the code that exists outside the scope of my app to establish the namespace. So that is not an option. I simply want to trump the parent project's url resolution so my views are called instead of stock.

Template tags: They appear correct, but more importantly this isn't about a failure to render, it's about the url supposedly not existing in the first place.

Example: The view name in question is 'objects', but none of these object views work. As an example of the source of my confusion, here's the content of the 404 error I'm getting when I go to a bogus page (/efwefwefijiefj/):

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

    ^objects/detail/(?P<slug>[wd-]+)/(?P<pk>[0-9]+)/$ [name='object-detail']

    ^objects/create/$ [name='object-create']

    ^objects/$ [name='objects']

    ...

We can both see that objects is a named view, the app it belongs to exists, and it's one of the first URLs evaluated. But if you try to actually go to the /objects/ page, that's when you get the NoReverseMatch error.

Any help would be appreciated!

I checked all the template tags, the url patterns, messed around with the order of app loading and url resolution. Nothing worked.

As I started stripping every URL template tag I had written out of my application I came across another NoReverseMatch for a reverse() on a FormView's success_url.

That was one of the last changes I had made but that one should absolutely exist; figuring this whole thing was an error that manifested due to Django loading things inconsistently/out-of-order I deferred reversal of that url by changing it to a reverse_lazy().

Everything works now. A prematurely-reversed URL as an attribute of a class-based view that had nothing to do with the objects view itself is what resulted in this incredibly opaque error.

I should have known better but the initial diagnostic information Django provided was of no help at all, so I'm leaving this out there as something else to check if you encounter this error-- most other questions/answers pertain to trivial regex errors in urls.py or misuse of template tags.

Don't set class-based view attributes to the result of reverse()-- use reverse_lazy() to account for all apps not having loaded yet!