A day without Spam
Hard to believe but it happened: Yesterday there was one (1) SPAM message. If it was sent just 10 minutes later, there would have been no discareded or quarantained message at all.
Didn’t look into rejected messaqges – there have been a few, about 20. Not that much as have been handled daily in the past weeks.
Retried PHP update
Mark Berryman’s commented on the previous attempt that I reversed the next day. I made some mistakes….
Today I retried and took his advise: Do a clean install and use the supplied version of the interfacing program – because there are some differences that are incompatible with the version supplied by Mark Daniel – and the right version of PHP.INI that comes with the package.
Thougfh I still got the ‘depricated’ messages, these can be suppressed in the web-interface by canging the value to one of the configuration items, but still the blogs don’t show up. No error message using IE – but WATCH output showed a 500-error: Something is definitely wrong – but no clue on what.
So I used the PHP image on the same PHP-source:
$ php :== $php_root:[bin]php.exe
$ set def sysblog:[000000]
$ php index.php
PHP Deprecated: Assigning the return value of new by reference is deprecated in
/sysblog/000000/wp-settings.php on line 472
PHP Deprecated: Assigning the return value of new by reference is deprecated in
/sysblog/000000/wp-settings.php on line 487
PHP Deprecated: Assigning the return value of new by reference is deprecated in
/sysblog/000000/wp-settings.php on line 494
PHP Deprecated: Assigning the return value of new by reference is deprecated in
/sysblog/000000/wp-settings.php on line 530
PHP Deprecated: Assigning the return value of new by reference is deprecated in
/sysblog/000000/wp-includes/cache.php on line 103
PHP Deprecated: Assigning the return value of new by reference is deprecated in
/sysblog/000000/wp-includes/query.php on line 21
PHP Deprecated: Assigning the return value of new by reference is deprecated in
/sysblog/000000/wp-includes/theme.php on line 623
PHP Parse error: syntax error, unexpected $end in /sysblog/000000/wp-includes/post.php on line
3439
$
Again, the ‘depricated’ messages show up (although it has been suppressed in PHP.INI) but also another failure: Unexpected $end on the first included file. Weird, since the file hasn’t been changed in the update: It starts with tag <?php, but there is no corresponding endtag ?>. The PHP documentation on the tags clearly recommends omission of these end-tags if the code is pure PHP – as is in this case:
When PHP parses a file, it looks for opening and closing tags, which are < ?php and ?> which
tell PHP to start and stop interpreting the code between them. Parsing in this manner allows
PHP to be embedded in all sorts of different documents, as everything outside of a pair of
opening and closing tags is ignored by the PHP parser.…
If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the
file. This prevents accidental whitespace or new lines being added after the PHP closing tag,
which may cause unwanted effects because PHP will start output buffering when there is no
intention from the programmer to send any output at that point in the script.
Nevertheless: adding it to the file seems to solve the issue for that file – but then the same problem arised on the next file, and the next….
Changing all 300+ files in that matter is not feasable. Even more: since it’s a recommendation to OMIT the end-tag, there should not be a need for it.
To be sure, I also dowloaded the latest WP version (3.4) and ran the INDEX.PHP file using the PHP command. I would expect an error message because wp-config.php isn’t there – but here again the parser complains on a missing end-tag:
$ set def wp34:[000000]
$ php index.php
PHP Parse error: syntax error, unexpected '>' in /wp34/000000/wp-blog-header.php on line 19
$
Depending on the file, it unexpectedly encounters “>” of “$end” on end-of-file – where the end-tag “?>” should be implied. At least, it looks that way.
But no more depricated interfaces, which is good.
So, again I had to revert the update.
The issue has been sent to the WASD mailing list. Hopefully there will be an answer soon…