Comments Plugin: Working with 1.4.2?

Hi,
Does anyone have the comments plugin working with 1.4.2?
I added it to a new install and only got the display on the screen without the ability to actually save/retrieve data.
Not sure if it is just a faulty install (e.g. failed initialization) for some reason or a version incompatability. It does say it is only tested with 1.3.x.
I gather from other postings that support for the plugin from the author is not happening but wondered, as it is fairly basic, if anyone out there had already got it working or had it just work anyway.
Thanks to anyone who can help
James

If you can wait a couple days, when we release Omeka 1.5 we're also planning to release a completely new and more feature-rich Commenting plugin. It will require the upgrade to 1.5. Those should both be available very soon.

Hi Patrick,
Sounds like a plan!
Thanks
James

It occurred to me that I should be able to use the new Commenting feature as the gateway to a discussion area for general topics that aren't related to conventional Items (e.g., with just a basic DC Title and meta-data Item Type and then assigned to a collection of such topics). However, when I do that, I don't seem to be able to get approved comments from other admin members to show up as a thread.

Interesting! That sounds like a nifty way at producing a forum that we hadn't anticipated.

Can I ask some more info to try to reproduce the situation you have?

What settings for the plugin have you checked off for the visibility of comments?

If you switch to not using threaded comments, do they show up?

I have the Commenting plugin settings set so that comments can be created and made visible for all three available user types and also visible for the public. I tried unchecking and rechecking the threaded option, but that didn't help.

I think the problem has something to do with how items\show.php (I now have that over in my Santa Fe theme folder) calls plugin_append_to_items_show() (which seems to be OK for a different item type, though).

Maybe it has something to do with commenting_get_comments not working right from the helper, when it goes to the plugin function plugin_append_to_items_show.

I'm not really a programmer, though, although I have a basic training and can sort of follow what's going on! Is it that I also need to move those helper and function files over to folders in my theme directory? It could be a lost-path thing, right?

It gets close to what I have in mind at the collection show, actually (works on public): http://music-discussion.net/mdn3/collections/show/2. However, the links back to the item-show obviously then don't include the comments via the plugin helper/function.

The files should all be okay where they are in the plugin. I'd expect a different, more visible error if there were a path problem.

Just to make sure of exactly what the problem is -- are the comments showing up, but just not threaded, or are they not showing up at all?

I believe threading isn't a problem, actually. For the attempt at a discussion forum, comments seem to show up only at collection/show (the link I gave before), but not at links back to items/show or even by going directly to the item show itself: http://music-discussion.net/mdn3/items/show/16 (even when the item's public). On the other hand, the comment shows up on the collection show page, even when the item it's attached to is NOT public (and, for example, when I'm not logged in, although the possibility of replying is correctly turned off in that case).

A comment on my instructional video item type seems to work as expected, though (logged in or not): http://music-discussion.net/mdn3/items/show/1.

ah...now I think I'm following you. I see a couple different things.

One is some poor word choice in the plugin itself. It is set up by default to allow commenting on both Omeka items and entire collections. And so when you see the comments at the bottom of collections/show/2, that's a comment attached to the collection, not to the item. The wording "Discussion for This Item" when you are really commenting on the entire collection is definitely misleading.

If you want to remove commenting on collections, go into CommentingPlugin.php and comment out the line 'public_append_to_collections_show', at line 11.

With that confusing part removed, hopefully all that's left is to go directly to the item show page at http://music-discussion.net/mdn3/items/show/16 and try entering a comment there, instead of on the collection page.

Second, the fact that the comments appear even when an item is not public is definitely a bug for us to fix.

Hope that does the trick

I don't actually mind having collection discussions as a possibility, but I think it will be too confusing to keep it, unless the word "Item" can be changed to "Collection" in that particular instance! If I get rid of that as you suggested, obviously the non-public comments showing up on the collections show page then also won't affect me.

Thanks for your help.

Here's a related question. The Comments "editor" does provide a bit of HTML capability for paragraphs and so on. However, it would be a lot more useful (and user-friendly for potential forum participants) if Comments could provide the blog-like/mini-MS-Word editor that is available elsewhere in Omeka, such as at the MyOmeka poster-description editor. Is it possible to use that for Comments? Thanks.

Here's an unrelated question. On my home page, I now have featured items coming in as embedded videos, such as from YouTube. However, when I get this thing up and running, Contributors will be able to add featured content that won't always have the relevant item field in the item's type metadata. So, I'd like to have an if statement that just does display_random_featured_item UNLESS the embedded media field has something in it. Am I close with the following? Thanks.

<?php
$featured = random_featured_item();
set_current_item($featured);
//if (item('Item Type Metadata', 'URL or Embedded Object') != NULL)
echo item('Item Type Metadata', 'URL or Embedded Object');
//else
//echo display_random_featured_item();
//endif;
?>

Actually, some Item Types won't have that field, so the if statement would need to be slightly more complex, I think, possibly with an elseif to account also for that field potentially not even being there.

On the related question: it's possible, either with a quick hack on the plugin, or (eventually) we could add that functionality into the plugin itself for a new release.

The quick hack approach would look like this. Bear in mind that this hasn't gone through any real testing to make sure that the validation works out correctly.

In CommentingPlugin.php, add queue_js('tiny_mce/tiny_mce') to the hookPublicThemeHeader method so it looks like:

public function hookPublicThemeHeader()
    {
        queue_css('commenting');
        queue_js('commenting');
        queue_js('tiny_mce/tiny_mce');

    }

Then, in /views/public/javascripts/commenting.js add the tinyMCE init code, so the last few lines look like this:

jQuery(document).ready(function() {
   jQuery('.comment-reply').click(Commenting.moveForm);
   tinyMCE.init({mode:"textareas", theme:"simple"});
});

That should at least add the editor, I don't know if any other problems might come in with the editor's validation vs the plugins validation.

For the unrelated question -- BTW, it'll be helpful for everyone to start a new thread for questions unrelated to the thread :) -- that'd roughly be it.

Depending on what item types have that field, you could use item_has_type('Relevant Type') to check whether to continue. item() will return an empty string, not NULL, for an empty field. So something like this might be what you need:

`
if(item_has_type('Relevant Type')) {
$data = item('Item Type Metadata', 'URL or Embedded Object');
if($data == '') {
echo display_random_featured_item();
} else {

echo $data;
}
}

HTH.

If there are followup questions, lets move those to a new thread.