News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

SMF 2.0.14 Released

Started by Colin, May 14, 2017, 05:16:14 PM

Previous topic - Next topic

ILUXA

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

Thank you for all the work done, I upgraded

alexetgus

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


Thanks for PHP7 support! :)

Colin

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?
"If everybody is thinking alike, then somebody is not thinking." - Gen. George S. Patton Jr.

Colin

Linkjay

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
I play games in my free time and volunteer my knowledge and support to the gaming communities of the internet.

You can contact me by these methods:
Use my Contact Script • PM me here • Add me on Steam

Hurga

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

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

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 PMPlease 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

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

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...?

Apllicmz




ian

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:


$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

Yes, it requires PHP 5.4.

Colin

If you need more help feel free to create a topic. Simply ask your host to upgrade to PHP 5.4 or higher.
"If everybody is thinking alike, then somebody is not thinking." - Gen. George S. Patton Jr.

Colin

digger

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

a mistake was made, we are aware of it.

ian

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.


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

vbgamer45

yes security updates site speed are huge benifits for new php versions
Community Suite for SMF - Take your forum to the next level built for SMF, Gallery,Store,Classifieds,Downloads,more!

SMFHacks.com -  Paid Modifications for SMF

Mods:
EzPortal - Portal System for SMF
SMF Gallery Pro
SMF Store SMF Classifieds Ad Seller Pro

Colin

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.


// 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.
"If everybody is thinking alike, then somebody is not thinking." - Gen. George S. Patton Jr.

Colin

Arantor

QuoteAm 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

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

Advertisement: