mysql_fetch_assoc() error (suggested fix attached)

[sts_pro]

Hello everyone,

My board is quite old and has been updated to 2.0.15 by means of several patches So this issue could be specific to my environment only.

However, I will describe what I noticed:

- Due to complains from WP on older PHP version I switched to PHP 7.0
- After this change ?action=profile;area=subscriptions started to return following error: "mysql_fetch_assoc() not found" (or similar)
- As per https://www.php.net/manual/en/function.mysql-fetch-assoc.php [nofollow] "This extension was deprecated in PHP 5.5.0, and it was removed in PHP 7.0.0"
- So, I changed PHP to 5.4 which removed error message, however, introduced new problem - Instead of list of active subscriptions I was always getting "You haven't set up any subscriptions yet."
- Few hours later I finally found a solution here https://stackoverflow.com/questions/8521543/warning-mysql-fetch-assoc-expects-parameter-1-to-be-resource-object-given [nofollow]

Please see attached a little extension which fixes mysql_fetch_assoc calls in Profile-Actions.php and ModReport.php and also allows to use PHP 7.0.

Note: there is another issue I found and which I haven't fixed yet. If user has multiple subscriptions only the fist one is being displayed and without subscription name. As I rarely has users with multiple subscriptions I don't think I will find time fixing this issue anytime soon

[Aleksi "Lex" Kilpinen]

This should not be a problem in 2.0 if the code is updated properly. Do you have any mods installed that deal with subscriptions? Are you sure the patches were installed without errors?

[sts_pro]

This should not be a problem in 2.0 if the code is updated properly.

I was originally using version 2.0.7, so it was always higher than 2.0...

Do you have any mods installed that deal with subscriptions?

Well could caused by other mods... Some of the currently installed modes are not supported by newer SMF versions, some of the mods are not even available for downloads anymore...  This is why I stuck with an older installation and not ready to perform a clean install with migration of all of the mods and users

Are you sure the patches were installed without errors?

It was a tricky pass of patching with a lot of different errors, which I eventually overcame

I guess I could try creating a separate clean install to confirm if this is a bug at all. Just wanted to share a solution in case someone else is experiencing similar issues.

[Arantor]

Except that in 2.0.14 full PHP 7 support was added and no bare code should ever have been using mysql_fetch_assoc directly.

[Aleksi "Lex" Kilpinen]

I guess I could try creating a separate clean install to confirm if this is a bug at all.

What I tried to say was that it most likely isn't. Now, what it is - without knowing what mods you have, can't say for sure, but I think it would be likely some mod that alters the subscriptions area, or deals with subscriptions in some way.

[sts_pro]

Fair enough. I think I will try clean install for 2.1 once it is finally released Hopefully migration will go smoothly

[shawnb61]

Except that in 2.0.14 full PHP 7 support was added and no bare code should ever have been using mysql_fetch_assoc directly.

^^ This.

There are no stray mysql calls or many users would have been having such issues since 2.0.14, which is a couple years old at this point.  (I've been running 2.0.15 vs php7.1 for over a year now.)

There are issues with your forum's code.

I would suggest refreshing your forum code with vanilla 2.0.15 & reinstalling your mods.  Preferably in a test copy of your forum first, to allow for testing & experimentation.  That would help you narrow down which set of changes caused the issue. 

I am going to move this over to the fixed/bogus forum board, as it does not appear to be a bug. 

[SpacePhoenix]

Use Notepad++ or a similar program and have it search all files for "mysql_fetch_assoc()"

[shawnb61]

Use Notepad++ or a similar program and have it search all files for "mysql_fetch_assoc()"

...and you'll find that it exists only in Subs_Db_mysql.php.  Where it is used conditionally.

if SMF detects mysqli, it will use mysqli exclusively.  If not, it will fall back on mysql calls exclusively.  But it is either one or the other, never a mix of both. 

[SpacePhoenix]

Use Notepad++ or a similar program and have it search all files for "mysql_fetch_assoc()"

...and you'll find that it exists only in Subs_Db_mysql.php.  Where it is used conditionally.

if SMF detects mysqli, it will use mysqli exclusively.  If not, it will fall back on mysql calls exclusively.  But it is either one or the other, never a mix of both.

Nope, if you search for "mysql_fetch_assoc(" as that exact string you'll find that it doesn't exist

[shawnb61]

Nope, if you search for "mysql_fetch_assoc(" as that exact string you'll find that it doesn't exist

That's because SMF never calls these functions directly.

In vanilla code, look at line #44 (the mysql call) and also at line #770 (the mysqli call).   SMF never calls mysql_fetch_assoc directly.  It calls $smcFunc['db_fetch_assoc']() instead. 

That's why we're certain that the direct calls to mysql_fetch_assoc in the OP above are due to a mod.  A mod that didn't properly use smcFunc, hence, was more vulnerable to recent php version support changes.  The proper fix is for that mod to cutover to using $smcFunc.