Ok, makes sense. Thank you very much for the details Daniel. Doug On Sunday, January 21, 2018 at 1:02:33 PM UTC-7, Daniel Hepper wrote: > > Yes, kind of. There are two kinds of redirects, temporary and permanent > redirects. By default Django's redirect() method returns a temporary > redirect. If you pass permanent=True, it returns a permanent redirect. > > So here is what happened in your case: > > 1. You run the MDN tutorial project and point your browser to > http://127.0.0.1:8000/ > 2. The browser requests the path / from the server 127.0.0.1:8000 (the > runserver running the MDN tutorial project) and receives a permanent > redirect to /catalog/ > 3. Then you stop the MDN project and run your own project. > 4. You then point your browser to http://127.0.0.1:8000 > 5. Your browser thinks "wait a minute, last time I accessed the path / on > the server 127.0.0.1:8000, it returned a permanent redirect to /catalog/. > I'll save my user some time and just go directly to /catalog/". > > Now, if a URL returns a temporary redirect, the browser knows that this > redirect is, well, temporary, so it might point to a different location the > next time or there might be no redirect at all. Therefore, it must load the > original URL. > > In the example of the tutorial, a permanent redirect should not be used, > not only because it can lead to the problem you encountered. > > Imagine you use this software for your local library at > http://smalltownlibrary.com/. After a while, you want to add another > feature, e.g. a book shop under /shop/ where visitor can buy used books. > You then want to add a homepage at / where users can select whether they > want to access catalogue or the shop. It works fine for new users, but > everyone who accessed the site http://smalltownlibrary.com/ before is not > able to access the new homepage because their browser has cached the > permanent redirect to the catalog. > > Permanent redirects definitely have their place, e.g. if you moved your > website to a new URL and want to tell the search engines that they should > only look at the new URL. But you have to be aware that they are indeed > permanent. > > Hope that clarifies it a bit. > > Daniel > > On Sunday, January 21, 2018 at 7:26:39 PM UTC+1, Doug Nintzel wrote: >> >> That got it Daniel...thanks for the quick help. Was it " permanent=True" >> in particular that was the problem? >> Thanks again, >> Doug >> >> On Sunday, January 21, 2018 at 10:29:33 AM UTC-7, Daniel Hepper wrote: >>> >>> I realized that the Mozilla tutorial is a wiki, so I took the liberty to >>> remove the "permant=True" from the redirect. >>> >>> On Sun, Jan 21, 2018 at 6:23 PM, Daniel Hepper <[email protected]> >>> wrote: >>> >>>> It's not the new project referencing the old project, it is actually >>>> your browser caching the redirect from http://127.0.0.1:8000/ to >>>> http://127.0.0.1:8000/catalog/. >>>> Because it is a permanent redirect, your browser won't access >>>> http://127.0.0.1:8000/, it will go http://127.0.0.1:8000/catalog/. >>>> >>>> You can usually get rid of this redirect by clearing your browser >>>> cache. How exactly that is done depends on the browser you are using. >>>> >>>> This also teaches an important lesson about permanent redirects. Only >>>> use them when you are absolutely sure that you (and more importantly your >>>> users) will never again want to access the old URL. >>>> >>>> Hope that helps, >>>> Daniel >>>> >>>> >>>> >>>> On Sun, Jan 21, 2018 at 6:06 PM, Doug Nintzel <[email protected]> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I am new to Django and followed this Mozilla Django Tutorial >>>>> <https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/development_environment> >>>>> which >>>>> was very helpful, and created the 'locallibrary' project. >>>>> As part of the exercise, it has you create a 'catalog' app and has you >>>>> set up a redirect to the default app >>>>> <https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/skeleton_website> >>>>> ('catalog') >>>>> as below >>>>> >>>>> locallibrary\locallibrary\urls.py >>>>> path('', RedirectView.as_view(url='/*catalog*/', >>>>> permanent=True)), >>>>> >>>>> >>>>> The whole tutorial went smoothly, but now I am wanting to create my >>>>> own project so I created a new virtual environment, created a new >>>>> site/project, and for sanity check started the server "python manage.py >>>>> runserver" in the new project and then tried to navigate to the >>>>> http://127.0.0.1:8000/ , but it instead tries to redirect to the >>>>> tutorial project's app http://127.0.0.1:8000/*catalog*/ and gets a >>>>> 404. >>>>> >>>>> I tried to install Django in the new virtual environment, but no help. >>>>> Here are the errors and some other messages: >>>>> Page not found (404) >>>>> Request Method: GET >>>>> Request URL: http://127.0.0.1:8000/catalog/ >>>>> >>>>> Using the URLconf defined in CalendarAlerts.urls, Django tried these >>>>> URL patterns, in this order: >>>>> >>>>> 1. admin/ >>>>> >>>>> The current path, catalog/, didn't match any of these. >>>>> >>>>> You have 14 unapplied migration(s). Your project may not work properly >>>>> until you apply the migrations for app(s): admin, auth, contenttypes, >>>>> sessions. >>>>> Run 'python manage.py migrate' to apply them. >>>>> January 21, 2018 - 09:28:59 >>>>> Django version 2.0.1, using settings 'CalendarAlerts.settings' >>>>> Starting development server at http://127.0.0.1:8000/ >>>>> Quit the server with CTRL-BREAK. >>>>> Not Found: /catalog/ >>>>> [21/Jan/2018 09:29:13] "GET /catalog/ HTTP/1.1" 404 1971 >>>>> Not Found: /favicon.ico >>>>> [21/Jan/2018 09:29:13] "GET /favicon.ico HTTP/1.1" 404 1980 >>>>> >>>>> (CalendarAlert_env) >>>>> C:\Users\dnintzel\Documents\django_projects\CalendarAlerts>*python -m >>>>> django --version* >>>>> *2.0.1* >>>>> >>>>> (CalendarAlert_env) >>>>> C:\Users\dnintzel\Documents\django_projects\CalendarAlerts>python >>>>> --version >>>>> *Python 3.6.4* >>>>> >>>>> >>>>> Can someone help me understand why the new project is referencing the >>>>> old (and how to resolve)? >>>>> Is it related to the virtual environment? >>>>> >>>>> I am also interested in BKMs for use of virtual environments in this >>>>> case? Specifically, should Django need to be installed on each virtual >>>>> environment (if you don't have it installed globally?). I am actually a >>>>> little surprised that Django commands executed in the new project before >>>>> I >>>>> installed it in that VE. >>>>> >>>>> Thanks in advance, >>>>> Doug >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> 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/772985a8-537a-4cdb-8030-177262e44efd%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/django-users/772985a8-537a-4cdb-8030-177262e44efd%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>
-- 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 [email protected]. To post to this group, send email to [email protected]. 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/6af3710d-9ef7-42c0-9ffe-d3993b9fd491%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
