I'm relatively new using Mezzanine and Django. But I run the manage.py with runserver as a parameter and I get the following error.
ERRORS:
?: (urls.E004) Your URL pattern (u'^', (<module 'mezzanine.urls' from
'C:\Users\khirst\InovaSupportSiteIsolated\lib\site-packages\mezzanine\urls.py'>, None, Non
e)) is invalid. Ensure that urlpatterns is a list of url() instances.
HINT: Try using url() instead of a tuple.
I browsed through Mezzanine's urls.py, and it seems to be properly updated for the new urlpatterns standards. I am using Django 1.10.0, and Mezzanine 4.2.2.
There are several lines that use
urlpatterns += [url("^", include("..") ..
of some sort. I am guessing that
means that for every url, add the following module as a possible match. It seems that Django doesn't like one of these. I can't find any help with this on Mezzanine's site or otherwise. Supposedly this version of Mezzanine and Django are supposed to be compatible. Has anyone else encountered this?
I blamed mezzanine, but it was our fault in our base module.
We had a tuple in our urls file.
("^", include("mezzanine.urls"))
That needed to be
url("^", include("mezzanine.urls"))
But Django was complaining as if it was in mezzanine's code.
Related
Today I decided to upgrade my project from Django 1.11 to 2.2.1. I've been working through various issues with my project, and I'm fighting through them. However, I spent most of tonight trying to get the URLs to work and they won't cooperate. Long story short, I have multiple app in my project and each app has a URL with it's own namespace. In Django 1.11 this is working fine. However, when I try to port the logic over to Django 2.2.1, I keep getting an error saying that I have a circular import somewhere probably.
Here is a snippit of what works just fine in Django 1.11.......
My Main Project...In Django 1.11
url(r'^Main/',include('AppA.urls',namespace="AppA")),
But when I try to do this in Django 2.2.1.....
I realize that URLs were replaced by paths...
path('', include('AppA.urls')),
But when I try to start my application it says....
your project does not appear to have any patterns in it. If you see valid p
atterns in the file then the issue is probably caused by a circular import.
I can't seem to figure out how to create the namespace that is working in django 1.11 so that I can properly reference my urls in my templates.
I've been staring at this most of the evening and that might be why I'm not seeing it...I also looked at the Django doc...https://docs.djangoproject.com/en/2.2/topics/http/urls/
And I just can't see what I might be doing wrong. Thanks in advance for any help to get me back on track.
As Bloodmallet pointed out to me...
I needed to add....
app_name = 'Appa'
to the top of my urls.py file. After doing this, the path URL worked as expected.
Instead of path(), consider using re_path():
from django.urls import include, re_path
re_path(r'^Main/',include('AppA.urls',namespace="AppA")),
I am in the process of upgrading huge project from Django 1.6.2 towards latest 1.8 version.
Following all release notes here: https://docs.djangoproject.com/en/1.8/releases/1.7/#using-a-custom-manager-when-traversing-reverse-relations
I believe I revisited my entire project for backwards incompatibilities, but I am still getting this error on any reverse url call to any admin page.
from django.core.urlresolvers import reverse
reverse('admin:scanners_scanner_changelist')
NoReverseMatch: Reverse for 'scanners_scanner_changelist' with arguments '()' and keyword arguments '{}' not found. 0 pattern(s) tried: []
This was working just fine on django 1.6.x
It's very frustrating as this error tells you nothing... Basically you have to guess and try what's wrong. Do any of you guys have some ideas what I might be missing, what is changed from Django 1.6 to 1.7 that could potentially cause this?
All other urls work fine except for admin changelist and change urls.
Finally figured this out. django-adminplus was a cause of this.
So if you are having similar problems when upgrading from Django 1.6.x to 1.7.x try to change django.contrib.admin to django.contrib.admin.apps.SimpleAdminConfig and do not remove admin.autodiscover() from your main urls.py file. This way you are doing admin discovery manually and explicitly, the old way instead of new implicit method which might cause you troubles if you are doing some serious hacking within your project.
Cheers!
I've configured url.py as is explained in different places of the Django documentation, but its behaviour is completely anomalous, between consecutives acceses. In Debug Mode and after looking for an url I get the "Page not found" error. The strange thing is that between acceses the error given is different:
... Django tried these URL patterns, in this order:
^admin/?$
^cheqsim/?$
^login/?$
^logout/?$
^questions/?$
But if I look at url.py my last element is ^searchquestions/?$ and I had restarted the server before looking at it, but the error is indicating me a different urlpattern from the actual in url.py.
Then I keep looking URLs and when I delete all the cookies and I try some non-existent URL I get the actual URL.py:
, Django tried these URL patterns, in this order:
^login/?$
^logout/?$
^admin/?$
^cheqsim/?$
^searchquestions/?$
Ok, so now I try http://mysite.com/myprojecturl/searchquestions/ and voila! It appears a new pattern error that leave me completely knock out:
, Django tried these URL patterns, in this order:
^admin/?$
^cheqsim/?$
^login/?$
^logout/?$
A pattern that I had used like 5 or 6 hours ago!!!
Please, do anybody have any idea of what is happening to me because this is really frustrating...
Thank you very much
P.S.: By the way, some URLs matches sometimes magicly
Check if you have multiple runserver instances running.
Check the ROOT_URLCONF setting
It seems the solution is changing the project.wsgi file and is well explained here: http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html
Anyway only time will know... xD
I have an app called lastapp that I would like it to be viewable on all pages. It renders base.html so it's available on all apps. So far I've tried adding it to the urls.py like this:
urlpatterns = patterns('',
(r'^first/$', firstapp, lastapp),
(r'^last/$', lastapp),
)
But when I go to /first/ it gives me the error: Error, 'function' not iterable. It shows fine when going to /last/. If I remove lastapp from the /first/ site in urls.py, then firstapp shows fine also. Is there a special way to do this? Thanks in advance.
What exactly are you trying to do?
All installed applications are available in your project, but the application by it self does not return any data to the template, that's the job of the views which are part of that application.
My guess is that firstapp and lastapp are rather views then apps.
If that is a case, context processors make it possible to always pass certain data to a template.
So, create a context processor out of lastapp and set it in TEMPLATE_CONTEXT_PROCESSORS in settings.py.
I think what you need is probably Middleware.
I'm having a problem with configuring Flatpages in Satchmo. I've used them before, in a pure django app, but now it just doesn't work, returning 301 http error when I'm trying to enter a flatpage-configured site.
What I've done to configure it:
added the middleware "django.contrib.flatpages.middleware.FlatpageFallbackMiddleware" to MIDDLEWARE_CLASSES as last in the list,
configured example pages in admin module.
Simply what the docs say about flatpages config.
I'm feeling helpless. Don't know how could I debug this issue. Any thoughts on that?
And of course help appreciated.
Thanks to suggestion by Peter I've managed to narrow the problem to my urls.py file, for the satchmo shop.
The urlpatterns has only one entry:
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),
This version does not work and moreover interfere with flatpages. But disabling flatpages from MIDDLEWARE_CLASSES and adding it to urls.py like the snippet below works:
(r'^(?P<url>.*)$', 'django.contrib.flatpages.views.flatpage'),
(r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}),
However next problem is with the redirection from / to /shop/. With the above config it results in infinite loop.
Perhaps you know the reason for that behavior (redirect overriding flatpage) and maybe You could suggest some working solution to this problem or what should be done with requests to /.
It returns 301? That's Page Moved Permanently (HttpResponsePermanentRedirect) and there are no references to that in the flatpages directory so I don't think it's coming from there. In fact there are only about 5 references to HttpResponsePermanentRedirect in all of the standard 1.1.1 release.
Possible approaches:
Comment out the FlatPages middleware and see if the error changes (I'm betting it won't).
Try changing the order of your MIDDLEWARE classes and see if things change.
When presenting a problem like this it's better to get very specific by showing the exact code from applicable portions of settings.py (or whatever) and by giving other things like precise URLs and the urls.py patterns you are trying to match.
Update:
OK, some random thoughts:
The pattern (r'^(?P<url>.*)$', 'django.contrib.flatpages.views.flatpage'), will match anything. Any patterns after it will never be seen.
flatpages doesn't work by being called directly, it does its magic in middleware. It looks for 404 responses (Page Not Found) and then looks to see if that path exists in its table. If so, it calls a view that renders the page, etc. etc. If it doesn't find a match it let's the 404 continue on through middleware processing.
The pattern (r'', 'django.views.generic.simple.redirect_to', {'url' : '/shop/'}), will match anything (I just tested it). If you want to match an empty path, use r('^$', etc.). This is the source of your infinite loop.
If you are new to regular expressions the Django urls.py file can seem like F*cking Magic. I recommend starting very simply and add one rule at a time. Do some quick tests to ensure that the new rule a) matches stuff you want it to match, and b) doesn't match stuff it shouldn't. In particular, make sure that some of the rules that occur later in the file are still reachable. In this case they wouldn't have been which should have raised a red flag.