Lack of interest Twemoji integration. [Emojis]

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.
This suggestion has been closed. Votes are no longer accepted.
Like that, but.... There is the conflict between the smilies and emojiis. And how to use emojiis on a desktop..
 
There's another cool library here:
https://github.com/Ranks/emojione
http://emojione.com/
http://emojione.com/demo/

--
Like that, but.... There is the conflict between the smilies and emojiis. And how to use emojiis on a desktop..
there's not any conflict.
I've been thinking that the best way to manage this, could be add the emojis that you want to use as normal icons like:
Screen Shot 2016-01-01 at 3.11.53 PM.webp
but, would be even better that emojis inserted from mobile devices can show exactly the same emoji installed as icon.
like:
Screen Shot 2016-01-01 at 3.30.09 PM.webp
that would be really great. many sites are using that system. emojis are important now.
 
Emojis can be added as a webfont to allow for desktop support (through the use of one of the libraries linked above), but native emoji support (posting from phones) would require the database to use utf8mb4 encoding if I'm not mistaken.
 
would require the database to use utf8mb4 encoding if I'm not mistaken.
At least the table columns where emojis are wanted. Anyone seeing a disadvantage in converting said columns? Cause in my eyes that'd be more efficient than processing each and every post to convert them to smileys or another font.
 
Are you talking TRUE emoji, or just images that emulate emoji's? If true translatable (from a mobile device like an iPhone) emoji, then there is more to it than making the software "capable". You also have to have a DB format (UTF8MB4) that supports it. So that will restrict (if it is a core dependency) it from being used an most shared hosting environments and numerous self-hosted ones from my understanding.
 
I doubt that. UTFMB4 requires msyql 5.5. That should be part of most nowadays LAMP Setups. Even Debian7 has it and that's a quite conservative distribution.
If you were responding to me (that's where quotes are nice) then I would refer you to past history of folks like HostGator and GoDaddy and their slow roll-out of more modern PHP versions and frequently their mySQL.
Not all Xenforo sites (in fact, most likely a minority) run in a VPS or dedicated server space where the admins can control those aspects.

I bring your attention to the very first line in that link (emphasis added by me)
In WordPress 4.2, we’re upgrading tables to utf8mb4, when we can
 
I would refer you to past history of folks like HostGator and GoDaddy and their slow roll-out of more modern PHP versions and frequently their mySQL.

So what is the point? you are saying that just because there are Host Companies that are too lazy to support modern versions, no one should go for state if the art technology?

We are talking about an addon that brings new features for those who are interested in it. and not about a new requirement for all xenforo installations out there.

If someone is really wanting that functionality and the Hosting Company does not want to provide, switch the provider. It is that simple.
 
We are talking about an addon that brings new features for those who are interested in it. and not about a new requirement for all xenforo installations out there.
Funny.. I thought this area was for XENFORO suggestions for implementation... not an add-on development request section - ergo, it WOULD effect ALL XenForo installations out there.

If someone is really wanting that functionality and the Hosting Company does not want to provide, switch the provider. It is that simple.
The point being, if it is CORE then that may not be an option... and restricting from hosts like that will restrict your possible user base of customers.
It's actually that simple.
 
It seems pretty easy to detect utf8mb4 support on install/upgrade and fallback to the current encoding if it's not available.

At least the table columns where emojis are wanted. Anyone seeing a disadvantage in converting said columns? Cause in my eyes that'd be more efficient than processing each and every post to convert them to smileys or another font.
I agree, but you'd still need a webfont library to see/use emojis on the desktop since Chrome doesn't support them natively (besides on OS X).
 
Last edited:
Funny.. I thought this area was for XENFORO suggestions for implementation... not an add-on development request section - ergo, it WOULD effect ALL XenForo installations out there.
You are right. But in one of the deleted Posts the discussion was that an addon is going to be developed. Sorry for the confusion, for me it was clear that we are talking of an addon.

Otherwise: as a core functionality xenforo could easy distinguish between the server capabilities. Just the same way it is handling "friendly urls" (requires mod_rewrite) or "image manipulation" (requires image magick). Give an option in the settings if mysql 5.5 is available and that's it.
 
Otherwise: as a core functionality xenforo could easy distinguish between the server capabilities. Just the same way it is handling "friendly urls" (requires mod_rewrite) or "image manipulation" (requires image magick). Give an option in the settings if mysql 5.5 is available and that's it.
Not sure how well that would go over since it's more of a user interface issue than the other two are. The two examples that you gave happen behind the scene - this would be an issue that could cause some admins headaches from their users of "why can I use these over there, but not here" type stuff.
It's not that I'm in disagreement with it - heck, I'd like to be able to use the emoji's from my iPhone 6 or iPad - just wondering how many headaches it would end up causing in support issues.
 
After making a Discord bridge for our chat I've been looking into this. It doesn't seem very tenable to do this as an addon without a significant performance hit.
 
Top Bottom