Tag: Wordpress

WordPress 3.5 test – a final updare
In the last two weeks, I’ve been busy with testing the new version of WordPress (at least, verison 3.5) to find out how to set things up in the WASD configuration, and it’s pretty close to be finalized. Two issues have been found – apart from problems within WordPress itself: The tests revealed an error in the PHP port, that could have caused the problem in cleanibg up the PHP environment after status has been returned to the server (a times that isn’t cleared when it should) but that is easily circumvented by specifying PHP.INI parameter max_execution_time to zero – meaning”indefentely”. In this case, it’s not a problem since WordPress won’t run into that situation :).
The other problem is to be solved by HP.
PHPWASD calls c-function chdir to change the ‘current directory’ for the running image, and next calls c-function setenv to change environment variable PATH to the same value. chdir succeeds – but setenv fails when the new value is longer than the last issued, or the default value that is passed when it wasn’t set before (being the current default). In such a case, PATH is set to NULL, the advantage being that from that moment on, any value is accepted, no matter what size it has, compared to the previously specified value.
There is a simple workaround: just re-specify the new value one more time. If all is well, it will than be accepted. The right solution if for HP to solve the issue. I created a reproducer and sent it to OpenVMS engineering.
(The full communication on the WordPress issue can be found on the WASD mailing list for 2013, thread on “WordPress: Config? UPDATE”. When applicable, some data may be downloadable from this site – links are included in the messages. The message to HP – including the reproducer, can be found on the same list – search for “setenv issue”).
Updates to be applied
This means I can now start thinking of an update of the blogs. Besides this one, I’m also thinking of updating Diana to VMS 8.4. One thing that may have caused the problem with PHP 5.3 on this system may be caused by a version difference in CRTL – or even VMS: if PHP5.3 is linked on 8.4 and run as-is on 8.3, it may have lead to the End-Of-Files issues I encountered before.

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.)