PHP 5.6.0RC4 & PHP 5.3.29 are available

Yes, because "./build update" updates CustomBuild files only, while "./build php n" updates PHP. "./build update_versions" would update PHP for you also.
 
What a rush for version numbers?! We still have servers with 5.2, and they offer 5.6 already. Commercial CMS has a free period of updates limited to 1 year; and not all the customers want to prolong it for a fee, so they are stick to PHP 5.2.9(!).


I hope you are not planning to drop PHP 5.3 support in CustomBuild 2.0.
 
CB 2.0 will still support PHP 5.3 in the future (CentOS7/RHEL7 is the only exception) :) Thank you for your input!
 
Hello,
there is no need to run 5.2 because everything is working on 5.3. With 5.2 there are many problems with performance and other modules. Upgrade to 5.3 and if you have problems Martynas can help you. If there is any problems on user side you can fix it with simple .htaccess changes or php.ini.
 
CB 2.0 will still support PHP 5.3 in the future (CentOS7/RHEL7 is the only exception)

Good to know that.

there is no need to run 5.2 because everything is working on 5.3.

Probably I was not enough clear. Commercial software which I was referring to is zend-encoded and since that it can not be used with another PHP version. We've got some solutions here already done, but still we are stick to CustomBuild 1.2. Anyway that's not a question how to upgrade PHP from 5.2 to another version. I'm just wondering why do they need that number of PHP branches.
 
5.2 to 5.3 ok in my experience (zend module backwards compatible) but 5.2 to 5.4 isn't and unless you own actual zend encoder no way to make the few php edits needed.
safe then sorry seems best way to go :)

would like to see yet another php option (run 3 versions) to test newer versions. the 2 versions allows us to run on older if needed which is extremely helpful.
but sometimes hard to test if you have items that need old version and items that need new version, no leeway to test with.
would be nice to fire up a test vps with test DA install on it but no way can afford that.
 
5.2 to 5.3 ok in my experience (zend module backwards compatible) but 5.2 to 5.4 isn't and unless you own actual zend encoder no way to make the few php edits needed.

I don't much worry about that old CMS (they are commercial and zend-encoded, so hardly somebody would ever want to hack it), we've already managed to upgrade those old servers to PHP 5.3 using CustomBuild 1.2, and most of the users are running PHP 5.3 and those users who need PHP 5.2. for the CMS do not use Joomla, WP, etc. That was long time ago, and CMS mentioned here are working only with PHP 5.2.9, and as you might know the latest release was 5.2.17, which for some reasons breaks that CMS.

Anyway that was mostly rhetorical question. That's not a problem to switch a server to a new PHP version. And what I like suPHP for, that we can install even more PHP versions without much efforts and make it to run smoothly. And leave those old commercial CMS with their PHP versions.
 
heh 5.2.17 (and iirc .14) broke many things for many people :p
iirc I was on 5.2.10 until able to go to 5.3 but I digress.

yeah these multiple php versions even w/o suphp make things very nice.
I have one php script thats pretty old that would take a ton of work to use 5.5 yet with 2 edits was ok on 5.4. so running that on 5.4 and others on 5.5 with php-fpm and apache proxy has helped a lot. and once I manually edited nginx file owncloud instance also runs very well on it.

need to start taking close look at 5.6 for some of my sites. think the one I really care about will be ok but need to check.
 
Last edited:
I got an issue with updating to php 5.3.29 on the pear section at the end.
These lines with errors appear:
Installing PEAR environment: /usr/local/lib/php/
PHP Warning: popen() has been disabled for security reasons in phar:///usr/local/directadmin/custombuild/php-5.3.29/pear/install-pear-nozlib.phar/OS/Guess.php on line 242
PHP Warning: fgets() expects parameter 1 to be resource, null given in phar:///usr/local/directadmin/custombuild/php-5.3.29/pear/install-pear-nozlib.phar/OS/Guess.php on line 243
PHP Warning: pclose() expects parameter 1 to be resource, null given in phar:///usr/local/directadmin/custombuild/php-5.3.29/pear/install-pear-nozlib.phar/OS/Guess.php on line 252

[PEAR] Archive_Tar - upgraded: 1.3.12
[PEAR] Console_Getopt - already installed: 1.3.1
[PEAR] Structures_Graph- already installed: 1.0.4
pear/pear dependency package "pear/XML_Util" downloaded version 1.2.3 is not the recommended version 1.2.1, but may be compatible, use --force to install
pear/XML_Util cannot be installed, conflicts with installed packages

[PEAR] XML_Util - upgraded: 1.2.3
[PEAR] PEAR - upgraded: 1.9.5
Wrote PEAR system config file at: /usr/local/etc/pear.conf

The lines in bold worry me. Do I need to worry or can I safely ignore this? If it needs to be fixed, how can this be done?
 
smtalk,

I'm not sure if I understand this correctly... Do you mean CB 2.0 will not support PHP 5.3 in CentOS 7/RHEL 7? I'm plan to start using CentOS 7 soon but still require PHP 5.3 support for some website. Really want to make sure if I should go with CentOS 7 or CentOS 6.

Thanks,


CB 2.0 will still support PHP 5.3 in the future (CentOS7/RHEL7 is the only exception) :) Thank you for your input!
 
Yes, that's true. RHEL7/CentOS7 requires patching of PHP 5.3 to install it and support systemd (for PHP-FPM). By the way, PHP 5.3 EOL date is "14 Aug 2014", meaning it will never support RHEL7/CentOS7 without the patching out-of-the-box. A dirty fix to install PHP 5.3 on RHEL7 (as mod_php, for PHP-FPM more patching would be needed) is (note: it is not officially supported):
Code:
cd /usr/local/directadmin/custombuild
mkdir -p custom/ap2
cp -pf configure/ap2/configure.php53 custom/ap2/configure.php53
perl -pi -e 's|--enable-intl|--enable-intl\nsed -i "/^BUILD_/ s/\\$\(CC\)/\\$\(CXX\)/" Makefile|g' custom/ap2/configure.php53

Then every time you run "build" to do anything with PHP, you need to run:
Code:
perl -pi -e 's|PHP1_RELEASE_SET="5.4 5.5 5.6"|PHP1_RELEASE_SET="5.3 5.4 5.5 5.6"|g' build
 
is systemd going to cause any issues with directadmin?
lot of controversy over systemd, personally I am pretty neutral on it at this point but am concerned about DA and other items.
would be a bit before I upgrade my 6.5 install to 7 I think.

edit: I just realized this question really isn't pertinent to this particular topic, so if mod wants to split it off I would appreciate it.
sorry, just the talk of systemd and php caught my eye.
 
Yes, that's true. RHEL7/CentOS7 requires patching of PHP 5.3 to install it and support systemd (for PHP-FPM). By the way, PHP 5.3 EOL date is "14 Aug 2014", meaning it will never support RHEL7/CentOS7 without the patching out-of-the-box. A dirty fix to install PHP 5.3 on RHEL7 (as mod_php, for PHP-FPM more patching would be needed) is (note: it is not officially supported):
Code:
cd /usr/local/directadmin/custombuild
mkdir -p custom/ap2
cp -pf configure/ap2/configure.php53 custom/ap2/configure.php53
perl -pi -e 's|--enable-intl|--enable-intl\nsed -i "/^BUILD_/ s/\\$\(CC\)/\\$\(CXX\)/" Makefile|g' custom/ap2/configure.php53

Then every time you run "build" to do anything with PHP, you need to run:
Code:
perl -pi -e 's|PHP1_RELEASE_SET="5.4 5.5 5.6"|PHP1_RELEASE_SET="5.3 5.4 5.5 5.6"|g' build

Thank you for your explanation. I will try to use PHP 5.4 on those websites and see how it goes, if it's ok, then, I will install CentOS 7 :)
 
pear/pear dependency package "pear/XML_Util" downloaded version 1.2.3 is not the recommended version 1.2.1, but may be compatible, use --force to install

For this one you can just give the following a try:
Code:
pear upgrade --force xml_util
 
Back
Top