Commenting Plugin Error

[NancyAnn]

It seems the closer I get to going live with my project, the more glitches I encounter. I just installed and configured the Commenting plugin, and now the item doesn’t display any of the metadata and I get this error message. It’s probably an easy fix that might give more advanced folks a good laugh!

Here is line 175:

Thanks again for all the help -

[patrickmj]

This actually does look like a special bug. Could you post up the configuration settings for Commenting that you are using (I know there might be a lot, but that seems like the quickest way to see how to reproduce the bug)

[NancyAnn]

Here’s the config settings:

[NancyAnn]

So now that I reactivated and configured it to get the screenshot, it works for me as a superuser but not the user I created as a test case.

Also, I just noticed that the navigation bar is missing when I log in as a user.

Hmmm …

[patrickmj]

Thanks. Alas, with those settings I still couldn’t reproduce the problem. The old standby things to try are

1. Uninstall Commenting, remove the plugins files and reupload them, and install again.
2. Look for a plugin conflict by deactivating other plugins to see if that makes it work, then if that makes it work reactivate them to see which one is the culprit.

The navigation bar disappearing is an interesting twist. Is that on the admin or public side?

[patrickmj]

UPDATE: Was able to reproduce it with a user with role Guest, but not Admin, Researcher, or superuser. There’s very weird stuff in that function, but I don’t quite see why the different roles make a difference.

[patrickmj]

Aaaand hopefully this’ll do it:

Replace that entire showComments function with this:

    public static function showComments($args = array())
    {
        $view = get_view();
        $view->addHelperPath(COMMENTING_PLUGIN_DIR . '/helpers', 'Commenting_View_Helper_');
        echo "<div id='comments-container'>";
        echo "<div id='comment-main-container'>";
        if( (get_option('commenting_allow_public') == 1)
                || (get_option('commenting_allow_public_view') == 1)
                || is_allowed('Commenting_Comment', 'show') ) {
            $options = array('threaded'=> get_option('commenting_threaded'), 'approved'=>true);

            $comments = isset($args['comments']) ? $args['comments'] : $view->getComments($options);
            echo $view->partial('comments.php', array('comments'=>$comments, 'threaded'=>$options['threaded']));
        }
        echo "</div>";

        if( (get_option('commenting_allow_public') == 1)
                || is_allowed('Commenting_Comment', 'add') ) {
            echo $view->getCommentForm();
        }
        echo "</div>";
    }

it cleans up some of the misguided ways the $view was retrieved [patrick shakes finger at past self]

There will be a more robust fix to the plugin coming soon, but for now that looks like the quickest solution. Let me know if you encounter any more problems after you make that change.

The quirk that your use case exposed was a role being able to add a comment, but not being able to view comments – that made the difference in the roles.

So, thanks for finding this bug!

[NancyAnn]

Great, that did the trick - thanks so much for the fix. Glad I could be of “help” finding the bug!

N.