Setup static setting

[kellanjacobs]

We should setup the static setting and configure django to serve these static files during development.

[Belgand]

I'm uncertain what the issue is here. As far as I'm aware Django is currently configured to find, collect, and serve static files and is doing so (sitewide for the CSS and Noisebridge logo, and in the profiles app for the default avatar). Could you please provide some more information on what exactly isn't being performed or the flaws in the current implementation?

[kellanjacobs]

The idea is that we can set the STATIC_URL variable for use in our templates. I was going to set the variable and modify the templates to use it. There is more info here in the django docs. https://docs.djangoproject.com/en/dev/howto/static-files/

[Belgand]

It's set in line 64 of settings.py:

STATIC_URL = '/static/'

A quick check by me confirms that the STATIC_URL variable works as it should.

Currently in our templates we're only serving four static files:

In base.html: Two CSS files using the {% static %} template tag from staticfiles.

In style.css: A hardcoded path to /static/NB-logo-red-black-small.png

In display_avatar.html (itself just a testbed to work on avatars): As the output from the method call {{ profile.avatar.url }} which, for a default avatar is set to settings.STATIC_URL + "default-avatar.png". It should be using STATIC_ROOT, but as I recall that was giving me trouble displaying on the page.

So, to address your stated issues currently the variable is set and the templates are using it or the when necessary (and possible, unless there's a way to get it into the CSS) to serve static files. In light of this I'm closing the issue. Please reopen it if there's something I missed.

[kellanjacobs]

Hey Mark,

I went in and modified this code and the templates a bit. I set the urls to use the {{ STATIC_URL }} variable. I also changed the settings file to make it easier to pull these files.

As a side note I switched the order of the css files in the template. The normalize.css file sets some basics up then you use the style.css to make your custom changes. In the order they were would have the normalize file overwrite the style.css.

Kellan

On Tue, May 22, 2012 at 1:55 PM, Mark Smith < reply@reply.github.com

wrote:

It's set in line 64 of settings.py:

STATIC_URL = '/static/'

A quick check by me confirms that the STATIC_URL variable works as it should.

Currently in our templates we're only serving four static files:

In base.html: Two CSS files using the {% static %} template tag from staticfiles.

In style.css: A hardcoded path to /static/NB-logo-red-black-small.png

In display_avatar.html (itself just a testbed to work on avatars): As the output from the method call {{ profile.avatar.url }} which, for a default avatar is set to settings.STATIC_URL + "default-avatar.png". It should be using STATIC_ROOT, but as I recall that was giving me trouble displaying on the page.

So, to address your stated issues currently the variable is set and the templates are using it or the when necessary (and possible, unless there's a way to get it into the CSS) to serve static files. In light of this I'm closing the issue. Please reopen it if there's something I missed.

---

Reply to this email directly or view it on GitHub:

https://github.com/noisebridge/pyclass-project/issues/22#issuecomment-5858654

[Belgand]

Why use {{ STATIC_URL }} rather than the {% static %} template tag?

Some of the changes in settings were dumping a lot of files into the top level directory so I reverted them. I see how the intent was to make things easier in development, but I was actually relying on that functionality rather than just pulling everything from a hardcoded static/ directory. The template was also looking for a css directory that wasn't created and the static files never actually got moved so I put them back in and checked that they were being found properly.

[kellanjacobs]

Mark there are a couple of reasons that we should be using STATIC_URL. First it is common when you go live to move your static files to a different domain. There are several reasons to do so. Using the STATIC_URL variable will allow us to move static files with only changing one line in the settings file.

As far as users uploading avatars this should make use of the MEDIA_URL setting django provides. We need to separate user data from site data.

There are two more points. First when we talk about the difference between development and production. While there will need to be some things different in production and development we should not set things that can work in both production and dev differently. This is a vector to introduce bugs.

Lastly one of the advantages of python over the default php. Is that we do not execute code from the web root directory. Static urls is one helper for making this possible.

If I didn't move the CSS as you state above I think it would have been a better choice to move the CSS to the correct directory instead of revert the code. Or you could have opened this ticket back up and asked me to fix the code I wrote.

[Belgand]

I guess my confusion is because according to the docs {% static %} is essentially just doing a join with STATIC_URL. The main difference seems to be that the tag uses STATICFILES_STORAGE so it's easier to host them on cloud storage or a CDN. I understand why we want to handle static files from a variable, but since they seem very close to being equivalent I don't get why we'd want to use the variable rather than the tag.

For the uploads MEDIA_URL wasn't the problem. Without MEDIA_ROOT they were just going into /pyclass-project/ when uploaded, not media/ so it was no longer valid. The same issue was happening without STATIC_ROOT and this actually led to both user data and site data all going into the root directory.

When I said "revert" I was perhaps being a bit unclear. I don't mean an actual git revert, I just moved the files to the correct directory, and uncommented STATIC_ROOT and MEDIA_ROOT. Because this would be a conflict to store our static files in static/ and have them collected there as the root I moved the STATICFILES_DIRS to look into staticfiles/ instead.