Author Topic: SMF 2.0.14 Released (Read 989598 times)

ILUXA · « **Reply #80 on:** May 19, 2017, 08:46:06 PM »

I understood, but IMO few offtop messages can be easelly removed by moderators (or by message authors) at any time

Anyway, thanks to all for developing SMF! It is a great forum engine!

rogrog · « **Reply #81 on:** May 20, 2017, 04:24:55 PM »

Thank you for all the work done, I upgraded

alexetgus · « **Reply #82 on:** May 21, 2017, 01:20:05 AM »

This proxy is a mistake, a huge mistake!

Don't use it!

Thanks for PHP7 support!

Colin · « **Reply #83 on:** May 21, 2017, 02:21:55 AM »

Quote from: alexetgus on May 21, 2017, 01:20:05 AM

This proxy is a mistake, a huge mistake!
Don't use it!

Thanks for PHP7 support!

Hmm, why is it a mistake?

Linkjay · « **Reply #84 on:** May 21, 2017, 03:01:33 AM »

Quote from: alexetgus on May 21, 2017, 01:20:05 AM

This proxy is a mistake, a huge mistake!
Don't use it!

I happen to think the Proxy is one of the best SMF features right now... Especially considering how easy it is to implement in your scripts within and externally from SMF.

Not sure if you're trying to be funny or something. lol

Hurga · « **Reply #85 on:** May 21, 2017, 10:34:48 AM »

Had a small issue with the update... new users couldn't register anymore, the forum logged the error message

Code: [Select]

Database Error: Field 'timezone' doesn't have a default value
File: /home/forum/smf/Sources/Subs-Members.php
Line: 771

Field 'timezone' from smf_members had a NULL default, setting default to 'Europe/Berlin' fixed this. After that, I had to set defaults for timezone_offset and timezone_update too (I used 0).

All seems to be fine now. - Am I the only one who was bitten by this, or did I do something wrong...?

Illori · « **Reply #86 on:** May 21, 2017, 10:58:23 AM »

Quote from: Steve on May 18, 2017, 03:43:45 PM

From the first post:

Quote from: Colin on May 14, 2017, 05:16:14 PM
Please do not use this topic for support requests.
You will receive a much quicker and better response by posting in the 2.0.x Support Board ...

Hurga · « **Reply #87 on:** May 21, 2017, 07:50:10 PM »

Read more closely. Since all is fine (for me) now, that was somewhat obviously not a support request. It's more like a heads-up that there might be circumstances under which the 2.0.14 update has issues. Do with it whatever you want.

Shambles · « **Reply #88 on:** May 22, 2017, 03:03:25 AM »

Quote from: Hurga

... that was somewhat obviously not a support request ...

You asked for confirmation that what you did was correct. That's a support request

Quote from: Hurga

...Am I the only one who was bitten by this, or did I do something wrong...?

Joomlamz · « **Reply #89 on:** May 22, 2017, 03:03:48 PM »

yes
thank you
Nice work

ian · « **Reply #90 on:** May 23, 2017, 11:45:32 AM »

Thanks for the update. Unfortunately, it stopped my forum working. After upgrading from 2.0.13, every request failed with a "Function name must be a string..." error message on this line in the reloadSettings function in Load.php:

Code: [Select]

		$request = $smcFunc['db_query']('', '
			SELECT variable, value
			FROM {db_prefix}settings',
			array(
			)
		);

The problem seems to be caused by the new SMF_DB_MySQLi class, which is setting db_query to an array instead of a string. I have disabled that class in smf_db_initiate for now, and the forum is working again.

I'm running Centos 6 with its default PHP 5.3.3. Perhaps the new SMF_DB_MySQLi class's smcFunc settings require a higher PHP version?

Arantor · « **Reply #91 on:** May 23, 2017, 11:49:43 AM »

Yes, it requires PHP 5.4.

Colin · « **Reply #92 on:** May 23, 2017, 06:57:42 PM »

If you need more help feel free to create a topic. Simply ask your host to upgrade to PHP 5.4 or higher.

digger · « **Reply #93 on:** May 24, 2017, 08:59:52 AM »

Why upgrade script says that release requires at least PHP 5.3 if it really need PHP 5.4 to work? Everyone who updated forum with php 5.3 get it broken after.

Illori · « **Reply #94 on:** May 24, 2017, 09:03:24 AM »

a mistake was made, we are aware of it.

ian · « **Reply #95 on:** May 24, 2017, 12:12:19 PM »

Disabling the SMF_DB_MySQLi class seems to be working fine. Am I missing anything important by not having PHP 5.4? If not, I hope the next SMF update will restore support for lower PHP versions by disabling the SMF_DB_MySQLi class itself if the version is lower than 5.4.

Code: [Select]

	// Checck for MySQLi first...
	if (function_exists('mysqli_connect') && @version_compare(PHP_VERSION, '5.4') >= 0)

vbgamer45 · « **Reply #96 on:** May 24, 2017, 12:17:08 PM »

yes security updates site speed are huge benifits for new php versions

Colin · « **Reply #97 on:** May 24, 2017, 12:26:42 PM »

Quote from: ian on May 24, 2017, 12:12:19 PM

Disabling the SMF_DB_MySQLi class seems to be working fine. Am I missing anything important by not having PHP 5.4? If not, I hope the next SMF update will restore support for lower PHP versions by disabling the SMF_DB_MySQLi class itself if the version is lower than 5.4.

Code: [Select]
// Checck for MySQLi first... if (function_exists('mysqli_connect') && @version_compare(PHP_VERSION, '5.4') >= 0)

Don't plan on it. Please update your PHP.

Arantor · « **Reply #98 on:** May 24, 2017, 12:47:08 PM »

Quote

Am I missing anything important by not having PHP 5.4?

Only that your server is fundamentally insecure as PHP themselves don't support PHP 5.4, or 5.5 for that matter.

ian · « **Reply #99 on:** May 24, 2017, 01:06:30 PM »

RHEL/Centos 6 is still supported by Redhat, who backport security fixes to their packages*. RHEL/Centos 6 is still used by a lot of people, so I don't think it would be a good idea to drop support for PHP versions below 5.4 unless there is no way around it. In this case, there does seem to be a way around it (disable the SMF_DB_MySQLi class for lower PHP versions).

* https://access.redhat.com/security/updates/backporting

News:

Author Topic: SMF 2.0.14 Released (Read 989598 times)