I have a website done with Django, that was previously done with PHP and CodeIgniter. I've moved the website to Webfaction, changed the DNS and all other configurations, but now my email is full of errors like this:
Error (EXTERNAL IP): /index.php/main/leer/7497
I don't know why the Django app is looking for pages from the PHP app, specially since the PHP app was in another host.
Are those URLs from your old site? That's probably a case of people having stale bookmarks, trying to navigate to them, and getting 404s. You might want to consider catching those, and redirecting to the new URL with response code 302.
I can't imagine those errors are caused by Django (except in the sense that the reports are from Django reporting 404s, which it does for free).
I agree with above. Just want to add you should use django.contrib.redirects to move the redirects.
You can read more about it here
Related
When I develop Django websites, I always develop them on a server that sits on the Internet in order to mirror my production environment (I run macOS locally but my servers are Linux). During development I also will set DEBUG = True for debugging purposes. The problem is that if I or anyone else who's poking around on my site enters an invalid URLconf string, Django displays the "Page not found (404)" page along with all valid URL patterns, which I feel is a bit of a security risk. For example, my custom URL for the Django admin site is listed there. Is there a way to disable the showing of this specific error page when I have DEBUG set to True or perhaps to limit its display to particular IP addresses?
you can override the default 404 view.
Read here to know how to do
Good morning. I have a dedicated ubuntu server behind my company's firewall. It is using Django, Gunicorn, and Nginx to serve an Intranet application to employees. The original app responds to the URL [server_name]/[original_application_name]. I want to serve additional apps from this server. I have followed this tutorial as I did when setting up the original app.
I can run Gunicorn and serve the app, I have created a second systemd service file that appears steady (copied from the original app with paths changed - service runs), same for a new 'sites-available' file in Nginx (copied from original and modified), new .sock file exists, binding appears successful. However, I have yet to hit on the right configuration combination between settings.py [allowed_hosts], [new_app].service, and nginx etc.
The original app is running and when I try a URL related to the new app it gives an error saying it cannot find the request in the url.py of the original app. The new app would be used by the IT dept. Ideally, the new URL would be something like: it.[server_name]/[new_application_name].
I have looked through other cases with this problem but most use Apache or are on a public hosting site. I have seen this but it requires a "socket file". My original app is not using a socket file. I was hoping to do this without interfering with the original app. Is a "socket file" required? How can I configure this to serve both apps? Never having done this, what will the new URL be? The URL for the admin site in both apps is 'admin/', how can I accommodate this? Thanks!
I combined into one file as you suggested and I am almost there! I have original site responding at [server_name]/inventory and new site responding at [server_name]/assets. Great! My only problem is the admin page. In both apps the admin site is called admin! So, [server_name]/admin brings up the original site. How can I get to the new admin page?
Folks,
I am pretty sure I am not the first one to stumble on this problem. But somehow I am unable to find any relevant resources out there.
Here is my issue, I have a backend in Django and my front completely written in Reactjs- React Router - Redux (nice combo right).
when entering the url webhost.com/, django provides me with a page with links to a bundle that is my whole react application and different stylesheets
The problem arise when I want to refresh a page, the browser still tries to query the server even though a route exists in my react-router configuration.
I had a look at the answer here (catch-all option) React-router urls don't work when refreshing or writting manually , but I don't quite understand it and I am afraid to have a new redux state everytime Django will provide the user with a new page.
You can setup up a wildcard url pattern that will render the same view that gets rendered when a request is sent to webhost.com. I don't know if that's going to retain your store though.
I have a backbone.js single-page app that is all set up with the router (well, actually a Backbone.Marionette app with a Backbone.Marionette AppRouter, but nevertheless). However, the backend is based in Django, where I do not have the URL conf directing to views for all URLs that are already in the backbone.js routes.
Based on the existing URLs in the Django URL conf, Backbone.js will serve the backbone routes regardless of what is listed in the Django conf - it seems something, anything just needs to be there.
Do I need to have proper Django views in order to offer a fallback for older browsers/SEO?
What are the best practices to coordinate the Django URL conf and the Backbone.js Router?
I've found a post that addresses this issue quite well:
http://duganchen.ca/single-page-web-app-architecture-done-right/
Briefly, my reasoning for including a fallback is for non-javascript browsers and SEO reasons. At the time of this post, non-javascript browsers account for ~1.4% (less than 2% from everything I've read) of users, making SEO The major consideration. Again, SEO may not be relevant for everyone reading this post, in which case, this can be skipped.
I found Thomas Davis' tutorial using phantom.js quite helpful. http://backbonetutorials.com/seo-for-single-page-apps/
However, another issue that I needed to account for was the history API, which has been neglected by all but the latest IE browsers. Given my client's users, about 15% of which are using IE <= 9, this was also a problem.
In the end, I also needed to use history.js. All in all, this was a lot of work to update an otherwise very simple website. However, I learned a lot from this ordeal.
In my opinion if your backbone app is truly a single page then you don't need any django views whatsoever. You can serve your index.html as a static file (in production, not even by django) and then let backbone's router take care of your url configuration, as you're doing already. You can use backbone's history and navigate to fake urls, add urls parameters etc, for resources in your app.
I have got a blog in wordpress (www.ashwinm.com) which i am looking to migrate to django as i am very much impressed with it. Is there any way so that i can migrate to django without losing my current pagerank (which is 3)?
I don't mind losing all current contents of this blog as it is too old.
You could take a look at something like django-wordpress. That would allow you to keep your current content in the existing wordpress DB (read-only) and continue to develop other portions of the site with Django.
If you have a high pagerank, that is probably because you have content and the content is linked to by other people. You should try to keep that content in some form (it doesn't have to be exactly the same form), or at least ensure that every URL that is being linked to redirects to something useful. No one who follows a previously valid link to your website should get a 404.
Your content and your inbound links together are responsible for your pagerank, so if you let both die then you're back at square one, regardless of what web application framework you are using.
If I were doing it I would probably set up the new blog with Django and import the data manually. Or, if there is simply way too much data, I could move the Wordpress server to be served from a directory such as /archive and instruct my webserver to 301 redirect all of the old Wordpress blog entry URLs to the new directory. You would have to continue to maintain the Wordpress installation to some degree, but you would be 100% certain to keep all of your pagerank.