Develop Reference

Django setting debug=False breaks href links

I am developing a website using Django framework. It works perfectly well using Django=True, however when I set Django=False, system could not find the other html files which are being accessed in <a href=... links.
Let say, I am developing 'mysite', then the following code:
<li><i class="fab fa-dribbble"></i></li>
is present behind an icon on mysite. Then clicking the icon takes the user to 'mysite.com/index-2.html', however it throws "The requested resource was not found on this server" error.
And this happens only when we set Django=False and in production. No link on the homepage is working due to this.
EDIT-1:
I've already reviewed:
Why does DEBUG=False setting make my django Static Files Access fail?
The static files are already working fine on my app because they are in 'assets' folder. The html files are in the root folder and somehow system is not able to find any file from root folder when debug is set to False. So my question is more regarding finding files at root folder using href links.
No error for files in 'assets' folder, but 404 for root folder files:

try using onclick function instead of href
and In static files you have add some configration to serve the static files in django.
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
STATIC_URL = '/static/'
#STATIC_ROOT = os.path.join(BASE_DIR, 'static/')
# add manual
STATICFILES_DIRS = [
os.path.join(BASE_DIR, 'static')
]
MEDIA_ROOT = os.path.join(BASE_DIR,'static/images/')
MESSAGE_TAGS = {
messages.ERROR: 'danger'
}
if this is work please contact me , I found this from freelance app

To resolve this, I added specific functions for each of the .html files in views.py file and added link of the function to main html file.
For example:
I added following to my views.py file:
def about(request):
return render(request,'about.html')
and used as follows in index.html:
href = '\about'
Doing this for all used html files resolved the issue for both debug=True and debug=False. Not sure if this is the best way but working for now.

Django STATIC_URL always points to local directory

I want to serve the static content generated by django in a different host with nginx.
The server with the files has the name 'static-server' and I can't access it with django.
The static file looks like this:
STATIC_URL = 'http://static-server/static/'
But the error log gives the following path:
"GET /http:/static-server/static/admin/css/base.css HTTP/1.1" 500 145
Why is django looking for the files in local? How can I avoid this?

Long story short, STATIC_URL cannot point to remote directories without the use of extra plugins.
If you want to serve static content generated by Django with another web server (ie: Nginx) it must be in the same host.

Serving static files from root of Django development server

My goal is to have an Angular project being served from the root of my development server. The files will be completely static as far as Django is concerned, no Django template processing is needed. The angular project will then make resource calls to a Django project located at /api/ on the same development server, which will then return json results generated from a view for the Angular project to process.
I assumed it would be as easy as adding the following to my urls.py file.
url(r'^/', 'django.views.static.serve', {
'document_root':'/Users/kyle/Development/project/site/app',
}),
Or
+ static("^/$", document_root="/Users/kyle/Development/project/site/app")
To the end of the urlpatterns.
With /project/site/app being the directory with the Angularjs files.
However, both of these leave me with 404 errors.
I'm open to changing the structure of the project if a more obvious solution exists.

You need to serve both index.html and your static files on / which is done like this in Django 1.10:
from django.contrib.staticfiles.views import serve
from django.views.generic import RedirectView
urlpatterns = [
# / routes to index.html
url(r'^$', serve,
kwargs={'path': 'index.html'}),
# static files (*.css, *.js, *.jpg etc.) served on /
url(r'^(?!/static/.*)(?P<path>.*\..*)$',
RedirectView.as_view(url='/static/%(path)s')),
]
See this answer where I wrote a more complete explanation of such a configuration – especially if you want to use it for production.

It turned out that it was a combination of 2 things, as shavenwarthog said, it shouldn't have the slash. Also, it needed a regular expression to direct it to the file. The final line ended up being:
url(r'^(?P<path>.*)$', 'django.views.static.serve', {
'document_root':'/Users/kyle/Development/project/site/app',
}),
I can then access files like
http://localhost/beer.jpg

note that by default Django won't serve a directory listing. Do you still get a 404 if file /Users/kyle/Development/project/site/app/beer.jpg doesn't appear as http://localhost/beer.jpg ?
in urls.py URLs don't start with a slash; compare url(r'beer') with url(r'^/beer')
I suggest just going for the standard STATIC support. It's awkward, but lets you serve file simply during development, and switch to a 3rd party server (ie Nginx) for production:
https://docs.djangoproject.com/en/dev/howto/static-files/

Django: Serving admin media files

I am trying to serve static files from another domain (sub domain of current domain).
To serve all media files I used this settings:
MEDIA_URL =
'http://media.bud-inform.co.ua/'
So when in template I used
{{ MEDIA_URL }}
it was replace with the setting above. Now I am trying to serve admin media files from the same subdomain, I changed the settings this way:
ADMIN_MEDIA_PREFIX =
'http://media.bud-inform.co.ua/admin_media/',
and expected that all calls to media from my admin site will be made to this url.... But actually it didn't work this way, I still see paths to CSS made as following:
http://bud-inform.co.ua/media/css/login.css
Could you suggest how to serve admin media files correctly

MEDIA_URL and ADMIN_MEDIA_PREFIX are two different things. One is the location of your media files, while the other is the location of the django admin system's media files.
You have to make sure that the ADMIN_MEDIA_PREFIX points to somewhere where you're actually serving the admin media. Django doesn't handle that step for you.
The django admin media is at django/contrib/admin/media/. Copy or symlink that directory somewhere publicly visible and set ADMIN_MEDIA_PREFIX to reflect where you put it.

Django "SuspiciousOperation" Error While Deleting Uploaded File

I'm developing in Django on Windows XP using the manage.py runserver command to serve files. Apache isn't involved. When I login to the administration and try to delete a file I get a "SuspiciousOperation" error.
Here's the traceback:
http://dpaste.com/123112/
Here's my full model:
http://dpaste.com/hold/123110/
How can I get rid of this "SuspiciousOperation" error?
EDIT: Here are my media settings:
MEDIA_ROOT = 'C:/Server/Projects/postnzb/static/'
MEDIA_URL = '/static/'

What is your MEDIA_ROOT in settings.py? From the back-trace, it seems you have set your MEDIA_ROOT to /static/.
This error is coming since Django is trying to access /static/ to which it has no access. Put an absolute pathname for MEDIA_ROOT like C:/Documents/static/ and give full permissions to Django to access that directory.
That should solve your problem.
Addendum: Since your MEDIA_ROOT seems to be OK, I am guessing that you are using MEDIA_URL for deleting the file instead of MEDIA_ROOT. Indeed, from the error it seems that Django was trying to access the /static/files/8.nzb and was denied access. Clearly, /static/ is your MEDIA_URL and not your MEDIA_ROOT. The model methods should never try accessing the files using the MEDIA_URL. I am sure a review of your code will spot the error.
Update: I skimmed your code and it seems you are setting File.nzb to %(1)sfiles/%(2)s.nzb' % {'1': settings.MEDIA_URL, '2': self.pk} which uses its MEDIA_URL and then in the delete() method you are calling the delete() method of the super-class of File as super(File, self).delete() which is obviously wrong as it will try deleting File.nzb and will try accessing the file through the MEDIA_URL. Fixing that will get rid of the error. I will leave the exact solution as an exercise to you :)