Patches installed.
Today, I installed a number of patches – after having made a proper image backup of the system disk.
That was no problem, as could be expected.
First tests of PHP
A few weeks ago, I learned a new version of PHP was coming soon. It’s abit delayed,but I was able to put it to thye test. Well, some tests.
To keep the previous version at hand, I renamed the previous directory trees to PHP4 and the newly created one PHP5. From there all updates have been done: PHPWASD that had to be changed a bit.
After reboot, PHP5 was enabled but there were some slight problems in the startup script, that caused PHP_ROOT not be defined. A small change solved that problem. I also forgot to move PHPWASD to the right spot, but once these issues were settled, I could start running tests.
MyPHPAdmin fails. From the start, it gives a non-CGI-conformance reply. Obvious, it doesn’t return the status as a first issue. Weird, since that should haven been returned. Or it’s caused by the MySQL 4.1 engine that came with the PHP package. That’s something to be reconsidered!
WP – the test blog – runs but is VERY slow. Login may fail, but will in the end succeed. Or may return an eror, but WATCH shows the full HTML output, which is valid. And some data is added, which may cause a problem.
This blog had a problem on login – but refreshing the screen would come back with the admin page in the end. Not sure yet what caused it. But where I previously found a message that PCRE lacked UTF-8 support, I get a more severe error:
%SYSTEM-F-STKOVF, stack overflow, PC=00000000002399E0, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
PHPSHR 0 00000000001E79E0 00000000002399E0
PHPSHR 0 00000000001E931C 000000000023B31C
PHPSHR 0 0000000000266634 00000000002B8634
PHPSHR 0 00000000001A1AC4 00000000001F3AC4
PHPSHR 0 0000000000189D94 00000000001DBD94
PHPWASD PHPWASD ProcessRequest 44025 0000000000001C58 0000000000031C58
PHPWASD PHPWASD main 43639 00000000000005A8 00000000000305A8
PHPWASD PHPWASD __main 43565 000000000000006C 000000000003006C
0 FFFFFFFF80379CE4 FFFFFFFF80379CE4
%TRACE-I-END, end of TRACE stack dump
and later on, where plugins list is shown, the same error is found.
Second, it’s VERY slow. And where I previously could handle fo9rms nicely within a 12Mb linit, I get Out-of-core messages now and than – on logout, for instance.
Testing getting an image wasn’t changed. After uploading the image, stating the image being included in the post, dows not return to the editor: IE states “The object doesn’t support this property or method”.
But the script is there if you view the source:
<script type="text/javascript">
/* <![CDATA[ */
var win = window.dialogArguments &vbar;&vbar; opener &vbar;&vbar; parent &vbar;&vbar; top;
win.send_to_editor('<a href=\"https://homedesk.grootersnet.nl/wp265/wp-content/uploads/2008/12/3c75_nrao_big.jpg\"><img src=\"https://homedesk.grootersnet.nl/wp265/wp-content/uploads/2008/12/3c75_nrao_big.jpg\" alt=\"Some astronomical image\" title=\"3c75_nrao_big\" width=\"500\" height=\"500\" class=\"size-full wp-image-20\" /></a>');
/* ]]> */
</script>
Well, I found that adding the data between the “” tags would do the trick. With, without these tags.
In the course of the next day, I’ll do some more testing to find out what’s going on.
UPDATE
Another issue just found: Where previously lines in withing <code> tags would wrap if they exceeded the width of the section, it’s not chopped on the right.
But I also found that once the site environment is set up, access to pages is faster than before. But that’s more like the result of Mark’s coding than the PHPSHR module 🙂