[TP 1.0] problem with database request after upgrading to SMF 2.0.14

[perkele]

Hello!

We recently upgraded our forum from SMF 2.0.10 all the way up to 2.0.14 with patches.

Most things seem to be working fine now. However, I stumbled upon this strange issue with TinyPortal (1.0 - I guess that is outdated, maybe I should upgrade that, too).

We have set up the portal frontpage to show selected articles and selected topics which were promoted to the frontpage.

But strangely, after the upgrade to SMF 2.0.14, only the articles were shown on the frontpage, not the promoted topics anymore. (But the pagination was still divided as if there were missing topics/articles that should be shown.)

So after some fiddling with the code and tracing back where things get lost, and trying and comparing for quite a long time, I found a solution. But I don't know really what it means.


This is a shortened extract from TPortal.php (TinyPortal version 1.0), as it was before I changed it now:

Code: [Select]

// do the frontpage
function doTPfrontpage()
{
global $context, $scripturl, $user_info, $modSettings, $smcFunc;

// ... a lot of stuff ...

if(count($mposts) > 0)
$request =  $smcFunc['db_query']('', '
SELECT m.subject,
' . ($context['TPortal']['frontpage_limit_len'] > 0 ? 'LEFT(m.body,' . $context['TPortal']['frontpage_limit_len'] . ') as body' : 'm.body') . ',
IFNULL(mem.real_name, m.poster_name) AS realName, m.poster_time as date, mem.avatar, mem.posts, mem.date_registered as dateRegistered, mem.last_login as lastLogin,
IFNULL(a.id_attach, 0) AS ID_ATTACH, a.filename, a.attachment_type as attachmentType, t.id_board as category, b.name as category_name,
t.num_replies as numReplies, t.id_topic as id, m.id_member as authorID, t.num_views as views, t.num_replies as replies, t.locked,
IFNULL(thumb.id_attach, 0) AS thumb_id, thumb.filename as thumb_filename
FROM ({db_prefix}topics AS t, {db_prefix}messages AS m)
LEFT JOIN {db_prefix}members AS mem ON (mem.id_member = m.id_member)
LEFT JOIN {db_prefix}attachments AS a ON (a.id_member = mem.id_member AND a.attachment_type != 3)
LEFT JOIN {db_prefix}attachments AS thumb ON (t.id_first_msg = thumb.id_msg AND thumb.attachment_type = 3 AND thumb.fileext IN ("jpg","gif","png") )
LEFT JOIN {db_prefix}boards AS b ON (b.id_board = t.id_board)
WHERE t.id_first_msg IN ({array_int:posts})
AND m.id_msg = t.id_first_msg
GROUP BY t.id_first_msg
ORDER BY date DESC, thumb.id_attach ASC',
array('posts' => $mposts)
);


// ... more code ...


// insert the forumposts into $posts
if(is_resource($request) && $smcFunc['db_num_rows']($request) > 0)
{
while($row = $smcFunc['db_fetch_assoc']($request))
{
// do stuff ...
}
// do some more stuff
}

}
The only thing I changed to make it work now was to remove the is_resource($request) condition from the last if clause. Because it turned out that is_resource($request) was false, but the request actually had a lot of results, concerning the selected forum topics for the front page.

I ended up with the idea to remove that condition, because after this there is another database query for fetching the promoted articles, with a similar logic, but without testing for is_resource($request).

I wonder what this is_resource($request) actually means. I am not really familiar with PHP. It seems to work fine now without that condition, but certainly there must have been a reason behind it? And after all, it did work all the time with that if-clause on earlier versions of SMF. So I am curious about a technical explanation here. 

Looking forward to any hints that you might have. 

And of course I'd be interested if my solution is technically okay, or if something could explode at some point now.

[lurkalot]

Strange, not come across that issue.  Just out of interest, did you also change php version? 

I would first and this is important. make a backup of all your files, because some stuff was known to get removed when uninstalling TP1.0, like TP downloads etc.

Then uninstall Tinportal 1.0 and install Tinyportal 1.3

[Arantor]

It wouldn't matter if they changed PHP versions. SMF prior to 2.0.14 returned query results as resources, but as of 2.0.14 they're no longer resources but objects.

This check is to check the query didn't fail and does have results before proceeding.

You can safely change is_resource(...) to !empty(...) in this case though I suspect if it's core TP code, TP 1.3 already has this covered.

[perkele]

Thank you both for your replies, especially for pinpointing the technical reason behind this change of behaviour and how to make it safe again. Always good to understand the reasons behind such not very obvious things.

Yes we did change PHP version from 5.3.something to 5.6.something. Because SMF 2.0.14 requires PHP 5.4 at the least. So this was a good opportunity to finally let a server migration happen after the forum didn't work anymore.

Let's see... should I try upgrading to TP 1.3 now as well, as long as the forum is still in maintenance mode anway? I'm not really up to adventure now and everything seems to be working okay. Maybe I should take a look at what nice new featues would await me.

Is reimporting old TP 1.0 data from a backup, i.e. downloads, articles and shoutbox shouts, after uninstalling TP 1.0 and freshly installing TP 1.3, a straightforward and relatively painless process?
But it seems there may be enough topics here where I could find the answer to this question, like this one perhaps. I will do some reading.

Thanks for your good work, by the way. This piece of software has been very useful for a long time.

[illori]

you dont need to import any data, you just uninstall the current tp leaving the data in place and install the new one.