Hi:

hmmm…I don’t have any ideas as to what might be happening there.  The local copy of the site was made from the live site with no changes? 

As far as the code, it looks like the filtering itself is in the simpleplress/sp-apisp-ai-class-spcdisplayfilters.php file. Around line #65.  There’s a function call to the hidelinks() function there.

Thanks.

I took a look at the hidelinks() function and I can see that there is a filter sph_display_hidelinks_filter.

However, if I add a filter for this, it seems like it never gets called when creating email content.

I can see that hidelinks is called from spcDisplayFilters->content($content), but I cannot see where content is called when creating an email notification.

Here is the filter I’ve added, maybe I am doing something wrong here?

add_filter('sph_display_hidelinks_filter', function($content, $original) {
    error_log("running sph_display_hidelinks_filter");
    return $content;
});

When Simple Press generates a notification is it getting permissions for the individual user?

Okay I took another look at this and can see a few more details about how this is working, but I still don’t have a definitive answer. It certainly seems like there is some kind of bug here, or conflict between different forum plugins.

I believe this issue is from a combination of the html emails plugin and the subscriptions plugin.

I can also confirm that this problem only occurs for the digest emails. Regular subscription emails are fine.

The function “sp_html_email_do_digests_entry” on line 353 of sp-html-email-components.php is called using the filter “sp_html_email_do_digests_entry” which gets run at the very end of composing a digest email as part of the subscription plugins “sph_subscriptions_digest_entry” filter.

On line 366 of sp-html-email-components.php the displayFilters->content() function is run on the digest email body content.

On line 64 and 65 of ‘sp-ali-class-spcdisplayfilters.php’ this content() function will attempt to hide any links included in the content if this particular forum does not have permission to view the links.

# 14: hide links
$forum_id = (!empty(SP()->rewrites->pageData['forumid'])) ? SP()->rewrites->pageData['forumid'] : '';
if (!SP()->auths->get('view_links', $forum_id)) $content = $this->hidelinks($content);

It is difficult to tell exactly what this code is doing, but it would seem the problem is somewhere in these two lines.

I’m not entirely sure what sp()->rewrites is, but is it possible that we are trying to get the forumid from part of the current navigation through the site, or the current page?

I suspect this won’t work since this function is called as part of a cron job through the subscription digest plugin. I suspect the forumid is returning blank, and the call to sp()->auths then always returns false, thereby always calling the hidelinks function.

This might also help explain why I’m seeing different behavior in different environments (depending on how “sp()->rewrites->pageData” is working…).

Any insight is much appreciated!

I was able to work around this with the filter below. This will completely disable the 'hide links' functionality.... so it is not perfect, but works for our purposes.

add_filter( 'sph_display_hidelinks_filter','filter_forum_links', 10, 2 );
function filter_forum_links($content, $original) {
    return $original;
}