Web staff 404 errors in paths to files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
New
|
Undecided
|
Unassigned |
Bug Description
We are using 2.12.4. The web staff client – when switched to Czech – does not seem to successfully find a number of – mostly javascript – files due to incorrect paths.
When symlinks are used to correct the wrong paths and file names, the browser can load the web pages without these errors. As a result, more translated strings appear.
Here comes a list of links with wrong NLS path that we have discovered so far and temporarily (in our installation) corrected through symlinks:
lrwxrwxrwx 1 opensrf opensrf 5 srp 7 22:22 /openils/
lrwxrwxrwx 1 opensrf opensrf 5 srp 7 23:06 /openils/
lrwxrwxrwx 1 opensrf opensrf 5 srp 7 23:18 /openils/
lrwxrwxrwx 1 opensrf opensrf 5 srp 7 21:44 /openils/
lrwxrwxrwx 1 opensrf opensrf 5 srp 7 23:10 /openils/
lrwxrwxrwx 1 opensrf opensrf 5 srp 7 22:52 /openils/
lrwxrwxrwx 1 opensrf opensrf 5 srp 7 22:22 /openils/
We have also tried to map the following missing files (js and map file) to similar existing files (add a fake link to another js or css file):
lrwxrwxrwx 1 opensrf opensrf 22 srp 7 22:07 /openils/
lrwxrwxrwx 1 opensrf opensrf 17 srp 7 21:47 /openils/
Also, there seems to be a typo in font file name (file extension):
lrwxrwxrwx 1 opensrf opensrf 33 srp 7 21:46 /openils/
One javascript file seems to be missing:
/js/dojo/
A better solution than to use symlinks would of course be to correct the paths in the appropriate places in Evergreen if these can be identified.
This bug is related to https:/
tags: | removed: webstaffclient |
Have to test this behavior. According to miker in IRC, this is "normal" cause the page will try to find the specific cs-cz and not finding that, drop down to cs and find that.
But should test to see if adding the links assists with the page render as indicated here.