PHP7
Permalink 1 user found helpful
Hi,
Has somebody have C5 running on PHP7 yet?
I want to run C5 in PHP7 (or at least test it) due to performance issues.
SnefIT
Has somebody have C5 running on PHP7 yet?
I want to run C5 in PHP7 (or at least test it) due to performance issues.
SnefIT
There has been preliminary testing, c5 generally works, but issues are still being fixed.
I had used version 5.6.3.1 for an old project. I upgraded my development server to PHP 7 a few hours ago. In first try I can see it fails because of "mysql" functions used in adodb:
I don't have time to make any further investigation yet. I'll add a comment here when I can find time to collect more observations.
PHP Fatal error: Uncaught Error: Call to undefined function mysql_connect() in /concrete/libraries/3rdparty/adodb/drivers/adodb-mysql.inc.php:442
I don't have time to make any further investigation yet. I'll add a comment here when I can find time to collect more observations.
Mysql no longer exists in new versions of PHP. The latest 5.6.3.4 version added support for mysqli for just this very reason. Upgrade to that version and see how you go.
It might be tricky to upgrade with PHP 7, so if it won't fly, try extracting the concrete folder from the 5.6.3.4, and replacing the 5.6.3.1 version that's in place and then running /index.php/tools/required/upgrade.
It might be tricky to upgrade with PHP 7, so if it won't fly, try extracting the concrete folder from the 5.6.3.4, and replacing the 5.6.3.1 version that's in place and then running /index.php/tools/required/upgrade.
Thank you for informing. I'll try that and let you all know the result asap
I think Not all the 3rd party bits are php7 ready yet.
On 10 december 2015 08:28:40 concrete5 Community
<discussions@concretecms.com> wrote:
On 10 december 2015 08:28:40 concrete5 Community
<discussions@concretecms.com> wrote:
Bored last night so thought I'd try building php 7.0.0 from source. Unfortunately I get an exception:
Whoops \ Exception \ ErrorException (E_WARNING)
Declaration of Concrete\Core\Attribute\Key\CollectionKey::getList() should be compatible with Concrete\Core\Attribute\Key\Key::getList($akCategoryHandle, $filters = Array) (this is with 5.7.5.3)
This is happening even when phpinfo() is telling me that error_reporting is 0, i.e. completely off.
Whoops \ Exception \ ErrorException (E_WARNING)
Declaration of Concrete\Core\Attribute\Key\CollectionKey::getList() should be compatible with Concrete\Core\Attribute\Key\Key::getList($akCategoryHandle, $filters = Array) (this is with 5.7.5.3)
This is happening even when phpinfo() is telling me that error_reporting is 0, i.e. completely off.
Having pulled 5.7.5.4 from github (5.7.5.4b1 apparently) that error is gone and the home page renders. I was able to edit the page and save without error, so the basic functions appear to be there.
At the risk of droning on, I did a few performance tests using my crufty old linux box. I logged the elapsed time for the main index.php to run when rendering the home page of a default C5.7 install.
PHP 5.3, all C5 caches OFF- 1.8 seconds
PHP 5.3 all C5 caches ON- 0.7 seconds
PHP 7.0 all C5 Caches OFF- 0.86 seconds
PHP 7.0 all C5 Caches OFF, Zend Opcache enabled - 0.4 seconds
PHP 7.0 all C5 Caches ON, Zend Opcache enabled - 0.18 seconds
PHP 5.3, all C5 caches OFF- 1.8 seconds
PHP 5.3 all C5 caches ON- 0.7 seconds
PHP 7.0 all C5 Caches OFF- 0.86 seconds
PHP 7.0 all C5 Caches OFF, Zend Opcache enabled - 0.4 seconds
PHP 7.0 all C5 Caches ON, Zend Opcache enabled - 0.18 seconds
@jero
You aren't droning on at all, I know myself and many others really appreciate you sharing your PHP 7 benchmarks.
The concrete5 performance boost from PHP 7 is even better than I expected.
Using a shared host with PHP 5.6, GZIP, expire headers, and concrete5 caching I see under 1 second load times using the Elemental theme with sample content.
https://www.concrete5.org/community/forums/chat/are-sub-second-time-...
This should mean that larger, heavier sites should hit that 1 second load time using basic optimization and proper design, and not require more aggressive caching like Varnish. Varnish would then be needed for just the truly large and heavy sites.
You aren't droning on at all, I know myself and many others really appreciate you sharing your PHP 7 benchmarks.
The concrete5 performance boost from PHP 7 is even better than I expected.
Using a shared host with PHP 5.6, GZIP, expire headers, and concrete5 caching I see under 1 second load times using the Elemental theme with sample content.
https://www.concrete5.org/community/forums/chat/are-sub-second-time-...
This should mean that larger, heavier sites should hit that 1 second load time using basic optimization and proper design, and not require more aggressive caching like Varnish. Varnish would then be needed for just the truly large and heavy sites.
@jero Wow, this is impressive. Thanks for sharing. I'd like to see the final stats once we get an upgrade with an official notice of compatibility. I imagine it will be similarly impressive, and this is in my opinion enough of a performance increase to motivate upgrading to PHP 7.
Well done!
Well done!
I was able to do some benchmarking as well and posted my findings about it. With the latest version of concrete5 it certainly seems usable and with opcache most pages load in 1/4 the time they would with say PHP 5.3
https://www.exchangecore.com/blog/php-performance-concrete5-version-...
https://www.exchangecore.com/blog/php-performance-concrete5-version-...
@exchangecore
Nice job on the PHP 7 benchmarking, it was very thorough.
Thehttp://c5sandbox.exchangecore.com/... demo site loaded really fast.
Is the demo running on regular shared hosting or an expensive VPS?
Nice job on the PHP 7 benchmarking, it was very thorough.
Thehttp://c5sandbox.exchangecore.com/... demo site loaded really fast.
Is the demo running on regular shared hosting or an expensive VPS?
I've now got 7 running on one of my blade servershttp://c57.jero.nz/index.php These are quad dual core Xeon 2.66 with 8GB RAM and RAID 1 spinning rust. Most cached pages are rendering in around 0.11 seconds, but some of the blog entries manage 0.027 - *27* milliseconds. Webpagetest.org actually managed a B rating for time to first byte.http://www.webpagetest.org/result/151219_KH_ACC/...
@MrKDilkington as mentioned in the blog it's running on a shared hosting account.
I was curious about apples to apples with jero's a-builtiful-blog request so I figured I'd toss that one up here too:http://www.webpagetest.org/result/151220_HG_5P8/... Results times weren't quite as low as jero's blade servers but even still I think it's pretty clear that PHP7 is a major boost to performance.
I was curious about apples to apples with jero's a-builtiful-blog request so I figured I'd toss that one up here too:http://www.webpagetest.org/result/151220_HG_5P8/... Results times weren't quite as low as jero's blade servers but even still I think it's pretty clear that PHP7 is a major boost to performance.
From which 5.7-version will it be PHP7 ready? I did a quick test an turned on PHP7 on a 5.7.5.3 version. But it did not rendered.
You would need to download 5.7.5.4.b1 - a **BETA** release. That does at least render the page but there are other problems with it and it's not ready for production. Best bet is to wait for the next official release, unless you want to experiment on a test site.
Thanks for your answer! So id needs some patience. Concrete5 needs that performance boost.
So I will be happy when it's coming.
So I will be happy when it's coming.
5.7.5.4 is now available for download or upgrade
https://www.concrete5.org/download_file/-/view/85488/...
Under Developer Updates:
Code improvements to facilitate concrete5 running on PHP 7 (thanks mlocati)
Thus far it seems to be true. :)
https://www.concrete5.org/download_file/-/view/85488/...
Under Developer Updates:
Code improvements to facilitate concrete5 running on PHP 7 (thanks mlocati)
Thus far it seems to be true. :)
PHP 7, TWIG and bootstrap 4 in the core, any thought on that?
I'm getting Controller::registerViewAssets() errors when running php7
The above is for the pagelist plus block, but i'm getting them for several blocks. Also a theme is giving an error. Asked for support already, but i thought to share this experience with testing on php7.
Declaration of Concrete\Package\SkybluesofaPageListPlus\Block\PageListPlus\Controller::registerViewAssets() should be compatible with Concrete\Core\Block\BlockController::registerViewAssets($outputContent = '')
The above is for the pagelist plus block, but i'm getting them for several blocks. Also a theme is giving an error. Asked for support already, but i thought to share this experience with testing on php7.
buurvrouw, you need to contact the PageListPlus add-on developer about this, this isn't a problem in the core.
Yes i know. I already did so. But i'm running into this with more add-ons then just the page-list plus. So i thought i'd share this experience for people wanting to upgrade to php7.
This is actually a problem that everybody is going to have with the new C5 versions. There was an undocumented change.
If in any block you use the function
You have to modify it like the error says to
If in any block you use the function
public function registerViewAssets() {}
You have to modify it like the error says to
public function registerViewAssets($outputContent = '') {}
It is true that this is a change: add-on developers will want to add that argument to that function, if they use it in their block's. We should have added this to the version history.We had to make some of the core code stricter in order to work without incident on PHP7.
However, this should only be an issue with running these add-ons on PHP7, and I imagine you could get around it by implementing some PHP error suppression as well, in the meantime.
However, this should only be an issue with running these add-ons on PHP7, and I imagine you could get around it by implementing some PHP error suppression as well, in the meantime.
I confirm it breaks only in PHP 7.
I don't know if error suppression is the way to go.
I found out about this because a buyer of my add-ons couldn't get my stuff to work. Not the best way to find out.
He was on PHP7 and there's going to be more and more of those very soon I think.
Much better to get the important information straight from the horse's mouth (that makes you the horse Andrew :) and act accordingly.
I don't know if error suppression is the way to go.
I found out about this because a buyer of my add-ons couldn't get my stuff to work. Not the best way to find out.
He was on PHP7 and there's going to be more and more of those very soon I think.
Much better to get the important information straight from the horse's mouth (that makes you the horse Andrew :) and act accordingly.
On a different note, I have an add-on (Buttons Pro) that processes a bunch of less files to generate a css.
On PHP 5.6.x it takes around 11 seconds.
On PHP 7 it takes 3 seconds.
On PHP 5.6.x it takes around 11 seconds.
On PHP 7 it takes 3 seconds.
