Has anyone tested SMF 2.0.11 with php 7?
i really doubt it. i bet SMF 2.0 does not work well with it out of the box since it does not come with mysqli support.
it was checked by one person that I know of... and - as noted, has issues.
It is unlikely that 2.0.x will support php7 any time soon (if ever)
Would the same go for SMF 2.1?
SMF 2.1 does support mysqli, but there have not been detailed tests on php 7 to know how much does or does not work.
Just for discussion sake:
http://custom.simplemachines.org/mods/index.php?mod=3469
PHP 7.0.0 dropped today, hold off upgrading then? :)
Yes
I just tested it with SMF 2.0.11 and db_type mysqli in settings.php
this is the server-error i get
mod_fcgid: stderr: PHP Fatal error: Uncaught Error: Call to undefined function mysql_connect() in /[...]/Sources/Subs-Db-mysql.php:58, referer: https://www.mydomain.de/index.php
mysql_connect was deprecated in php5.5 and removed in php7 (see http://php.net/manual/en/function.mysql-connect.php)
So no PHP7 Support in SMF 2.0.x
Quote from: margarett on October 28, 2015, 10:18:01 AM
Just for discussion sake:
http://custom.simplemachines.org/mods/index.php?mod=3469
that should help you somewhat.
God dammit i should read thoroughly and drink more coffee in the afternoon.
nevermind.
Easy on the language please. It's a family friendly place here. ;) :)
Actually, no it doesn't help at all because of the differences in mysql and mysqli calling formats as well as specific references to mysql throughout.
did you APPLY the mod?
Arch Linux added php 7.0 as a default php in their repos today. I bit the bullet. Part of the services went down. Piwigo / SMF (with the error mentioned above) and few others.
Downgraded to previous version of the php-* packages, added php-* to the ignorepkg list for now. Installed the mysqli mod and changed Settings.php as mentioned above, restarted the mysqld, php-fpm and nginx. Everything is back up. At least next time I will upgrade the php-* packages I will be able to test the mysqli mod at work.
Cheers.
Andrzej
Mods can be incompatible with PHP7 but after adding MySQLi mod core forum working pretty well.
SMF should really be upgraded to use PDO, or at least MySQLi. The old MySQL extension has been deprecated for many many years now... MySQLi was released in 2004 and PDO was released in 2005. There's no reason to continue using the old extension. The entire database abstraction layer in SMF should probably be replaced with PDO at some point.
For now I'm running both PHP 5 and PHP 7 on my server. I've moved most sites over to PHP 7, but legacy software such as SMF is currently still on PHP 5.
smf 2.1 will work just fine with php7 and mySQLi commands
Quote from: Daniel15 on January 19, 2016, 01:30:40 AM
SMF should really be upgraded to use PDO, or at least MySQLi. The old MySQL extension has been deprecated for many many years now... MySQLi was released in 2004 and PDO was released in 2005. There's no reason to continue using the old extension. The entire database abstraction layer in SMF should probably be replaced with PDO at some point.
For now I'm running both PHP 5 and PHP 7 on my server. I've moved most sites over to PHP 7, but legacy software such as SMF is currently still on PHP 5.
I'm glad that you are already running php7, however please do note that not everyone (and by everyone I mean Linux distros and big hosting companies) is a fan of running the shiniest php versions out there (even if they are already marked as stable) come on! you should know this.
Making SMF 2.0.x compatible with PHP7 isn't as easy as you think it is, we still support pretty old PHP versions (and yes, people STILL use PHP 4). We just can't happily jump into the php7 wagon without making sure everyone will still be able to use SMF on whatever server configurations we told them SMF can work on.
SMF 2.1 is already using mysqli and it will be compatible with PHP7 the reason behind not going with PDO is simple, compatibility with SMF 2.0.
Quoteand yes, people STILL use PHP 4
Is it worth keeping the legacy code just for the very very few people that use PHP 4 though? I used to be on the customization team and work on the SMF code a lot (around the days of SMF 1.0 and 1.1 Beta) and there's a huge amount of technical debt in the older SMF code. It's baggage that doesn't belong in a modern application. PHP 4 is long gone now. In fact anything older than PHP 5.5 is not even supported by the PHP project any more. At some point you need to let go of the past and move on :)
Quoteplease do note that not everyone (and by everyone I mean Linux distros and big hosting companies) is a fan of running the shiniest php versions out there
Lots of people are upgrading to PHP 7, almost all major frameworks and quite a few major applications run out-of-the-box. All of the things that were removed in PHP 7 have been obsolete/deprecated for many years now, and any code that has been actively maintained during that time runs fine on PHP 7 with no modifications. None of it should be a surprise :) Examples include the POSIX regex functions (ereg) which have been deprecated since PHP 5.3 (2009), and the old MySQL extension which has been deprecated since the release of MySQLi with MySQL 4.1 (2004) and PDO (2005). People aren't going to hold off upgrading just because SMF doesn't support it, especially when all other software on their server runs on PHP 7 with no issues.
Back in the SMF 1.0 era it made sense to use PHP 4 compatible code, but today I doubt you'll find
anyone in the wild still running PHP 4.
We have a higher requirement for minimum versikns in 2.1
We are not going to do that sort of change in the 2.0.x path
Quote from: Daniel15 on January 19, 2016, 06:16:05 PM
I used to be on the customization team and work on the SMF code a lot
Thats cool to know as it means you do fully understand the size of SMF and therefore, you know its not that easy to do a full rewrite, now combine that with the hassles of any open source projects.
Quote from: Daniel15 on January 19, 2016, 06:16:05 PM
Quoteand yes, people STILL use PHP 4
It's baggage that doesn't belong in a modern application. PHP 4 is long gone now. In fact anything older than PHP 5.5 is not even supported by the PHP project any more. At some point you need to let go of the past and move on
Thank you, but you see, we already know all of that ;) what you say its nothing new, we are pretty aware of whats happening outside and from time to time people come to tell us exactly the same as you and then we proceed to explain the huge mammoth that is SMF and lack of manpower etc etc etc... then we proceed to ask people to actually help us and thats usually when they mysteriously disappear.... ;)
Quote from: Daniel15 on January 19, 2016, 06:16:05 PM
Lots of people are upgrading to PHP 7, almost all major frameworks and quite a few major applications run out-of-the-box.
Please do note that I specifically said OS and hosting providers ;) I know many projects are jumping in and thats great! good for them! on the other hand its going to be a while before php7 becomes mainstream.
Our priority is release 2.1, next goal is making 2.0.x compatible with php7 via a patch.
Again, we aren't against upgrading, we aren't fond of php4 and we aren't ignoring whats going on either... but please try to understand that we cannot automagically release a full rewrite fully compatible with cutting edge software by tomorrow... its unrealistic...
The decisions we made has been made thinking about all angles, all factors, yes php4 is fugly.... yes we should be targeting 5.6.... yes PDO yes DI yes... unit tests..... yes modularization.... yes {insert framework name here} ... etc etc etc... but we still have a pretty, massive, huge codebase to maintain.
Quotebut please try to understand that we cannot automagically release a full rewrite fully compatible with cutting edge software by tomorrow... its unrealistic...
Totally understandable :) The wording in my original comment was probably overly harsh. I didn't mean to sound like I was attacking you or anything :)
Is there a list of known incompatibilities with PHP 7 (ie. stuff that actually breaks)? I'm happy to hack on some of them if I get some free time.
Theres a PR that handles the session restrictions: https://github.com/SimpleMachines/SMF2.1/pull/3230
It coverts almost everything I believe but I gotta yet to create a test environment with php7 to test that PR more.
My server was upgraded to php7 today by the host, and it broke SMF 2.0.11 for me. Searching led me here and changing mysql to mysqli didn't fix the problems. Going to have to try out 2.1.
Quote from: wicked1 on January 27, 2016, 09:41:43 PM
My server was upgraded to php7 today by the host, and it broke SMF 2.0.11 for me. Searching led me here and changing mysql to mysqli didn't fix the problems. Going to have to try out 2.1.
You need to ask your host to downgrade to php5.5 (or similar) then apply the MySQLi modification then go back to php7. You cannot solve your problem just changing mysql to mysqli in settings.php
Do note: Modifications without mysqli support also breaks down your forum. You need to ask mod authors to update their mods.
About SMF 2.1, its still in development stage, unless you are comfortable with debugging and finding bugs I strongly suggest you not to upgrade to SMF 2.1.
PHP 5 is not available in Ubuntu 16.04 LTS Server: how to run SMF with Ubuntu 16.04 ?
Quote from: http://blog.dustinkirkland.com/2016/04/php7-in-ubuntu-16.04-lts.htmlAs such, PHP7 will be the only version of PHP supported in Ubuntu 16.04 LTS.
If you have a hard dependency on PHP5, then you should either remain on Ubuntu 14.04 LTS (Trusty), which is supported for another 3 years.
Downgrade to older version of 14.04 LTS (Trusty)
Current SMF will not work on php7
I was planning to upgrade to 16.04, still planning though, just waiting til the kinks are worked out by the early adapters. :laugh:
Not fond of the stock options, it is still a good OS with a few tweaks. I hope they got rid of that Ubuntu Software Center, I read they where.
Yeah, looks like PHP 5 is dead for now in 16.04, someone will add it though, maybe, just have to wait.
Active support for PHP5.6 upstream ends Dec. 31, 2016.
Security support for PHP5.6 upstream ends Dec. 31, 2018.
For those under Ubuntu server 15.10 , migrating to Ubuntu 16.04 (and PHP7) must be completed before July 2016 (end of security support for ubuntu server 15.10)
Hello everyone,
My web host plans to remove PHP5 in January 2017.
The developement of a compatibility patch (like PHP 5.5) is planned?
I reminds SMF 2.0.7 is not a security release but an update to brings full compatibility for PHP 5.5
It would be nice to offer the same for PHP 7.0, as SMF 2.1 will not be released until 2018.
Benoît
Yes, support for php 7 within SMF 2.0.x is on our plans.
No, there is no set date for SMF 2.1
Thanks for update glad to hear 7.0 support for SMF 2.0.x
Thank you for supporting PHP 7 on SMF 2.0.
Speaking of evolution of the Internet, will it be possible to support IPv6 on SMF 2.0 ?
There are many traps for those using IPv6 with SMF 2.0
Benoît
There is a mod
http://custom.simplemachines.org/mods/index.php?mod=3051
We looked forward for the PHP patch 7 SMF 2.0
@vbgamer45 For IPv6, the mod http://custom.simplemachines.org/mods/index.php?mod=3051 is unmaintained and is not compatible with the latest versions of SMF 2.0
vivien,
almost any mod for 2.0.x is usable on any other 2.0.x version. That mod is just fine.
I try use PHP 7 with myboard (smf 2.0.11)
I use mod
http://custom.simplemachines.org/mods/index.php?mod=3469
And
function isReservedName() in Sources/Subs-Members.php Not Support PHP 7
because I think
In PHP 7, foreach does not use the internal array pointer.
How to fix I use Sources/Subs-Members.php in smf 2.1.0 Beta isReservedName() function on Only.
Quote from: Suki on June 27, 2016, 03:13:49 PM
Yes, support for php 7 within SMF 2.0.x is on our plans.
Any news when this might be available (officially)?
No news, there are plans but there are other other items that needs to be addressed first.
After updating my OS from Ubuntu 14.04.4 LTS to 16.04.1 LTS and PHP 7 I ran into the mysqli issues described earlier in this thread. Here's a quick summary of what I've done to fix the issues for anyone else who bumps into them:
I manually installed this mod: http://custom.simplemachines.org/mods/index.php?mod=3469. I also had to add "$db_type = 'mysqli';" to Settings.php to make it all work.
From there I saw a consistent pair of error messages in my error log:
QuoteUnknown: Session callback expects true/false return value
To fix this error I had to edit Sources/Load.php to make the changes described here:
https://github.com/SimpleMachines/SMF2.1/commit/dd4222bc9af04355db14c5cdf0925e24ea791eaf
QuoteUnknown: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/sessions)
I still haven't figured this one out. The value for session.save_path is correct, for now I have permissions set to 777, and the error still appears. Any thoughts?
Quote from: sah62 on August 07, 2016, 11:11:22 AM
QuoteUnknown: Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/sessions)
I still haven't figured this one out. The value for session.save_path is correct, for now I have permissions set to 777, and the error still appears. Any thoughts?
Some progress: I found information describing a bug in PHP related to the warning message:
https://bugs.php.net/bug.php?id=71070
The implemented bug fix returns a different message ("Failed to write session data using user defined save handler") if there's a custom save handler involved. That got me looking at the sessionWrite function in Load.php; the warning is triggered if this function returns boolean false. The SMF 2.1 patch described above makes this change:
- return $result;
+ return ($smcFunc['db_affected_rows']() == 0 ? false : true);
}
So now this looks like a situation in which the attempt to either add a row to the session table or update an existing row has failed. How might that happen?
Quote from: sah62 on August 09, 2016, 12:21:58 PM
So now this looks like a situation in which the attempt to either add a row to the session table or update an existing row has failed. How might that happen?
More progress: with a little more digging I discovered (http://stackoverflow.com/a/5389008) that you can't depend on $smcFunc['db_affected_rows']() to produce a non-zero value if you're using mysql. The sessionWrite function uses the value returned from $smcFunc['db_affected_rows']() to determine the return value for the function; that's probably not the right thing to do. Here's a fix to the code in the sessionWrite function:
- if ($smcFunc['db_affected_rows']() == 0)
+ if ($result == false)
$result = $smcFunc['db_insert']('ignore',
'{db_prefix}sessions',
array('session_id' => 'string', 'data' => 'string', 'last_update' => 'int'),
array($session_id, $data, time()),
array('session_id')
);
- return $result;
+ return ($result == false ? false : true);
Hello,
SMF 2.0.11 on PHP 7 didn't detect ACPu, OPCache or Memcached.
Is it possible to solve?
Another thread, for SMF 2.0.11 and PHP 7 : http://www.simplemachines.org/community/index.php?topic=548881
This is from the other thread :
QuotePerhaps. The good news is it shouldn't be a discussion point for much longer as we will be PHP 7 compatible soon. Locked for now :). Enjoy the holidays all.
Anyone know how soon 2.0.x will be PHP 7 compatible?
This forum software is the only thing holding me back from upgrading. The new PHP version is so much faster and uses less memory than the 5.x version.
We still working on it, but we never give dates for upcoming releases. If we don't have any setback, the release will be soon.
Has anyone actually benchmarked the memory usage and speed specifically for SMF on 5.6 vs 7 for those who've done the tweaking? Sure, for heavy class use PHP-NG will outperform Zend Engine 2.x. SMF doesn't heavily use classes. Ditto on variable allocation and garbage collection; most of SMF's variables are globally allocated and reused, plus a fair amount of stuff passed around by reference which was always faster anyway.
In reality, the bottleneck on SMF has been the database for years now and you need to be up into the millions of posts category before that starts to change, and there are many more things you can do before that to improve the situation. I don't really see PHP 7 changing it nearly as much as people think, but once I see actual benchmarks, maybe that'll be different.
To be honest, I'm not concerned about the performance or memory savings with SMF and PHP 7. It runs great for me right now.
However, I am concerned about how much of a performance boost it will give my other projects running on this dedicated server. I'm looking at almost 3x the speed boost with pretty big memory savings. Of course none of this can happen until SMF 2.0.x is PHP 7 compatible ...
Quote from: Arantor on January 02, 2017, 06:33:34 PM...
It's not about performance but support.
PHP5 is getting more obsolete day by day.
Ubuntu 14.04 is the last Ubuntu now that can run SMF - and while there is still 2 years of support, SMF 2.1 has been in the works for several long years now.
I am very thankful for every contributor's work, and I don't really care about the new version, just saying that time is running out.
That was an answer to a comment two months ago about performance. Please don't take it out of context to misrepresent it.
Hey guys, hate to pile on here but many older versions of CPanel will end their support lifespan on March 31st, 2017. And they won't be supporting some 32 bit operating systems anymore like CentOS6 after that date. What this means is that tons of people are having to migrate to 64 bit machines with new CPanel versions and don't even have the option for php 5.x as far as I know. If it is an option it's a messy one. Would be awesome if smf could support 7.0 soon.
I def appreciate the work you guys put in.
And, as has alreayd been stated, when 2.0.14 is released, it will
As the OP's question has been asked and answered (amongst other questions) I'll go ahead and mark this solved.