Viewing Thread:
"Unannounced web server changes grumble"

I am really irritated that Freeola make changes to web server configurations without letting users know - either before or after the event. Some months ago there was the change which stopped PHP programs running until you changed your folder/file permissions. And just recently the change affecting calls by reference, which again stopped PHP programs working that had previously worked fine for many months.

I understand that Freeola may sometimes need to make changes for e.g. security reasons (though I can't see any logical reason for the reference call change), but surely they plan these changes and don't just make them on a whim overnight. There is an email address associated with every website, so why don't they send out an advance warning (at least 1 month before) and again after the change has been effected? Then we could plan to make the necessary changes at a convenient time.

As it is, I was left to find out by accident. After the first change, I got a few emails from users complaining that the site didn't work anymore. In the second case, it was just luck that I happened to test the site just before going away on holliday - so I had to scramble to make corrections to my code when I was already really busy. I know it's a free service, but this is just treating users with contempt.

Also the so-called Help about the reference call change was pitiful - it suggested you could change the php.ini file, but I (and probably most users) don't have a specific ini file, and to create one we need to copy the existing default Freeola php.ini file - but how do we do that? Not a clue.

And the change itself seems very odd - if a function is defined having a call-by-reference argument [e.g. foo(&$xyz) ] then previously it could be called either implicitly as foo($abc) or explicitly as foo(&$abc) - but now the 2nd call type doesn't work (although it matches the function definition!). It's not a case of disabling call-by-reference, just disabling the form of calling that makes the reference explicit! Weird.

Hi alanb,

If you didn't receive any prior notification, it might be worth checking that your MyFreeola e-mail address is vaild and up-to-date as this is the address we normally use to contact users.

Also, if you have Hotmail or use any other e-mail service with an overly agressive spam filter, it may help to whitelist e-mails from freeola.co.uk and .com addresses to ensure that notifications get through in future.

Yes emails were sent out. If you did not receive them then please accept my apologies.
As for allow_call_time_pass_reference (thanks Garin) you should read http://uk3.php.net/ini.core
'This method is deprecated and is likely to be unsupported in future versions of PHP/Zend. The encouraged method of specifying which arguments should be passed by reference is in the function declaration. You're encouraged to try and turn this option Off and make sure your scripts work properly with it in order to ensure they will work with future versions of the language (you will receive a warning each time you use this feature).

Passing arguments by reference at function call time was deprecated for code cleanliness reason. Function can modify its argument in undocumented way if it didn't declared that the argument is passed by reference. To prevent side-effects it's better to specify which arguments are passed by reference in function declaration only. '

So it seems that the newer version of PHP4 has this off by default in the ini file.

I only questioned you about PHP5 to ask whether you were using it. To use PHP5 you files must have the extension of PHP5.

Of course tests were done on the changes being made but I don't think anyone would be able to test everything PHP has to offer to make sure it ran exactly the same as before. Settings were changed for a reason, either by the PHP developers or by us and information was sent out and posted on our website stating this.

fwiw -
I received an email a few days before each of the latest webserver upgrades. I haven't kept the emails, but the last one was received in the week starting 18th June and concerned web servers 2,4,7 & 8 saying the upgrades would take place on the 25th.

I made a note in my diary to check my sites functionality on the 25th!

Did your problems start around that time and did you see that email?

EDIT> posted at the same time as Digitrader...

I received an email to all my accounts from freeola about the php upgrades.

Yes, maybe Freeola have 'upgraded' PHP 4 as well - but without telling anyone! Let's not get too sidetracked about specific problems - I have already made the changes needed to get my website working again. My grouse is more general, that Freeola make significant changes (i.e. that stop sites working that were previously OK) without adequate (or any) notice to the website owners. I suspect that they sometimes don't even realise what effect their changes can have, i.e. they don't do any proper testing before making a change.

Maybe professional website builders check the Freeola status page and chat pages every day for news, but hobby users like me who maintain a few sites used only by family and friends do not do so, and I may not view my own sites for weeks on end, so a problem may exist for ages before I pick it up and correct it. Unfortunately, many viewers do not bother to report a problem, they just give up trying to view the website.

W.r.t. the previous case when Freeola changed the permissions needed for PHP folders and files, this was for a valid security reason, but I did not know about it until several weeks later (after several people had had a problem but not bothered to tell me!).

Incidentally, the information given about this (on the PHP Basics page) is misleading as it seems to suggest 2 different modes (755 and 644) for files. I think that para 3) should say executable, not writeable:

2) PHP scripts cannot have their permissions set so that they are writeable by anyone other than the user.

The usual permissions for your PHP files would be to set them to 755 not 777.

3) PHP script files cannot have their permissions set so that they are writeable by anyone other than the user.

The usual permissions for your PHP files would be to set them to 644 not 777.

Ahem, perhaps not wise to assume Freeola explicitly changed it. It seems to me that PHP 4 has been upgraded as well. Upgrading to new versions can and will mean ini settings get changed. Especially in cases like this where its a depreciated feature.

Further info: I ran phpinfo() again, and this shows it is running PHP 4.4.4. Also the Configuration File (php.ini) Path is /usr/local/etc/php4/cgi/php.ini

Presumably the PHP 5 ini file would be in a different folder with /php5/ instead of /php4/

All my PHP files are plain .php extension, and the above confirms I am running PHP 4. So the only difference is that YOU (Freeola) must have recently changed the PHP 4 configuration file php.ini, and changed the value of allow_call_time_pass_reference within it. This has got nothing to do with PHP 5, nor with any security issues, so why on earth did you do this?

As an example of the problem, one of my files is called viewfuncs.php - there is nothing in the name or contents that specifies which version of PHP to run. The file was written to be compatible with PHP 4 and used to run OK. I don't see how I can choose what PHP version will run - surely this is determined by the server (unless it expects a different file extension for different versions)?

This file contains a function defined as follows:

function viewIndex(&$itemlist, $itemnumber=0, $redisplay=false)
{
...
}

Note that the first argument $itemlist is defined as call-by-reference (for efficiency, because it's quite big).

This function was called in the following way:

viewIndex(&$itemlist,$itemnumber,true);

This worked fine for months, but today it didn't, and gave a warning that call by reference was no longer supported (not quite true!). The warning also suggested either changing the code, or setting allow_call_time_pass_reference to true in the php.ini file.

After investigating (and finding I could not use ini_set() for this ini variable), I decided to change the code instead. So I changed the above call (and similar cases in this and other files) to:

viewIndex($itemlist,$itemnumber,true);

Now the file works again, with no warning, and correct operation. Note that it is still using call by reference (otherwise the function wouldn't work correctly), it's just that this is only apparent in the function definition and not in the function call.

I also created and executed a small php file containing just:
phpinfo();
?>

which confirmed that allow_call_time_pass_reference was set to false. But I don't know an easy way to make a copy of the Freeola php.ini file (if I had wanted to create my own customised version of it.)

I don't think just posting a general message on the status page is adequate if you are going to make a change which will stop websites working. Why would I even look at the status page when everything is working fine? So I get no advance warning. You need to send an email addressed to all website owners - surely you have this capability - I am sure I got an email about changes to form mail (but which I don't use).

His problem is that the PHP directive allow_call_time_pass_reference is set to off and I assume that it wasnt previously.

Of course, whether you should turn it back on again is another matter entire. :)

Hello,
Is there any chance you could give an example of the problem code? If you don't want to post it here then you can email it to webmaster at freeola.com.
I believe that a notice of the intended upgrade to all our web servers was on our network status page for some time. This has now been removed as all the web servers are now upgraded.
If your code is causing problems since the upgrade and you can't find out what has changed then you can check using phpinfo() and also let us know. Some changes may have occurred due to an upgrade in software versions (the servers are running PHP4 alongside PHP5 now, which requires a different configuration, together with the improved security of PHP5 and the introduction of other setting that can be viewed with phpinfo()). While we try to minimise problems for customers some changes were absolutely necessary.

The way in which referencing works changed slightly with PHP5, but unless you renamed your files to have the PHP5 extension then this shouldn't effect you.

As far as I'm aware there is nothing in the PHP4 configuration that should effect this so if you could sent through the code we can have a look and see what may be causing the problem.