Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options
Convert Chatbox Breizh Shoutbox for Vanilla 2
Tof
✭
Hello the community
We use the last 4 years a shoutbox produced by Breizh: Breizh Shoutbox
I would like to know if it was possible to adapt to Vanilla 2.
She currently works for phpbb 3.
I tested the chatbox Vanilla 2 : https://vanillaforums.org/addon/van2shout-plugin
This project is a good beginning but many things missing.
Smileys lack of options, no sound, rapid administration ...
Thanks for your feedback
Tagged:
0
Comments
Here is a more complex chat box I tried and it is very nice. You can embed it in a module and add it to your website.
http://www.rumbletalk.com/
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
The problem with these paid services is that they are really very expensive.
The idea to set up a chat box for vanilla 2 plugin is actually a capital gain.
The shoutbox is no longer developed. Are there someone who will take over?
I can't help but wonder whether the conversation module could be enhanced to be an alternative to all these side panel chats. Thinking out loud (always dangerous) maybe a "public" type of conversation that anyone can join in...
You can try the VChat plugin, it is free and offers lots of stuff but no admin or moderation, You can also try xat chat it is free and has admin and mod capabilities.
http://xat.com/
or this one http://www.smartchatbox.com/
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
Whatever made you think saying your opinion is unwanted, must be a misunderstanding.
In my opinion using the conversation tables would be possible, but not optimal. I see two reasons for that:
Conversations are using 2 tables: Conversation and ConversationMessage. Every write to ConversationMessage updates Conversation. A shoutbox could be implemented with only one table. Since they are used like chat and could generate a lot of traffic, they should be as fast as possible. If you use ConversationMessage for each shoutbox entry, Conversation would have to be updated every time without any use for the shoutbox.
If the shoutbox is used heavily, it will influence the speed of queries to the ConversationMessage table and thus influence the speed of the Conversations addon functionality as a whole.
The only benefit of reusing Conversations is the existing table structure. To my opinion the gain of reusing an existing table wouldn't be high enough for the performance penalty.
But implementing it as a Vanilla plugin without making use of a third party script seems to be a good idea.
Creating a table and using CRUD operations on it is really easy with the Gardens model class. Using the formatting options is also quite easy with the format class. So I think implementing the php side of a shoutbox would be really easy. I do not have much knowledge when it comes to JavaScript but I would assume it wouldn't be too hard to do the ajax part of the shoutbox. It would have the benefit that users could use formatting options and smilies that they are used to that the formatting options have in the forum.
Hi @R_J, very insightful and triggered a Google search (to figure out what CRUD stands for). From my learning through coding the InboxPanel and DiscussionNote plugins I think it is very doable including the JS part. However I think that from the user's point of view the side panel should be combined (chat+conversations) as the difference is vague and more so when a conversation has multiple participants. My observation comes out of our users using the Inboxoanel plugin for a while and using it like a chat of sorts. So with my experience the difference is whether a conversation is "public" or not. Public means it appears in everyone's sides panel and everyone can respond, non-public is limited to the conversants (as conversations behave today).
With the above and considering your performance comments I can see two ways of implementing this:
1. Implementing a separate Vanilla chat plugin and then a side panel that merges data from both (chat and conversations)
2. Using the existing conversation model and absorbing the performance hit you mentioned. The advantage is that the side panel code (php & JS) would be much simpler.
What do you think?
You are starting with the assumption that the panel is a good place for conversations. Personally I do not share this point of view.
But just for fun: given that conversations already take place in the panel, I wouldn't mix it up with a shoutbox (your first point) because a conversation is still a private way to communicate and a shoutbox is public. As an administrator I wouldn't risk setting a public channel next to a very similar looking private channel and having some dumb users (you always have more of them than you wish to) contacting me full of panic to delete their wrong posts in the shoutbox.
If you separate them and put one on the left and the other on the right, that might be a whole different story.
But anyway: I think they must always be very clearly distinguishable. Only from what I as a user would expect from a UI. I'm not sure if mixing it with other conversations would be sufficient.
Additionally a shoutbox should be viewable all the time, shouldn't it? So wouldn't you have to separate it from the conversations, anyway?
I'd say you have to separate both, which would contradict your second point.
Conversations are implemented that you must be a participant in order to see and being allowed to write to it. New users must be auto assigned. Or the mechanism must be overridden, which must be done for guests anyway.
Implementing that without compromising the privacy of other conversations alone would outweight your second point.
And as I said before: the only benefit that conversations might bring is the already existing table structure. But for a shoutbox that is a poor design.
I still do not see a single advantage to reuse a conversation for that, but only disadvantages.
My personal opinion on this is more a conservative way. This is the Linux philosophy : write programs that do one thing and do it well. If you want to discuss, use a forum. If you want to chat, use a chatroom. If you want to exchange messages use mail.
Nevertheless I think that a private message system is a must. Users should be able to start a private communication. I think it is a bad habit to use PMs for more serious/important things. You "own" your mails, but PMs can get lost at any time. They can not do what mails can do and they never should and they never will. And that's okay. They are just a vehicle to get in contact or exchange minor important information.
I totally dislike shoutboxes and I would never, never recommend a forum to use one. What makes your forum whealthy is its content. Shoutboxes content is lost. Allowing - if not encouraging! - your users to "waste" that capital is dumb. Why shouldn't they open up a discussion and start trolling around in that discussion? All those personal involvement mechanisms work in a discussion: mentions, reactions, toys like the minion/bot plugin, whatever! What does a shoutbox offer? Smilies. Nothing else. What a waste of time if you've configured your board to be attractive.
One more thing: technically PHP and js aren't the best base for a near real time chat. In order to "know" if the shoutbox has to be updated, there must be an ajax call made to the server. So even if no one is writing to the shoutbox at all and everyone is reading a very, very long discussion or just let their browsers open and going out with their dog, they're hammering on your server with requests.
So just be adding a shoutbox to your forum, you would have to consider adding more hardware power to your server. Whether your users use it or not...
Yes, @R_J I hear you. Indeed our experiences are different both from where we're coming from (Unix vs. Windows) and likely the type of forums we work with. I am administering an internal forum on the corporate departmental intranet and so my audience is a captive audience.
I also see how chat conversations could compete with discussions by redirecting both content and attention sideways. Also concur that content in conversations (& chat) is "lost" when compared to discussions. In fact, when we internally thought about the Inbox side panel (in response to internal users requests) we were contemplating the idea of using a special discussion category dedicated to "public chat" just to ensure that content is not lost and that plugins would work with it. We never implemented that and only have the Inbox side panel. Clearly, the performance issues you mentioned earlier about using the conversation model would would apply to the discussion model.
I understand the issue of having to ping the server frequently in order to refresh the shoutbox. What I am wondering is the difference between doing it internally or via one of the external shoutboxes solutions. Wouldn't these too have to ping their servers? Can I assume that the difference is on where the infrastructure costs are?
My background is MS-DOS
and I only struggle with Linux because I think it is superior. But I'm almost always having to look up everything I want to do. But if you want to have a fast and reliable web server, you have to deal with Linux.
For your forum having a conversation that everyone can participate in might be best suited. You could auto assign new users to that discussion quite easily. Did you that you can have subjects for conversations? Try adding
$Configuration['Conversations']['Subjects']['Visible'] = true;to your config.php.If you use subjects, you could name that conversation "Chatroom" and you are almost done. Only the frequent updates must be added.
If your forum isn't that big, performance should not be a big problem, too. Your solution would be the solution for a niche, though.
I do not have any knowledge about shoutboxes. There might be some that are implemented as external services which would relieve your server.
If you want to create something with real time communication, you should take a look at websockets
You would either need to implement the server in js for node.js or use something like this or that
But as I've said before: if you've got a small forum, you would be able to go with the most used php/js combination. Using websockets would be really cool, but might be overkill.