[Expo-tech] Expo Survex listings page fixed and changed

Thu Mar 25 20:36:03 GMT 2021

In fixing lots of dead links, I have changed a small thing which I hope you will not object to.

See http://expo.survex.com/survexfile/2017-cucc-28

In all the survex files for a complex cave which has subfolders,

I have changed the label in the left column from the name of the first survex file, to the name of the folder itself.

So now under 161, the left-hand column has entries such as

·         france

·         triassic

·         phumour

instead of previously where it was:

·         allfr

·         alltrias

·         allphs

which I think is more obvious. See http://expo.survex.com/survexfile/caves/ live now.

This change is particularly useful for those caves where there is a /cucc/ or /arge/ subdirectory containing earlier versions of the same surveys with the same names, e.g. for 115, 144 and 142.

The other change is that all the caves without kataster names e.g. 2017-cucc-24 <http://expo.survex.com/survexfile/2017-cucc-24>  now link to the right set of survex files instead of crashing horribly. I just made it look for an unofficial number if it couldn’t find the official one. Exception handling is a wonderful thing.

So now this page http://expo.survex.com/survexfile/caves/ is useful in an earlier stage of our process:  before the kataster number has been issued, and also after it has been issued but before someone gets around to go in and rearrange all the folders to match (which takes years, though it shouldn’t).

You can now click away with wild abandon on this page without anything horrible happening.

(Shagged-spit Hohle needs attention though)

It’s all part of trying to make troggle a useful tool to help us in getting things consistent, rather than a fragile beast that only works if we have already entered the data in precisely the correct manner.

Next jobs: make it work with anything other than 1623 and fix the CSRF security editing issue.

From: Philip Sargent [Gmail] [mailto:philip.sargent at gmail.com] 
Sent: 18 March 2021 22:03
To: 'Expo Nerding'
Subject: the fossil bits of JavaScript in expo troggle: JSLIB_URL

OK expo website people. I am starting on the 10-15 pages of faults and glitches and whatnot that should be done on the expo website software.

Who knows anything about the fossil bits of JavaScript that used to be accessed at http://expo.survex.com/javascript/...  which is configured in the Apache config and also the Django JSLIB_URL constant, but which point to various jquery things which are not in any of the repositories and are not on the server either – and so not actually loaded or used.

Simplest example:

javascript/jquery-form/jquery.form.min.js  

used to be imported into pages showing a survex file, e.g. 

http://expo.survex.com/survexfile/caves-1623/107/antigrav.svx 

but the import currently fails. But the HTML page seems to work fine!  This is the survex file online display & edit page.

So what was it meant to do, so what functionality is invisibly missing ?

The import of JSLIB_URL/codemirror/codemirror.min.js in the same page also fails. I presume this is a better editor, and may even have survex syntax colouring, but the actual code we used to use has been lost in history.

Elsewhere there are mentions of MEDIA_URL/CodeMirror-0.62/ but none of that is any of the repos either.

Context: on the server today JSLIB_URL points to http://expo.survex.com/javascript/ which Apache aliases to /usr/share/javascript/ which, on the sever, has subdirectories

/jquery

/jquery-ui

/CaveView

/openlayers

and some others, but not 

/jquery-form/

I presume these are what come “as standard” with Debian Buster on the server. On my copy of Ubuntu 20.04 on my home machine I have the same /jquery/ (and the same version: 3.3.1) but I don’t have /jquery-ui/   or any of the others. I have found no relevant installation instructions.

Currently none of these javascript imports are under any kind of version control. Neither are any of them documented whatsoever.

Documenting what is supposed to be there would be a start.

Philip

From: Philip Sargent [Gmail] [mailto:philip.sargent at gmail.com] 
Sent: 27 February 2021 01:02
To: 'Expo Nerding'
Subject: Expo website: troggle updating

Hi,

OK I am about to re-engage with the Expo website updating. The job is just the Django version <http://expo.survex.com/handbook/troggle/trogdjango.html> :

o   The server is on Debian Buster (10.8) and I presume Wookey is not planning on upgrading that before next year but no hurry.

o   We are using python 3.7.3 which is in date and will have security updates until mid-2023

o   The troggle code is on Django 1.11 which is out of date and no longer getting security updates. The initial need is to migrate to Django 2.2 LTS which will be in-date until Spring 2022. This is compatible with python 3.7.

I have just finished bringing the CU Yachting Club website up from python2.7 & Django 1.5 to python 3.5 & Django 2.2, which is a much larger job than the Expo website. (It is stuck at python 3.5 because of old plugins: PayPal, Raven link, captchas, Mailman link, Trac link and image management.)

So I should do the Expo Django update while this is all fresh in my mind. I will need to remove the registration plugin and move to the Django in-built user system which is now more than adequate for our needs. I am also now much more adept at writing test suites for Django so I will do more automated testing.

The CUYC python was written by a professional Django developer (in 2009) and so uses a much wider range of programming features than we use. I have learned a lot. (My wallpaper is peeling from all the swearing.)

I remain firm in my belief that we should migrate away from Django and replace as much as possible with plain python. Django is just too big for amateurs now. This rewriting can be done a chunk at a time: logbooks, then survex, drawings, QMs and so on.. 

We can do import + static publish . No need for multi-user database now that importing everything takes 2 minutes.

Philip

CUYC:
14,674 lines of non-comment, non-empty python.
That is > 2x the size of the CUCC Expo django codebase 
and 15,658  lines of non-empty HTML & scripts in the /templates/ too 
That is 6x as big as CUCC Expo - but mostly static.

Unlike CUCC Expo, the CUYC system <https://www.cuyc.org.uk/training/>  is used every week to construct ~35 sailing trips a year and to enrol students in practical classes and theory courses – taking payment via PayPal and authenticating  junior members of the university via the Raven plugin. So it is vital to the everyday functioning of the club. It very significantly reduces the workload on organisers. It will be staying on Django indefinitely and is hosted by SRCF. The club turnover is more than £50k a year.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wookware.org/pipermail/expo-tech/attachments/20210325/57b1fcd0/attachment-0001.htm>