27-Feb-2013

More on WordPress
Mark has suggested another mapping:
map /wptest**/ /wptest*/index.php
exec+ /wptest/**.php* (cgi-bin:[000000]phpwasd.exe)/wptest/*.php* ods=5
and that works – for the basic action; though for completeness, I had to add
pass /wptest/000000/* /wptest/* ods=5 search=none dir=noaccess
pass /wptest/* /wptest/* ods=5 search=none dir=noaccess
to be sure images and stylesheets are loaded as well.
But first, I had to set things up so I could use the all-important WATCH facility: make sure I had to login, and could access the required files. The fast way was to copy the setup of Diana. Once that was done, I could find out what would happen now.
This new mapping does the trick – for a part. The normal user page comes up nicely, without a problem, and it is possible to login. But once the “login” button is hit, the process stops abruptly; WATCH output shows that there is insufficient core to extend “PATH” in the admin page (/wptest/wp-admin/indecx.php). This is weird, since the maximum amount of available memory for the PHP processor is 128M, set in PHP.INI….So it could be a matter of another process parameter: too little virtual memory. But pagefilequota is set to 500.000 for HTTP$NOBODY – the user under which the PHPWASD executable runs.
But when the URL of the admin page is next executed – and a new PHPWASD image is started – nothing is wrong: it simply comes on screen, a new post can be added, and followed by a few extra’s.
So it looks it works – until there is the io-error again – caused, in examination, by the same problem: there are 512 channels open…
Some further examination revealed that, if you wait long enough, the open cahnnels are closed at some point, but if you enter the next command too quick, the PHP engine gets to work without closing open channels….
What could be caused by parameter max-execution-time in PHP.INI: this has been extended from 30 to 120 seconds, otherwise the user page would not show because of exhaustion of execution time, as I found out when testing with SWS.
This has been added in the correspondence in the WASD mailing list; the raw data is available in a Windows .zip file on request by mailing list subscribers: these files may be rejected when sent as an attachement, for instance when received on a gmail account….
There is something more that’s wrong, but that is within the application: Some references in the tinymce environment are plain wrong and so some javascript files cannot be located and so some buttons don’t work. But since the link is set within WordPress, it seems more of a WordPress issue than PHP….(though these may be related!) Perhaps this is one of the things that is repaired in 3.5.1?