Yesterday’s Mondesi issue solved
Dug into the issue.
The old version did show a page, no error (nor data but that is another story), on the mapping:
0212 redirect /cgi-bin/mondesi* ///cgiplus-bin/mondesi*
0213 pass /mondesi/-/* /wasd_root/src/mondesi/*
0214 exec+ /cgiplus-bin/* /cgi-bin/*
and the new one:
0212 redirect /cgi-bin/mondesi* ///cgiplus-bin/mondesi*
0213 pass /mondesi/-/* /wasd_root/src/mondesi/runtime/*
0214 exec+ /cgiplus-bin/* /cgi-bin/*
But WATCHing the mapping procedure on the server, it seems that is still using the old value – it maps /mondesi/-/acme.js to /wasd_root/src/mondesi/acme.js:
0174 /mondesi/-/acme.js .. SET /wasd_root/* stmLF
0175 /mondesi/-/acme.js .. SET /web/* stmLF
0176 /mondesi/-/acme.js .. SET /wasd_root/doc/* map=ELLIPSIS
0177 /mondesi/-/acme.js .. SET /wasd_root/src/* NOcache map=ELLIPSIS
0178 /mondesi/-/acme.js Y- PASS /mondesi/-/* /wasd_root/src/mondesi/*
and since this file doesn’t live there, it won’t find this file. hence the error.
I didn’t understand so I asked for help on teh WASD-INFO list.
But after that, scrutinizing the output, it turned out the problem did not occcur in homedesk.conf itself, but in one of the included files: Basic.conf. In that file, there was another location of this wrong mapping. And since WASD runs the mappings from top to bottom, it will use the first match – in this case, the wrong one. So I commented it out – and ran into the same error but to another location, because a bit further on there is one line that now causes havoc:
pass /*/-/* /wasd_root/runtime/*/* cache=perm
So now the acme.js files is searched for in the general WASD runtime environment, where it doesn’t exist either.
Therefore the commented line would need to be changed to the right value:
pass /mondesi/-/* /wasd_root/src/mondesi/runtime/*
like the comment added a long time ago, states:
# Mondesi, Must be defined here otherwise overruled by
# runtime setting
And behold:
So I have to answer my own request to the WASD list….
WordPress 4.6.1
This is the latest version of WordPress.
A few weeks ago I got a mail from the WordPress team urging me to update. Easy – if you’re on Windows or Linux, but for VMS, the automated update won’t work as in these systems, since quite a lot of files contain dots as part of the filename, which is not normal for VMS. So it’s likely that when these files are stored on VMS, the dots will be replaced by underscores and therefore kill the blog. Moreover, I don’t want a standard installation (I do not have a [wordpress] directory 🙂 ) so it won’t work for that reason alone.
Of course I could set the system to allow dots in a filename (there is a setting to do that) but that may interfere with other programs. so I take the slow route: Upload the .ZIP file, unpack it, rename the newly created wordpress directory to WP with the version added, and create a system logical with that same name, referring to that directory as root of the given WordPress environment:
So on my (windows) workstation, download the nzipfile from wordpress,org and pass it to VMS
FTP wordpress-4.6.1.zip to the standard location on VMS (sman:[install.wp] - this will create wordpress-4^.6^.1.zip.
on VMS:
$ set def sman:[install.wp]
$ unzip wordpress-4^.6^.1.zip -d web_disk2:[private].
$! this creates web_disk2:[private.wordpress] directory tree
$ ren web_disk2:[private]wordpress.dir web_disk2:[private]wp461.dir
$ def/sys WP461 web_disk2:[private.wp461.]/trans=conc
The next thing is to ‘reverse’ the translations of dots in a filename (except the last one, being the divider between file name and extension/file type) into underscore. In the past, this was straight on: any dos – except the last one – should be replaced by a dot. This was possible because in the past, wordpress didn’t use underscores in their filenames, but hyphens. But since version 3.something, some files have underscores…
So the script I created to do this tedious job (named wp2vms.com), had to be altered, and 4.3.1 – the current version – was made running using that script. But in 4.4 there were even more of these files, so I didn’t get it running.
Now I have investigated what files should NOT be renamed and happily enough, the filter of files to bypass this action, could be found in two places: If the full name contains string “RANDOM_COMPAT” or “IMAGES”, the files do not need to be renamed. Running that procedure reversed the translation except these, and one that was false-positive and needed to be renamed.
(to find it: run wp2vms another time. Since the output is now limited, any file that should be renamed now stands out clearly).
So now WP461 can be put to the test.
The only thing to be done is to edit WP-CONFIG.PHP to refer to the include file containing the security definitions (which is inaccessible via the internet, of course) and add a mapping for the server. Non-public, by the way.
If it works, the blogs will be updated.
Bootcamp preparations
Nine days left to prepare a system for bootcamp ….