In a discussion about the vBulletin Emojis plugin for Discourse, cpradio introduces a plugin to revive classic vBulletin-style emojis — many animated — which coexist with modern Emojione sets without conflict. codinghorror notes that Discourse 1.2 will support custom emoji from Apple, Google, and Twitter, but cpradio argues the vB emojis have a nostalgic, distinct aesthetic that doesn’t fit modern styles. Humor ensues, including playful jabs and emoji-laden replies codinghorror and cpradio. Later, users report the plugin is broken in recent Discourse versions (e.g., 2.5.0.beta2) Hifihedgehog. Steven explains the breakage stems from new emoji group features, suggesting a fix via register_emoji in plugin code, but notes caching issues remain unresolved. cpradio offers to add Steven as a contributor to the repo. Debugging reveals a NameError: uninitialized constant Plugin::Instance::Emoji cpradio, which j.jaffeux resolves by wrapping register_emoji in an after_initialize block — a fix cpradio confirms works. sunjam asks whether to import all emojis directly or split into separate plugins; tom1984 questions if native custom emoji now support animation, noting they’ve worked well for 20+ years. Steven confirms some GIFs work, and tom1984 shares success using built-in custom emoji with CSS resizing for proper aspect ratios, citing meta.discourse.org.
For anyone who wants to relive the old days of vBulletin and bring back those emojis, have a look at the following plugin (and yes, several of them are animated)
Oh, and they do not interfere with the existing emojione emoticons, as these are all prefixed with ‘vb-’
https://github.com/cpradio/vb_emoji
A big thanks goes out to @eviltrout for his emoji extender!
Just a reminder that in the 1.2 release there will be:
choice of Emoji class from Google, Apple, Twitter, EmojiOne
custom Emoji support
Yes, that looks really neat (btw). The vB ones really don’t fit in with the Google/Apple/Twitter… ones, so I see this still being the easiest way to quickly bring in the vB emoticons, but I do like the progress that was made here within Discourse.
Well, these vb ones don’t really fit in anywhere in my opinion 
Well aware of that. As you are aware that the opinions of others are the existing ones don’t really fit in anywhere.. So the opinions are mutual across both sides. I personally don’t care enough one way over another, I simply created the plugin as 1) a test to get used to the plugin framework, and 2) because I know our forum specifically wants it.
I am just kidding. Just know, @cpradio, that I will always think of you as my
I always did consider myself a 
Too much? 
Hahahahahaha. This was too good to just like.
PSA: This plugin in the last few weeks has become broken with the latest release of Discourse, 2.5.0.beta2. Bye, bye, vbulletin emoticons. It was nice knowing ya. 
The plugin can be updated, the plugin is broken because of a great new feature that allows the creation of new emoji groups but we still can register new emojis via plugin
https://github.com/discourse/discourse/commit/0996c3b7b36c37c3b478985da6e968f54dc4835c
I think we’ll just need to add an element in the plugin.rb file, something like this:
register_emoji "doh", "/plugins/discourse-plugin-vb-emoticons/images/doh.gif", "vbulletin"
And it should work again
Thanks, @Steven. I see @cpradio is still active visiting the forums here, as of 3 days ago. If he doesn’t reply in a week, is it kosher if I fork his plugin (duly credited) using the fix you mention above?
This fix doesn’t seem to be enough, we need to add some clear_cache command but I don’t really know how to do this for now. I’ll look into this.
I don’t mind maintaining it also, I have a similar plugin, so I can do some grouped upgrades when something changes.
That sounds like a plan! I appreciate it.
@Steven, if you want, I can add you as a contributor to the existing repo. More than happy to share the responsibility. Sadly, it will take me awhile to get a dev environment built for discourse again, sadly, I haven’t had time to spend in it so I’ve discarded my setups for awhile now.
I’m ok with this, my github account is iunctis
I didn’t find a solution yet for emojis plugins to work, I’m missing the right commands to clear cache
Sent you an invite. If there are any others you want to be invited to, let me know. I did get my rig put back together late last night, but that is as far as I got, clean install of Discourse. I plan to look at it again tonight (time willing), worst case, tomorrow night.
This is weird and might not be an issue with the plugin itself. When I do a rebuild on a clean install of Discourse adding my plugin, I get the following error
Caused by:
NameError: uninitialized constant Plugin::Instance::Emoji
/var/www/discourse/lib/plugin/instance.rb:482:in `register_emoji'
/var/www/discourse/plugins/discourse-plugin-vb-emoticons/plugin.rb:12:in `activate!'
/var/www/discourse/lib/plugin/instance.rb:526:in `instance_eval'
/var/www/discourse/lib/plugin/instance.rb:526:in `activate!'
lib/discourse.rb:224:in `block in activate_plugins!'
lib/discourse.rb:221:in `each'
lib/discourse.rb:221:in `activate_plugins!'
/var/www/discourse/config/application.rb:280:in `block in <class:Application>'
/var/www/discourse/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/var/www/discourse/config/application.rb:279:in `<class:Application>'
/var/www/discourse/config/application.rb:62:in `<module:Discourse>'
/var/www/discourse/config/application.rb:61:in `<top (required)>'
/var/www/discourse/Rakefile:7:in `require'
/var/www/discourse/Rakefile:7:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Note the first two lines:
NameError: uninitialized constant Plugin::Instance::Emoji
/var/www/discourse/lib/plugin/instance.rb:482:in `register_emoji'
@j.jaffeux, any ideas why it can’t find the constant? It seems to be looking within the wrong namespace.
I think it would work nicely if you wrapped all your register_emoji calls inside, an after_initialize block
Is it something you can do ?
Indeed that works! Thanks!
