Closed bernd-wechner closed 3 years ago
bernd-wechner
commented
3 years ago Still stuck on this. It was working so well until just recently, now some JS issue on live site only, and I can't find any differences yet in the live and dev site includes and sources or code delivered. Must be there somewhere. And smells like failed or double load of JQuery problem.
bernd-wechner
commented
3 years ago More diagnostics.
These code snippets:
context['Django_source'] = django.__spec__.origin # @UndefinedVariable
context['Django_version'] = django.__version__
context['DAL_source'] = dal.__spec__.origin # @UndefinedVariable
context['DAL_version'] = get_distribution("django-autocomplete-light").version <pre id="version_debug_info">
Django source: {{ Django_source }}
Django version: {{ Django_version }}
DAL source: {{ DAL_source }}
DAL version: {{ DAL_version }}
</pre>
<script>
const v1 = jQuery.fn.jquery;
const v2 = $().jquery;
const e = document.getElementById("version_debug_info");
e.innerText = e.innerText + "JQuery fn version: " + v1 + "\n\tJQuery $ version: " + v2;
</script>Yield identical output on my page, on the functional (dev) and dysfunctional (live) sites (bar the source paths as the venv is in a different spot)
Django source: /data/venv/CoGs/lib/python3.8/site-packages/django/__init__.py
Django version: 3.1.7
DAL source: /data/venv/CoGs/lib/python3.8/site-packages/dal/__init__.py
DAL version: 3.8.2
JQuery fn version: 3.3.1
JQuery $ version: 3.3.1This snippet in settings.py
log.debug(f"Django settings: {'Live' if SITE_IS_LIVE else 'Development'} Server")
log.debug(f"Django version: {django.__version__}")
log.debug(f"Django loaded from: {django.__file__}")
log.debug(f"Using Path: {sys.path}")
log.debug(f"Process Info: {pinfo()}")
log.debug(f"Static root: {STATIC_ROOT}")
log.debug(f"Static file dirs: {locals().get('STATICFILES_DIRS', globals().get('STATICFILES_DIRS', []))}")
log.debug(f"Debug: {DEBUG}")produces for the live site:
Django settings: Live Server
Django version: 3.1.7
Django loaded from: /data/venv/CoGs/lib/python3.8/site-packages/django/__init__.py
Using Path: ['.', '', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/data/venv/CoGs/lib/python3.8/site-packages', '/home/sting/.local/lib/python3.8/site-packages', '/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages']
Process Info: {'Me': "pid=1653007, name=uwsgi, commandline=['/usr/bin/uwsgi', '--ini', '/usr/share/uwsgi/conf/default.ini', '--ini', '/etc/uwsgi/apps-enabled/leaderboard.space.ini', '--daemonize', '/var/log/uwsgi/app/leaderboard.space.log'], started=1617543085.49", 'My Parent': "pid=1, name=systemd, commandline=['/lib/systemd/systemd', '--system', '--deserialize', '31'], started=1605235057.38"}
Static root: /data/www/leaderboard.space/static/
Static file dirs: []
Debug: TrueAnd similar on the Development site, with local filesystem differences.
The symptoms are that I have a DAL widget that rends like this on the Development machine:
and if I click in the white box I get a drop down, correctly populated by a callback. (i.e. it works as it has for eyars and is fine). The console is clear on the browser. On the live site as of this weekend (with unknown changes causing it) I see this:
And this on the console:
select2.js:5 Uncaught TypeError: $ is not a function
at select2.js:5
at select2.js:122and select2.js is found at:
https://my.site/static/autocomplete_light/select2.js
as revealed in the browser debugger hovering over the above message.
All these diags so far are barking up the wrong tree I worry. And I am still clueless as to cause.
bernd-wechner
commented
3 years ago Aaargh, am pulling my hair out here. Have salvaged a path forwards but still don't understand it. Single stepping JS code on the live site I find yl.JQuery is never defined. I see if it defined in jquery.init.js so I add this to the template:
<script src="/static/autocomplete_light/jquery.init.js"></script>and suddenly all works again.
Digging deeper, I found that something did go wrong with collectstatic. The file select2.js was different between the two servers. I cleaned static and collected again and all came good once more.
Oh the hours that cost me!
gamesbook
commented
3 years ago Digging deeper, I found that something did go wrong with collectstatic.
How is this possible? collectstatic is a well-established Django function that has been running for years.
bernd-wechner
commented
3 years ago No idea. Hard to diagnose ... I run a script to publish for dev to live, and it stops copies across the site code, then runs collectstatic and reloads uwsgi. Been working fine for a long time.
My best theory (and it is but a theory), is that somehow somewhen, I did something kludgy by hand (put a wrong file in /staticautocomplete_light/select2.js - and this is one heck of a tenuous theory as I cannot for love or money imagine ever doing something so bizarre and esoteric) and collectstatic I was not using with --clean and so it wasn't copying the right select2.js into static. In short one manual error is preserved by collectstatic.
So my fix now has been to put --clean in the publish script when it runs collectstatic and all seems well. Did some tests, by hand to confirm behaviours and pretty happy.
I have one odd behaviour (that I sort of like but haven't found documented anywhere). I keep images (icons and such), javascript source, and css files in an app folder in a fairly prosaic layout:
app\static
css
img
jsAnd the file in img and only those, end up the /static folder after a collectstatic (as well as under static\app\img). So I'm not convinced I've found the definitive documentation on collectstatic yet though I've read a lot ;-). I might even dig into its code at some point (that of colectstatic).
It's certainly been reliable yes for years. Hence my tenuous theory, of some manual miscopy of a select.js file that was subsequently respected by collectstatic without --clean. That manual glitch must have happened in the last month or so (as data entry is a monthly routine on it currently and happened last month with working forms).
But yes, when I said "something did go wrong with collectstatic" I did mean in fact with my use of it, rather than with its code (which is indeed mature, stable and in the venv site-packages folder).
For reference:
Has worked fine forever, just topped wotking and I'm stuck working out what change may have caused this. Unfortunately the nature of the problem is hard to apply change detection to, mainly because of poor publishing practices (which I'll look into fixing). You see it works fine on in the dev environment under runserver, but not when published to a live server.
When I load my page I get one single console error:
There are also two identical warnings (as I have two DAL widgets on this page I guess):
The header of the page renders in code as:
The message looks familiar and suggests to me JQuery hasn't loaded or loaded twice ... but I find no evidence of that.
Aside from solving the problem, what I'm for is to learn better how to interpret it and assess the cause if possible.
This has killed my website alas. So I'll double down and try rollbacks to see what happens, but alas it's a pre-beta site (albeit in use as an alpha) and so robust backup systems aren't in place yet. Oh well.
The mystery I have is that I can load this page under runserver on a development machine and it renders fine, published live it does not. And a context diff between he two rendered pages has no significant differences:
Same results in same browser, and also browser independent. Something has broken on the live site, that I am having seriously trouble understanding and yet it seems to be pure Javascript issues, and identical Javascript.
I even did a meld on the static directory under runserver and on the live side, and they are identical, and I run collectstatic as I always have on each side sensibly.