PHP 5.4.0 released!

I'm guessing that you disabled one or more extensions which were crucial to your site(s). Recompile these extensions and install them again. Disable extensions you don't really need, such as APC. And, of course, check the server logs to see what went wrong.
 
Make sure that you update the php.ini (often /usr/local/lib/php.ini) to match the new extension filenames. And, again, check the logs to see what goes wrong. If the pages stay blank, it's most likely a PHP error, which get logged. Maybe try running one of your PHP scripts on the CLI? It often gives you more information about what goes wrong.
 
I know this sounds strange but I checked on these logs:

/var/log/httpd/access_log
/var/log/httpd/error_log
/var/log/httpd/domains/mydomain.com.log
/var/log/httpd/domains/mydomain.com.error.log

and there is nothing.... I mean there are only some old logs but nothing new.

I tried to re-compile extensions, checked php.ini, run again ./build php n and still is not working... maybe I should run ./build php y instead?
 
Check the domain's logs @ DirectAdmin. You may have to turn on "log_errors" in php.ini
 
PHP 5.4 EA Loaders coming...

There is no ionCube loaders released for PHP 5.4 yet, but I think they will release it very soon.

Indeed, following an intensive period of development, we expect to release early access Loaders for running PHP 5.3 compiled code on PHP 5.4 within a Linux platform next week. Encoded files must be produced using the version 7 Encoder as that's the release that adds PHP 5.3 encoding. Although classified as early access, this Loader has been running well and for a while against an extensive test framework that we use, so we're keen to make it available now for the early adopters out there!

Users in general wouldn't be aware of this, but PHP 5.4 is a huge change. Not only has the language itself changed yet again with new syntax (if php.net had their version numbers under control correctly then this would be PHP 7 or PHP 8), but internally there are wide ranging and fundamental changes to core data structures that have been otherwise largely unchanged since the first introduction of the Zend Engine, when PHP went from 3 to 4 well over a decade ago. If PHP 5.3 was tricky, which it was and interestingly Zend failed to support existing encoded files on PHP 5.3, supporting existing encoded files on PHP 5.4 is a whole new level of complexity and challenge. However we expect to be able to run PHP 5 encoded files too in due course and perhaps also PHP 4 files. A new Encoder for PHP 5.4 native compilation will be released later in the year. So stay tuned. We put announcements out on Twitter @ioncube and on our site.
 
@ioncube, Thanks for the details.
I guess that explains why it took so long for the cache guys to come up with a compatible product.

For me, only Xcache is working. Apc still breaks when using it on ex magento (installation goes fine).
Zend only has a beta out.

What you may be wary of is the fact that php 5.4 now gives notice errors when doing array to string conversions.
The fact that array_diff does this internally, and then throws insane amounts of errors if you put in a multi dimensional array, can kill your server.
In my case it was Doctrine 1.2 what did this, so i had to patch it (it's no longer supported).
 
ioncube for php 5.4:

This is what worked for me:
Code:
# cd ~
# wget http://www.ioncube.com/early_access/phpd-4.1-libs-linux_x86_64-glibc2.3.4.tgz
(for 64bit. Check [URL="http://www.ioncube.com/loaders.php"]this/their site[/URL] for other version)
# tar -zxvf ioncube_loaders_lin_x86-64.tar.gz
# mv cp ./linux_x86_64-glibc2.3.4/5.4.0/ioncube_loader_lin_5.4.so /usr/local/installatron/lib/
# wget http://data1.liquenox.com/installatron/installatron_setup.sh
(source: [URL]http://installatron.com/docs/admin/upgrade[/URL])
# chmod 755 installatron_setup.sh
# ./installatron_setup.sh -f

Worked for me with CentOS 5.7 64bit, Apache 2.4.2, PHP 5.4, Custombuild 1.2

Hope it helps :)
 
Last edited:
It's not clear from your reply as to whether this will work for people who don't have Installatron installed; the thread topic is PHP 5.4 so that would be helpful info.

Thanks, Jeff
 
What i did (Ubuntu 64):
wget http://www.ioncube.com/early_access/phpd-4.1-libs-linux_x86_64-glibc2.3.4.tgz
tar -zxvf phpd-4.1-libs-linux_x86_64-glibc2.3.4.tgz
cp linux_x86_64-glibc2.3.4/5.4.0/ioncube_loader_lin_5.4.so /usr/local/lib/ioncube_loader_lin_5.4.so

cd /usr/local/directadmin/custombuild
nano options.conf
php5_ver=5.4
./build update
./build php n

Don't forget to edit php.ini

And it works for me (well, at this moment it does, haven't found a site going nuts on me yet).
 
Last edited:
It's not clear from your reply as to whether this will work for people who don't have Installatron installed; the thread topic is PHP 5.4 so that would be helpful info.

Thanks, Jeff
Sorry for that...

I don´t have anything else to test it on.
 
I update PHP5.3 to 5.4 version. I must back to 5.3 version, but now safe mode is ON. Directadmin sey safe mode is OFF. What is wrong?
 
did u restart apache afterwards ?

Code:
# service httpd restart
 
I put in a ticket with IONCube today that includes questions and answers that should be of interest to others contemplating PHP 5.4.

IT_Architect said: I have an app the original developer abandoned. PHP has changed a lot with 5.3. I THINK I have source for everything that needs to be updated to make it compliant. HOWEVER:
1. Will/can an IONCube that is compatible with 5.3, work with files that were encoded before 5.3?
(I’m currently using FreeBSD 7.2 64. I know you don’t have a loader for 5.4 yet.)
2. If not, is there any utility that I can run on the files to convert them to run on the IONCube 5.3 version loader?
Nick said: We expect to do a full release of our 5.4 Loader next week across the various platforms. PHP 4 encoded files upwards are supported.
 
After some soul searching, jumping over 5.3 to 5.4 sounds good on paper. However, many products don't work with 5.4 yet, including SquirrelMail. IONCube won't have a release out until next week. The 5.3 migration is a worthy one because you pick up features you can use. 5.4 drops what was deprecated in 5.3, and if that were all, almost all of 5.3 compatible code would run with it, but that is not the case. 5.4 corrects things in the language that were never right from the start. Example: You pass an A-z character or white space to a function, and it evaluates it as 0. You can see where developers would write code that would rely on that behavior. Or lets say you pass a 1.4x, and it evaluates to 1. There are probably a thousand ways hackers can exploit PHP coded sites with a little knowledge of the source code. Suddenly with 5.4, it sees these things as errors. Moreover, it's likely that many problems would be intermittent because whether they show up or not would depend on the contents of a variable at certain point in time. If the code is designed to rely on the new behavior of 5.4, it may not work in <= 5.3 because older versions wouldn't set an error you depend on for branching. Therefore, 5.4 also has a lot of potential to break things. Even after SquirrelMail and IONCube have their releases out, you would have the expense of hiring a body guard if you rolled out 5.4 in a shared hosting environment if the useful plugin scripts that come with products like Installatron or Fantastico haven't been converted yet.

The reason things are moving awfully fast today, is they moved awfully slow in the past. What is amazing to me is why PHP hasn't had a mass exodus. 5.3 was an emergency release of 6.0 without the UNICODE. They recently rebooted the 6.0 project because of a faulty UNICODE strategy. We all agree the changes are necessary, we all agree the changes cause major carnage, and there is really no nice way to do this. PHP was never envisioned to do the things it's being asked to do today.
 
Last edited:
After some soul searching, jumping over 5.3 to 5.4 sounds good on paper. However, many products don't work with 5.4 yet, including SquirrelMail. IONCube won't have a release out until next week. The 5.3 migration is a worthy one because you pick up features you can use. 5.4 drops what was deprecated in 5.3, and if that were all, almost all of 5.3 compatible code would run with it, but that is not the case. 5.4 corrects things in the language that were never right from the start. Example: You pass an A-z character or white space to a function, and it evaluates it as 0. You can see where developers would write code that would rely on that behavior. Or lets say you pass a 1.4x, and it evaluates to 1. There are probably a thousand ways hackers can exploit PHP coded sites with a little knowledge of the source code. Suddenly with 5.4, it sees these things as errors. Moreover, it's likely that many problems would be intermittent because whether they show up or not would depend on the contents of a variable at certain point in time. If the code is designed to rely on the new behavior of 5.4, it may not work in <= 5.3 because older versions wouldn't set an error you depend on for branching. Therefore, 5.4 also has a lot of potential to break things. Even after SquirrelMail and IONCube have their releases out, you would have the expense of hiring a body guard if you rolled out 5.4 in a shared hosting environment if the useful plugin scripts that come with products like Installatron or Fantastico haven't been converted yet.

The reason things are moving awfully fast today, is they moved awfully slow in the past. What is amazing to me is why PHP hasn't had a mass exodus. 5.3 was an emergency release of 6.0 without the UNICODE. They recently rebooted the 6.0 project because of a faulty UNICODE strategy. We all agree the changes are necessary, we all agree the changes cause major carnage, and there is really no nice way to do this. PHP was never envisioned to do the things it's being asked to do today.


Squirrelmail has now!

http://squirrelmail.org/

ANNOUNCE: PHP 5.4 Compatibility
Mar 29, 2012 by Paul Lesniewski
With the recent release of PHP version 5.4, some community members have helped identify some small issues which we've fixed and made available in our daily snapshot packages located on our downloads page. Especially if you use the Mail Fetch plugin and want to upgrade to PHP 5.4, you should download one of our snapshot packages.
 
Back
Top