• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

XenForo on PHP7

Alfa1

Well-known member
#1
I see that various people are experimenting with PHP7. @pegasus and @eva2000 @RoldanLT have been looking into it.
PHP7 introduces a 70 percent performance improvement.
See here for a comparison between PHP 7 and HHVM: https://community.centminmod.com/th...port-testing-for-centmin-mod-betas.892/page-3

Pegasus said:
I would advise against using PHP 7 in a production environment at the current time. VaultWiki 4 works with PHP 7, but there are still some serious bugs in PHP 7 that still result in random segfaults, infinite loops, and just unexpected behaviors. We have had to roll back to PHP 5.6 for a while.

On its own, XenForo 1.4 doesn't currently work perfectly with PHP 7. I never investigated if it's just a design conflict or if it's another PHP 7 bug, but you can't save most XenForo templates while using PHP 7 (segfault, always have to switch to PHP 5.6 for that).
RoldanLT said:
My XenForo forum is using this:
igbinary.ini
imagick.ini
memcache.ini
memcached.ini

That's the only reason I can't use PHP 7 on my Live Board attachFull90215
 

pegasus

Well-known member
#3
The only module I am using with it is Zend Opcache. I have noticed that the memcache(d) extensions haven't really offered any performance benefit (sometimes a hit) in my case since PHP 5.4, so I was not hesitant to drop them.

In particular I am struggling with one PHP 7 issue that started due to a particular commit (after using PHP 7 almost problem-free for several months), which now causes PHP to hang on many pages on my site. Even with all extensions (including Zend Opcache) removed, the only variants that work for me now are compiled with debug symbols. This is not a solution, since debug symbols are actually about a 100% performance hit compared to PHP 5.6.

I am still waiting to hear more debugging suggestions from the PHP devs, but it seems that right now they are just perplexed by this.
 
Last edited:

LPH

Well-known member
#5
I thought php 7.0 is not ready for a live production site. Did this change or are you just taking a step to the edge?

Regardless, I'd love to see performance differences between 5.5.9, 5.6, and 7.0.
 

Karelke

Active member
#9
Where is 6.0 in this story?
This should answer your question:

  • First and foremost, PHP 6 already existed and it was something completely different. The decimal system (or more accurately the infinite supply of numbers we have) makes it easy for us to skip a version, with plenty more left for future versions to come.
  • While it's true that the other PHP 6 never reached General Availability, it was still a very widely published and well-known project conducted by php.net that will share absolutely nothing with the version that is under discussion now. Anybody who knew what PHP 6 is (and there are many) will have a strong misconception in his or her mind as to the contents and features of this new upcoming version (essentially, that it's all about Unicode).
  • PHP 6, the original PHP 6, has been discussed in detail in many PHP conferences. It was taught to users as a done-deal, including detailed explanations about features and behavior (by php.net developers, not 'evil' book authors).
  • PHP 6 was widely known not only within the Internals community, but around the PHP community at large. It was a high profile project that many - if not most - PHP community members knew about.
  • There's lots of PHP 6 information, about the original PHP 6, that exists around the web. Books are the smallest part of the problem.
  • Unlike the 'trivia question' of 'why did we skip into 7?', reusing version 6 is likely to call real confusion in people's minds, with ample information on two completely different versions with entirely different feature sets that have the exact same name.
  • Skipping versions isn't unprecedented or uncommon in both open source projects and commercial products. MariaDB, jumped all the way up to version 10.0 to avoid confusion, Netscape Communicator skipped version 5.0 directly into 6.0, and Symantec skipped version 13. Each and every one of those had different reasons for the skipping, but the common denominator is that skipping versions is hardly a big deal.
  • Version 6 is generally associated with failure in the world of dynamic languages. PHP 6 was a failure; Perl 6 was a failure. It's actually associated with failure also outside the dynamic language world - MySQL 6 also existed but never released. The perception of version 6 as a failure - not as a superstition but as a real world fact (similar to the association of the word 'Vista' with failure) - will reflect badly on this PHP version.
  • The case for 6 is mostly a rebuttal of some of the points above, but without providing a strong case for why we *shouldn't* skip version 6. If we go with PHP 7, the worst case scenario is that we needlessly skipped a version. We'd still have an infinite supply of major versions at our disposal for future use. If, however, we pick 6 instead of 7 - the worst case scenario is widespread confusion in our community and potential negative perception about this version.
 

Chris D

XenForo developer
Staff member
#13
Might be worth trying to confirm which add-on caused that - also if any error messages. Obviously if there is anything else we need to change in XF we'd likely want to do that ASAP :)
 

Chris D

XenForo developer
Staff member
#15
Trying it beforehand might be beneficial, if you have a test server. I'm sure whoever's code is responsible for the crash might want the opportunity to fix it before more people start using PHP 7.
 

imthebest

Well-known member
#18
Imho it would be better to wait until XenForo 2.0 to upgrade to PHP7. At that moment PHP7 will be stable and officially supported plus the new add-ons being written for 2.0 will have compatibility for PHP7 as a must.

If you upgrade to PHP7 RC1 or whatever version of PHP7 using XenForo 1.5 you might have a very hard time trying to check whether each one of your add-ons works fine. It is just too much work...
 
Last edited: