Posted on

15-Aug-2012

More investigations
I have done a bit more investigation on the PHP issue.
First, I created a procedure in which I can set the PHP environment as /JOB logicals so I can do the tests without interferendce with the access over the Internet.
Next, I checked the WordPress versions I haev installed. Apart from 2.6.3, I have installed 2.6.5, 2.8.2 and 3.4.1. I tested each of them after setting the PHP version to use (either 5.2.6 of 5.3.14), directly on the root directory of that WP version – so VERY basic.
Even using 5.2.6 I had problems – where this wasn’t the case a few days ago: On each of the blogs, PHP complained a file could not be located:

$ set def WP:[000000] ! the root directory of that WP version
$ php index.php

X-Powered-By: PHP/5.2.6
Content-type: text/html

<br />
<b>Warning</b>: require(/WEB_DISK2/private/wp263/wp-includes/class.wp-dependencies.php) [<a
href='function.require'>function.require</a>]: failed to open stream: no such file or directory in
<b>/WEB_DISK2/private/wp263/WP-INCLUDES/script-loader.php</b> on line <b>3</b><br />
<br />
<b>Fatal error</b>: require() [<a href='function.require'>function.require</a>]: Failed
opening required '/WEB_DISK2/private/wp263/wp-includes/class.wp-dependencies.php' (include_path='.:/php_root/000000') in
<b>/WEB_DISK2/private/wp263/WP-INCLUDES/script-loader.php</b> on line <b>3</b><br />
The problem here is that this filename contains a dot: the file does exists:

$ dir [.wp-includes]class.wp-dependencies.php

Directory WEB_DISK2:[private.wp263.WP-INCLUDES]

class^
⁁.wp-dependencies.php;1

Total of 1 file.
(except in WP34, but that is to be expected: I didn’t change the file there)

The only reason I can think of is that the tests a few days ago – or work done yesterday – has removed something….

The same runs using PHP 5.3.14 didn’t run into this issue, even with the older WP versions; apart from the ‘depricated’ messages, any version runs into error:
PHP Parse error: syntax error, unexpected $end in
/sysblog/000000/wp-includes/class.wp-styles.php on line 72
It means the file – including the dotted name – is actually found.
WP 2.8.2 didn’t show the ‘depricated’ messages, so that one seemed to be Ok for PHP 5.3. But there was this same error in the end…
The WP3.4 gave a slightly different message:
PHP Parse error: syntax error, unexpected '>' in /web_disk2/private/wp34/wp-blog-header.php on line 19
So not ‘unexpected $end’; it could mean theer si something else wrong – but since it’s off-the-sheld, ist simply should work…

Bu the web has no trouble with it – so I tried – with PHP 5.2.6 – and removed the private PHP logicals, and used the /SYSTEM/EXEC defined once: Same problems….But for the web access, nothing changed: it simply runs like it has done for months….

Next, I redefined thet SYSMGR blog to run from WP 2.8.2 – being the latest version before WP 3.0; And by access from the web, I remembered why it wasn’t released before: It uses some form of Redirect which causes a loop when the mapping in WASD isn’t altered: accoring the WATCH output, it is obvious that is does: time after time, it runs into the bolded line:

redirect /sysblog /sysblog/index.php
redirect /sysblog/ /sysblog/index.php?
redirect /sysblog/**/ /sysblog/*/index.php?
exec /sysblog/**.php (phpwasd:)/sysblog/*.php \
ods=5 script=syntax=unix script=query=none map=once
pass /sysblog/* /sysblog/* ods=5 search=none dir=noaccess

Quite likely that WP 3.4 runs into the same problem

So I set things up to use 2.6.5, and now the blogs run on that version; there is yet another issue to be tested: Does WP 3.4 require another mapping…

PMAS license
The new license has arrived and is now installed. Just in time 🙂

Posted on

13-Aug-2012

PHP upgrade (continued)
Mark found something – because Variable-format files are indeed a problem. This type wasn’t taken into account in his rigorous testing…
Now he has found what was going wrong and has released a new PHPSHR file – AND he’s now able to reproduce the error. For now, all files that are included (‘require’ or ‘include’ in the code) MUST be stream_lf. So on request, I converted the only file that is in variable format, to stream_lf. PHP 5.2.6 has no problem – but when I tried with PHP 5.3, PHPWASD.EXE stopped without error – and returned a 500 error.
Running the blog with PHP.EXE didn’t change a thing….

But since the problem is now reproducable, the issue may now be solved.

(to be continued)

Posted on

12-Aug-2012

PHP upgrade – continued
Got a reply from Mark – I sent him some WATCH output on the errors I encountered last Friday – and he noticed PHP code in the log – where it shouldn’t.
Admitted: I completely overlooked this part of the output….But these lines explained both the database-access problems with WP 2.6.3, and the shown PHP-code using WP 3.4.: the log shows no space, or better: line termination, between the PHP starttag and the first characters of the next line:
<?phpdefine or<?php/**
where you would expect
<?php
define or
<?php
/**
like the files read.
I encountered the first of these when I ran the blog using WP 2.6.3, with PHP 5.3. I thought the absence of the mysql and mysqli extensions were to blame, but that seems not to be the case, but the fact this file wasn’t interpreted. Apart from the other messages (that now seem to be suppressed in the PHP.INI file) this was unexpected, but it explaines the database access issue: the file is not included and interpreted but simply outputted – since there is no starttag stating this is PHP-code: the system simply concatenated the tag (which does exist in the file) and the next line – causing “<?phpdefine“. This is the databse-access file, kept outrside the normal path, but included in wp-config.php. And, in the WP 2.6.3 environment, it is the only file in Variable format.
As for the second example, this is a plain WP 3.4 file – the one I have converted to Variable format on request of Mark. Again: the lines are simply concatenated – WITHOUT addein Linefeed or NULL character, causing it to be interpreted as plain text to be outputted, in stead of being PHP code to be interpreted. Therefore, the database access file is never reached, so you would never see the first message showing up.

After I reversed the change and used the Stream-LF version again, I got the missing end-tag message again….

It looks like End-Of-File processing is not correct, nor is the End-Of-Line processing for Variable files….

To be continued

Posted on

10-Aug-2012

More on PHP update
Downloaded the latest PHP (5.3.14), in which all extensions are now included, but it has it’s own obstacles: WordPress 2.6.3 can no longer connect to the database; I ran into something similar when I tried to bypass the mysql extension in favour of the more modern myslqi one, where WP signaled it missed an extension…No message of that kind in this case, but a database connection cannot be established…
Not such a big deal – WP 3.4.1 is on the shelves to be rolled in – when PHP 5.3 works.
So I continued testing.
Not that it mattered much: I got the very same issue: missing end-tags at EOF, on the every first file that is ‘required’ in the code on index.php:
<?php
/**
* Front to the WordPress application. This file doesn't do anything, but loads
* wp-blog-header.php which does and tells WordPress to load the theme.
*
* @package WordPress
*/

/**
* Tells WordPress to load the WordPress theme and output it.
*
* @var bool
*/
define('WP_USE_THEMES', true);

/** Loads the WordPress Environment and Template */
require('./wp-blog-header.php');
?>

wp-blog-header.php is indeed the file that PHP 3.4 complains about:

<?php
/**
* Loads the WordPress environment and template.
*
* @package WordPress
*/

if ( !isset($wp_did_header) ) {

$wp_did_header = true;

require_once( dirname(__FILE__) . '/wp-load.php' );

wp();

require_once( ABSPATH . WPINC . '/template-loader.php' );

}

Indeed: no end-tage here.

Since all files originate from Unix, the WP files are all in Stream-LF format. It may cause an issue with PHP 5.4 (where, I think, it should not), but since I noted other problems with this function elsewhere (wget…), Mark suggested to convert the file to variable format, since that would bypass the mmap function.
So I did, for this file. It could mean the next file (wp-load.php) would cause the problem with a missing end-tag. But alas. The converted file did no longer cause the error on this file, but neither did wp-load.php: the contents of wp-blog-header.php are not interpreted, just presented as normal output….
Not exactly what is to be expected.

We’re getting on….Mark will set up an Alpha 8.3 box and try for himself. (I guess he’s working on 8.4 on Alpha, or on an Itanium box?). I’ll try on my 8.4 box as well. Perhaps it is an 8.3 issue ….

Posted on

09-Aug-2012

PHP update tested
Last mail I got from Mark Berryman stated that PHP now uses mmap in memory management – and that rang a bell: the wget image, ported by Steven Schweda, does as well, and that one crashed on ACCVIO in accessing robots.txt, according his investigation. He suggested there might be some issue with the MMAP implementation in ACTRL – the C run-time Library. If that’s the case, it may explain why PHP 5.3 has trouble as well.
Last OS update included an update of this library, so perhaps it was solved.
But no: again, the PHP engine failed to recognize EOF as the missing “?>” end-tag. So that’s to be reported once more. It must be something withing the environment since, as he told me, he couldn’t reproduce the error.

Switching between the two versions is easy using the setup I use: just run one procedure and use the right PHP version. But as it turned out, there a bit more to reckon with. The WASD web server caches files – including started run time environments and scripts. Purging the cache and stopping all processes you’re going to handle, is a requirement; but you may end up with restarting the web server (just a commend, it’l be available within a few seconds. But the environment is fresh). Don’t forget the browser cache, not just the pages but cookies as well, even those of your favorite sites. I forgot that one – and starting this blog rendered the ‘NoService’ page– the one you get if you enter a non-existing grootersnet.nl site….(There might have been a coïncidence with the SYSBLOG logical, but the /EXEC and /SUPER defined logicals were completely corrrect….)

Anyway: PHP is restsored to it’s previous version….Once more 🙁