Closed GibbsConsulting closed 4 years ago
Hi, do you guys have anyone that could do consulting for an hour? I am losing too much time. This isn't in prod. The data is fake. This is just a matter of getting functionality up to par.
I literally only need someone to set up the dbc part so I can import it and then do dbc.button or whatever in the app. That is the only business requirement- to allow me to use bootstrapped buttons in the app. This is slowing down EVERYTHING. Someone experienced can knock this out quickly I presume since this is a config only problem
HTTP GET /django_plotly_dash/app/test/_dash-component-suites/dash_bootstrap_components/_components/dash_bootstrap_components.v0_9_0m1585057943.min.js 302 [0.01, 127.0.0.1:49797] HTTP GET /static/dash/component/dash_bootstrap_components/_components/dash_bootstrap_components.min.js 404 [0.01, 127.0.0.1:49797] HTTP GET /django_plotly_dash/app/test/_dash-layout 200 [0.23, 127.0.0.1:49797] HTTP GET /django_plotly_dash/app/test/_dash-dependencies 200 [0.31, 127.0.0.1:49770]
I need these 404 and 302 errors to go away. If this problem doesn't go away soon then I have to gut this process and using a diff tech stack for work.
We do offer consulting here - generally on longer timescales - but hopefully we can fix up this issue without having to resort to it.
The 302 is not an error; this is a redirection (from the dash-app-instance specific URL to a shared one for the asset).
The 404 is an error and it is saying that the file is not being served up by whatever is handling static files for your Django setup. Assuming that collectstatic has been run, the file should be under STATIC_ROOT
along with all the other static assets. If it is not there, and there is no error when running collectstatic, then there is a (nonobvious) settings issue.
On the other hand, if it is there, then your static files are not being served properly; this will depend on your Django setup. We find whitenoise to be useful, at least during development.
Did this get resolved? I am getting the same 404 error when adding django-bootstrap components to my app: "HTTP GET /static/dash/component/dash_bootstrap_components/_components/dash_bootstrap_components.min.js 404". I have run collectstatic (without any errors), but the "dash_bootstrap_components.min.js" file is not present in the static folder.
The app just displays a completely blank page when I add the dbc's - even the regular html divs disappear. I posted about this on SO, but so far without much luck (see e.g. https://stackoverflow.com/questions/61259045/django-plotly-dash-application-returning-completely-blank-page-when-using-django).
django-plotly-dash is pretty rad, by the way : )
@geilfeldt if you've run collectstatic, but don't have this file in the static folder, then the first thing to check is that everything is configured correctly. In particular, make sure that all of the steps have been followed including PLOTLY_COMPONENTS
and middleware.
I believe I've done everything stipulated in the docs (https://django-plotly-dash.readthedocs.io/en/latest/installation.html). Indeed, everything else works fine - only the dbc's can't be loaded. "dash_bootstrap_components.min.js" is not in the static folder, but just at "[MY_ENV]\Lib\site-packages\dash_bootstrap_components_components\dash_bootstrap_components.min.js".
I've pasted in the relevant parts of settings.py below.
INSTALLED_APPS = [
'django_plotly_dash.apps.DjangoPlotlyDashConfig',
'channels',
'dpd_static_support',
'test_app.apps.TestAppConfig',
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]
MIDDLEWARE = [
'django_plotly_dash.middleware.BaseMiddleware',
'django_plotly_dash.middleware.ExternalRedirectionMiddleware',
'whitenoise.middleware.WhiteNoiseMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
X_FRAME_OPTIONS = 'SAMEORIGIN'
CHANNEL_LAYERS = {
'default': {
'BACKEND': 'channels_redis.core.RedisChannelLayer',
'CONFIG': {
'hosts': [('127.0.0.1', 6379),],
},
},
}
Can you try adding bootstrap4
to INSTALLED_APPS
(installing django-bootstrap4 if you don't already have it) and then check also your PLOTLY_COMPONENTS
setting?
That did the trick! Well, almost.
I added bootstrap4
to INSTALLED APPS
, added dash_bootstrap_components
to PLOTLY_COMPONENTS
, and django_plotly_dash.finders.DashAppDirectoryFinder
to STATICFILES_FINDERS
. That made collectstatic
copy the right files to the static folder (as specified by STATIC_ROOT
). The components would only render however, when os.path.join(BASE_DIR, "static")
was included in the STATICFILES_DIRS
list and the STATIC_ROOT
varible was removed. Quite strange.
So now there are no more 404's, and the components are rendering. However, the external_stylesheets
option - which was my main reason for using dash-bootstrap in the first place - seems to be entirely ignored. Whether using an absolute path like external_stylesheets= ["https://stackpath.bootstrapcdn.com/bootswatch/4.4.1/cyborg/bootstrap.min.css"]
or one of the references provided by dash-boostrap-componenets like external_stylesheets=[dbc.themes.CYBORG]
, the themes don't seem to be applied to the app. As long as add_bootstrap_links=True
, the components just get a vanilla bootstrap theme. Upon inspection, the only boostrap-related thing I can find in the html that the app generates is this: django_plotly_dash/app/pie_app/_dash-component-suites/dash_bootstrap_components/_components/dash_bootstrap_components.v0_9_2m1586721990.min.js
. And it is there whether add_bootstrap_links=True
or not.
Am I missing something obvious here?
Documentation updated in #255 and released as version 1.4.1
The external_stylesheets option isn't working in my code either. Did u find any solution @geilfeldt
Using the
add_bootstrap_links
parameter, whilst suboptimal and not regarded as a permanent solution, is not that well documented and leads to confusion - more than one user has raised issues over this.Task: improve the documentation, ideally with an example, to make use of the parameter more obvious.