Update on WordPress upgrade
Finally, the new version of WordPress – that is: 3.5) runs on Daphne, under WASD 10.2 and PHP 5.3.14, in a basic theme, but it required a very different mapping than I used originally:
redirect /wptest /wptest/index.php
map /wptest**/ /wptest*/index.php
exec+ /wptest/**.php* (cgi-bin:[000000]phpwasd.exe)/wptest/*.php* ods=5
pass /wptest/* /wptest/* ods=5 search=none dir=noaccess
There might be some additions, thanks to UMA, but this setting does the (most basic) job.
Nevertheless, there are still a few things to take care of – but since I don’t control the PHP-port, PHPWASD or C-RTL, the few things that still don’t work as expected, or wanted, cannot be resolved immediately.
Mark Berryman identified an error in PHP but there is a workaround: setting max_execution_time in PHP.INI to zero will probably solve some timer-related issues – as the sort-of keep-alive of PHPWASD.EXE and the PHP environment. He will solve this issue, so there is some more testing required.
Not that this workaround solved all the issues – when WordPress admin page is started, it may take a while before they show up – and the number of open channels keep going up, to 150 or so. But later on, it’s MUCH faster, and requires less channels, even when PHPWASD is restarted from scratch. This has to do with paging, I guess, because Daphne is small – compared to the systems that Mark Berryman and Mark Daniel appear to be using.
More problematic is a dysfunctional C function.
As Mark Daniel has explained, PHPWASD.EXE uses the chdir function to change the location where the images should run – in the Unix-way of thinking – in practice, the directory specified in the URL that starts the PHP code. So http://<site>/wptest/index.php will cause a chdir to /wptest, and http://<site>/wptest/wp-admin/index.php will chdir to /wptest/wp-admin. That is working fine. But next, PHPWASD.EXE calls function setenv to set environment variable PATH to the same value. In itself, that’s fine also – but this fails when the second assignment uses a string longer than the preivious one. This happens within WordPress: On the first URL (http://<site>/wptest), nothing is wrong chdir ("/wptest") is executed as well as setenv("PATH","/wptest"), but after the login sequence, when http://<site>/wptest/wp-admin/index.php is to be excuted (which is reflected in the address bar of the browser), chdir ("/sptest/wp-admin") succeeds, but setenv ("PATH","/wptest/wp-admin") fails and PHPWASD exits after returning a 502 status to the server, causing a non-cgi-conform response….
When you next start the same URL, all is well, and the pages show up nicely. However, you may encounter similar problems on executing other PHP code that re-executes setenv.
After Mark Daniel had specified a test program for chdir, getenv and setenv, I adapted this program to do some testing. And my assumption that size maters, becomes clear: the length of the last assignment determines the maximum size of the next string! If longer, the status of setenv is -1 – stating an error, and the environment variable is set to null:
$ run test3
1 - Longest (/wptest/wp-includes)
getenv PATH == sys$sysroot:[sysmgr]
setenv PATH == 0
getenv PATH == /wptest/wp-includes
chdir PATH == 0
getenv PATH == /wptest/wp-includes
2 - Midsize (/wptest/wp-admin)
setenv PATH == 0
getenv PATH == /wptest/wp-admin
chdir PATH == 0
getenv PATH == /wptest/wp-admin
3 - shortest (/wptest)
setenv PATH == 0
getenv PATH == /wptest
chdir PATH == 0
getenv PATH == /wptest
4 - Midsize again (/wptest/wp-admin)
setenv PATH == -1
getenv PATH == (null)
chdir PATH == -1
getenv PATH == (null)
I would call this a bug. It might have been introduced in an UPDATE on VMS 8.3 and 8.4, Jeremy Begg has located that there has been an update on this function to prevent a memory leak. Quit possible that the way it has been solved causes this erroneous behavior.
Alas, there is no way to get around this, except that PHPWASD should NOT change PATH this way. So I would need the PHPWASD-code for PHP 5.3.14 (The version for PHP 5.2 has another interface to PHP which is not compatible…).
But for the normal user – who reads the blogs – there seems to be no a problem. So the next step is to try the newest release of WordPress (3.5.1) and the themes I would like to use, and see if it all works fine.
Finally, there may be another thing to consider, and this may have caused the end-of-file problems I encountered on Diana with PHP 5.3: If the code is built on VMS 8.4, it may cause problems when executed on VS 8.3. It shouldn’t, but because CRTL is involved, it could cause problems.
All information on the issue can be found on the WASD mailing list, look for “wordpress: CONFIG?” in the 2012 and 2013 directories, and the test programs I used are available here. Note this is a VMS-created ZIPfile so you’ll have to move the file to VMS (binary!) and unzip it there….(The other files in this directory are Windows-based ZIPs containing NOTAPAD files.)