@Ariel - I'm still learning github, but the pull request seems straightforward. I have a fork up there, but my settings.py is quite a bit different. Since we are using the sites framework I use a multiple settings files. One short one for each site, which sets SITE_ID, SITE_NAME, INSTALLED_APPS, and others, it then pulls in a globals setting file, then pulls in local settings for development overrides.
@David - I'm only suggesting that the default GEONODE_CLIENT_LOCATION be based off of STATIC_URL, or at the very least that a comment be added that unless you are running a separate webserver for JS development, that GEONODE_CLIENT_LOCATION needs to under one of the existing served directories (media, admin, or static) for a development environment. Although I admit my error was avoidable and I should have paid better attention, it would have saved me a bit of time if there was better explanation or it had defaulted to a location under STATIC_URL. On Thu, Feb 16, 2012 at 10:00 AM, David Winslow <[email protected]> wrote: > Actually a common use case (the reason we have GEONODE_CLIENT_LOCATION at > all) is to run a separate server for the geonode client scripts. In the > client project (which I'm working on making a subdirectory of the main > project instead of an independent repository) you can use: > > $ ant debug > > to fire up a web server with scripts set up at the same places as the > minified ones, which will instead make the page reference the original > sources. As you may imagine, this is useful for debugging, especially since > changes to the sources will be reflected immediately rather than requiring a > rebuild. > > A check that the GEONODE_CLIENT_LOCATION is local to the development server > would be a problem for those JavaScript developers. > > > On Thu, Feb 16, 2012 at 9:38 AM, Matthew Hanson > <[email protected]> wrote: >> >> Of course, right when I start thinking it was a bug I should have >> immediately suspected it was my own fault. And also the lack of >> responses here should have clued me in that, since no one seemed to >> have any idea what I was talking about, that it was not a problem with >> GeoNode. Since I hate finding threads with problems that never get >> resolved in the thread.... >> >> I had been trying different settings and got parameters mixed up. I >> was right about the expected behavior. The dev server takes the >> STATIC_URL and publishes STATIC_ROOT and STATICFILES_DIRS locations to >> that URL. There's no settings elsewhere like I had thought (I'm >> still confused as to what egg the egg:GeoNode is referring to in >> shared/dev-paste.ini....there's no egg with that name). Ariel's >> post had a clue as to the problem, but the source of the problem is in >> the original GeoNode settings.py file and really should be changed. >> >> # GeoNode default settings.py has these two variables, far away from >> each other in the settings.py file. >> STATIC_URL = "/media/" >> GEONODE_CLIENT_LOCATION = "/media/static/" >> >> Ariel stated: >> >> >>> STATIC_* are for things like css and js >> >>> GEONODE_CLIENT_URL is just there to be able to point to a development >> >>> version of geonode-client, usually maps to a place under STATIC_URL. >> >> However, for the dev version in fact GEONODE_CLIENT_URL *has* to map >> to a place under STATIC_URL...or at least some location that will be >> auto-shared by the dev server. Presumably this could be media, or >> admin, since those are served as well. The default settings.py >> should be updated to be like Ariel's. I'd also suggest moving them >> so STATIC_URL and GEONODE_CLIENT_URL are next to each other in >> settings.py >> >> STATIC_URL = '/media/' >> GEONODE_CLIENT_LOCATION = STATIC_URL + "static/" >> >> which will ensure that the GEONODE_CLIENT_LOCATION is properly served >> by the dev server. Otherwise if you change STATIC_URL without also >> updating GEONODE_CLIENT_LOCATION those client js and css files will >> become orphans. >> >> >> - m >> >> >> >> On Thu, Feb 16, 2012 at 7:57 AM, Matthew Hanson >> <[email protected]> wrote: >> > I think this is a bug. When using the default settings.py, the >> > development environment runs fine. >> > >> > If I change STATIC_URL, nothing else, it doesn't serve static files >> > when starting the server. >> > >> > I think it's a bug, but I don't know what the intended behavior is. >> > I'd think that the dev server should read the settings module, then >> > serve the static directoriess to whatever URL is specified in >> > STATIC_URL, so no matter what STATIC_URL is it should work. >> > >> > matt >> > >> > >> > On Wed, Feb 15, 2012 at 3:56 PM, Matthew Hanson >> > <[email protected]> wrote: >> >> Ariel thanks a lot, >> >> >> >> I think I mostly understand Django's media handling, as I've used >> >> Django prior to GeoNode, and don't have a problem with production >> >> deployment. What I'm having a hard time with now is serving the >> >> static files in the development environment. Now to be clear, I can >> >> serve static files fine using the default setting for STATIC_URL. >> >> But if I change STATIC_URL to anything else, it fails to work. Even >> >> if I just add a prefix of http://localhost:8000/ it fails to work. >> >> (in production we may be serving static files from a different >> >> machine) >> >> >> >> STATIC_URL = '/media/' # original setting, works fine >> >> >> >> STATIC_URL = '/static/' # fails >> >> STATIC_URL = 'http://localhost:8000/static/ # fails >> >> >> >> The paster host seems to be set up to serve files at the original >> >> setting location (/media/), and I can't find where to change it. Or >> >> maybe there's something else going on here. >> >> >> >> I also see you included this in your settings: >> >> >> >> STATICFILES_STORAGE = 'staticfiles.storage.StaticFilesStorage' >> >> >> >> which was removed from the settings file in 1.1 Is it required ? >> >> >> >> The relevant section of my settings file is pasted here, and it's >> >> currently configured to work properly, but I would like to change the >> >> names of some directories as well as be able to add an ASSETS_URL >> >> prefix (to point to a different machine) >> >> >> >> >> >> ########################################################### >> >> # Locations of things >> >> ########################################################### >> >> >> >> # Assets include media, static, admin, etc - any static resources >> >> ASSETS_ROOT = os.path.join(PROJECT_ROOT,'media/') #'/var/www/geonode/' >> >> #ASSETS_URL = 'http://localhost:8000/media/' >> >> ASSETS_URL = "/media/" >> >> >> >> # Absolute path to the directory that holds media. >> >> # Example: "/home/media/media.lawrence.com/" >> >> MEDIA_ROOT = os.path.join(ASSETS_ROOT,'media/') >> >> # trailing slash if there is a path component (optional in other >> >> cases). >> >> # Examples: "http://media.lawrence.com";, "http://example.com/media/"; >> >> MEDIA_URL = ASSETS_URL + 'media/' >> >> GEONODE_UPLOAD_PATH = MEDIA_ROOT >> >> >> >> # Absolute path to the directory that holds static files like app >> >> media. >> >> # Example: "/home/media/media.lawrence.com/apps/" >> >> STATIC_ROOT = os.path.join(ASSETS_ROOT,'static/') >> >> # Additional directories which hold static files >> >> STATICFILES_DIRS = ( >> >> os.path.join(PROJECT_ROOT, 'media'), >> >> ) >> >> # URL that handles the static files like app media. >> >> # Example: "http://media.lawrence.com"; >> >> #STATIC_URL = ASSETS_URL + 'static/' >> >> STATIC_URL = '/media/' >> >> GEONODE_CLIENT_LOCATION = STATIC_URL + "static/" >> >> >> >> # URL prefix for admin media -- CSS, JavaScript and images. Make sure >> >> to use a >> >> # trailing slash. >> >> # Examples: "http://foo.com/media/";, "/media/". >> >> ADMIN_MEDIA_PREFIX = os.path.join(ASSETS_URL,'admin/') >> >> >> >> >> >> On Wed, Feb 15, 2012 at 3:09 PM, Ariel Nunez <[email protected]> >> >> wrote: >> >>> Mathew, >> >>> >> >>> I understand how daunting media handling is for Django and especially >> >>> in GeoNode with the additional GEONODE_CLIENT_LOCATION, there is a >> >>> reason for each of those settings but I won't go in detail now (can >> >>> provide links later if needed). >> >>> >> >>> Here is how I configure the settings file in my development projects >> >>> so they are development and production friendly: >> >>> >> >>> MEDIA_ROOT = os.path.join(PROJECT_ROOT, 'static', 'uploaded') >> >>> >> >>> MEDIA_URL = '/uploaded/' >> >>> STATIC_ROOT = os.path.join(PROJECT_ROOT, 'static') >> >>> STATIC_URL = '/static/' >> >>> GEONODE_UPLOAD_PATH = MEDIA_ROOT + 'geonode' >> >>> #GEONODE_CLIENT_LOCATION = 'http://localhost:8080/' >> >>> GEONODE_CLIENT_LOCATION = STATIC_URL + 'geonode/' >> >>> ADMIN_MEDIA_PREFIX = STATIC_URL + 'admin/' >> >>> >> >>> STATICFILES_STORAGE = 'staticfiles.storage.StaticFilesStorage' >> >>> >> >>> # Additional directories which hold static files >> >>> STATICFILES_DIRS = [ >> >>> os.path.join(PROJECT_ROOT, 'media'), >> >>> os.path.join(GEONODE_ROOT, "media"), >> >>> ] >> >>> >> >>> # URL prefix for admin media -- CSS, JavaScript and images. Make sure >> >>> to use a >> >>> # trailing slash. >> >>> # Examples: "http://foo.com/media/";, "/media/". >> >>> ADMIN_MEDIA_PREFIX = os.path.join(STATIC_URL, "admin/") >> >>> >> >>> >> >>> For deployment you need to use the: `geonode collectstatic` static >> >>> command (pass it a -v0 flag if you have an error related to printing) >> >>> and that will take care of putting the static files in the right dir >> >>> (usually /var/www/geonode/static ). >> >>> >> >>> MEDIA_* are for user submitted files >> >>> STATIC_* are for things like css and js >> >>> GEONODE_CLIENT_URL is just there to be able to point to a development >> >>> version of geonode-client, usually maps to a place under STATIC_URL. >> >>> >> >>> In my urls.py I do: >> >>> >> >>> from staticfiles.urls import staticfiles_urlpatterns >> >>> >> >>> # Extra static file endpoint for development use >> >>> if settings.SERVE_MEDIA: >> >>> urlpatterns += >> >>> [url(r'^static/thumbs/(?P<path>.*)$','django.views.static.serve',{ >> >>> 'document_root' : settings.STATIC_ROOT + "/thumbs" >> >>> })] >> >>> urlpatterns += >> >>> [url(r'^uploaded/(?P<path>.*)$','django.views.static.serve',{ >> >>> 'document_root' : settings.MEDIA_ROOT >> >>> })] >> >>> >> >>> urlpatterns += staticfiles_urlpatterns() >> >>> >> >>> Hope it helps, >> >>> Ariel. >> >>> >> >>> On Wed, Feb 15, 2012 at 1:18 PM, Matthew Hanson >> >>> <[email protected]> wrote: >> >>>> Hello there, >> >>>> >> >>>> We've been starting to work with GeoNode here, and this is my first >> >>>> post, although I met some of you at FOSS4G this year. I'd introduce >> >>>> our project, but right now there is no public site. We're using >> >>>> GeoNode in a multi-site configuration, which means utilizing the >> >>>> Django Sites framework and tweaking GeoNode to use it. I've got a >> >>>> basic multi-site config running in Production on Apache, and am >> >>>> trying >> >>>> to get my development environment matched up, however paster, and >> >>>> static and media URL's are giving me some heartburn (I'm using >> >>>> family-friendly language here). >> >>>> >> >>>> The plethora of file location variables is rather daunting: >> >>>> STATIC_URL, STATICFILES_DIR, MEDIA_URL, GEONODE_CLIENT_LOC, ADMIN, >> >>>> etc. and certainly has caused me lots of confusion. The problem I >> >>>> was having is when I changed STATIC_URL, my development server was >> >>>> unable to find the static files. With Apache I've got no problem as >> >>>> it's easy enough to change to whatever I wish. But with paster I'm >> >>>> unable to make any sense out of the shared/dev-paste.ini file. The >> >>>> syntax in it doesn't match up with the paster online documentation. >> >>>> To be more specific, the app:static config block doesn't set >> >>>> document_root like the documentation says must be provided. It >> >>>> instead gives >> >>>> >> >>>> egg=GeoNode >> >>>> resource_name=GeoNode/static >> >>>> >> >>>> There's reference to resource_name in paste.urlparser, but no >> >>>> examples >> >>>> of a configuration file using the syntax above. Obviously paster is >> >>>> setting the server settings somewhere, but I can't for the life of me >> >>>> figure out where. I just want to be able to change some of my >> >>>> settings variables for locations of things, but seems like the >> >>>> development environment has hardcoded some things somewhere. >> >>>> >> >>>> Any insight? >> >>>> >> >>>> Thanks in advance, >> >>>> >> >>>> Matthew Hanson >> >>>> Applied GeoSolutions >> >>>> http://www.appliedgeosolutions.com > >
