31-Dec-2008

PHP issues
I found that the new PHP engine seems to be somewhat case sensitive….
When trying to add new content to the tracks blog, I entered the location as “Tracks” and that failed – causes the location not found. But stating “tracks” – all lowercase – works. At least, at that time it meant a difference. Once things have been accessed, case doen’t seem to matter anymore: I cannot reproduce it at will now.
The same problems happened with this blog. Once in a while, nothing seems wrong and all works fine, at other times I get “stack overflow” at some places, and MySQL may (!) fail accessing RSS data; This is found in the webserver log:
WordPress database error MySQL server has gone away for query UPDATE sm_options SET option_value = 'O:9:\"MagpieRSS\":19:{s:6:\"parser\";i:0;s:12:\"current_item\";a:0:{}s:5:\"items\
It happens on any of the admin screens, I guess this is a MySQL problem…
The same may happen using SET in stead of UPDATE in the SQL statement. It causes errors on accessing the server, but refresh could well return the page.

So it’s not as stable I would expect. Big problem: Re-starting the older version failes with ACCVIO, no matter what I try….But normal use seems to work pretty well – and fast, once the environment has been setup – so I keep it this way – for now (there is no real alternative 🙁

Others are testing as well, it has been found that UTF-8 is now built-in in the PCRE module. That’s true, since at times I do not get this error in the sysblog admin pages. But other required modules are not included, and these could cause the problems I found including media.

Some digging to do, still, before sending a report to HP.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.