[UW] Smileys Bar [Deleted]

[deslocotoco]

I am testing this addon starting from first release and very please with its performance.

I have reported two bugs (IOS and 3rd part addon compatibility) @xffutureuser is very interested and returned back as soon as possible.

Due to 3rd part compatibility issue, I was not able to install it at my real site. With the last version which is released very soon, I will install and start to use it at my real site.

Thanks for your reply.

I'm going to wait for a more stable version, then. Almost 50% of my members use mobile and this is very important for me.

Glad to see that @xffutureuser is giving a great feedback support.

 

[mkucuksari]

I'm going to wait for a more stable version, then. Almost 50% of my members use mobile and this is very important for me.

It is stable enough, at least for me It is definetely very usefull both for mobile and PC users.

If you have time you may check at my real site within 3 hours and see yourself how it is also working perfect at real site

My Forum adress:

RCKolik

Bagımlılık Yapan Modelci Platformu

www.rckolik.com

 

[xffutureuser]

xffutureuser updated [UW] Smileys Bar with a new update entry:

Support for all text editors

Edits made to the code so that Smileys Bar works well in any text editor, even from other add-ons.
The thing is that there are forums with many other add-ons that contains also their own text editor. Now even on those text editors Smileys Bar works well. Already tested on several other add-ons such as XF Resources, some DragonByte text editors, XenAddons text editors, 8WAYRUN text editors....

Smileys Bar for text editor in DragonByte add-on:

View attachment 205545

Read the rest of this update entry...

 

[xffutureuser]

@palhanow
There are no bugs already. I hate bugs a lot. If you find any bug (within 48hrs from download, has to be reproduceable) you will get a reward. Contact me for more details. Currently there is no work on any bug because non is known. And featurewise, all originally planned features are already completed.

Actually, this add-on is not as new as it might seem. The code of this add-on was completed almost a month ago. My job was to find bugs, design flaws and that is what I've been doing for almost a month now. So this add-on was posted here only after I was not able to find any bug.

You can test it on a life website here as well: https://ultraweb.co/threads/new-testing-thread.17/post-192

And I've also checked the thread about this add-on on rckolik website and the users really love it. rckolik is using also custom smileys in the Smileys Bar. Works flawless.

Plus the price is so cheap, it's basically for free compare to the real cost to develop this thing. I wish I could buy it just for this price. I mean, really, you've got nothing to lose.

 

[mkucuksari]

And I've also checked the thread about this add-on on rckolik website and the users really love it. rckolik is using also custom smileys in the Smileys Bar. Works flawless.

Yes i can confirm it. I and my forum users really like it too much Although it is in Turkish, you can still see it from the thread reactions

Duyuru - Smiley Emojii Editör iyileştirmesi devreye alınmıştır

Öncelikle forumun gelişmesinde maddi anlamda ciddi destekleri olan ABONELERIMIZE bu vesileyle bir kez daha teşekkür etmek isteriz. Forumu daha pratik ve güzel hale getirme çalışmalarımız sırasında abonelerimizin MADDI desteklerini hep yanımızda hissediyoruz. Abonelik sistemi hakkında bilgi...

www.rckolik.com

 

[Kirby]

This is a really nice feature that IMHO makes using smilies on mobile a lot easier
I would'nt mind having this in stock XenForo.

 

[JamesBrown]

I must say this is a vast improvement in usability over the core solution. Well done, I'll be buying,

 

[Kirby]

One performance suggestion though:
This Add-on performs two additional queries on every page which is wasteful.
You are doing this because you apparently found no way to reliably detect if the editor is going to be used on the page.

Dependency Injection will solve that problem

Take a look at how DI is being used by XF in \XF\App, you can add your own data in templater_setup

 

[xffutureuser]

We know about DI. We are already using the right approach here. Let me explain.

At initial versions we were only making queries on the templates which have editors to avoid any useless query. But later we realized that we need to make it work for all custom add-ons as well. So we inject our code into templater_global_data to make it work for all custom addons.

you can add your own data in templater_setup,

This will further increase the queries cost. We've a scenario where there can be around 38 editors on a single page (FCS add-on). If we go with templater_setup, it will make queries each time the editor template is setup so that would be worse.

So keeping in view that there can be multiple editors on a page, the best solution was to pass the data into the templater_global_data.

 

[deslocotoco]

Just bought your add-on and everything is working perfectly.

No theme related issues or bugs that i notice.

Keep the good work! Thank you very much for this awesome feature. XF should buy your add-on work to implement like a core feature for sure!

 

[deslocotoco]

Hello!

Just one little requisition:

I have some old schools emojis in my board and they doesn't show up in the categories menu:





I'm installing some new emojis in this week, in new categories. Is possible to show this custom categories like the rest of then?

Edit: The "X" button (close the search bar) is not working.

 

[Kirby]

Unfortunately there are further, more serious performance issues:
All smilies do get loaded even if the Smiley Bar is closed, I do get ~ 100 HTTP requests for smilie images

While, depending on the amount of smilies, it might be workable to load them all upon initial page load if the Smiley Bar is opened, it is not acceptable to load them if the Smiley Bar is closed - especially not on mobile.

Idea

• Split the list into chunks of ~10 images
• Wrap each chunk in <noscript>
  Do not wrap the first 2 chunks if cookie indicates Smiley Bar is open.
• On page load/Initial Bar opening: Make the 11th smilie a sentinel and start IntersectionObserver or unwrap all chunks if not supported by the browser (poor dumb IE and older Safari versions ...)
• On Intersection Observer Event: Unobserve, unwrap next chunk , find new sentinel, observe

You already do have IntersectionObserver code in your JS, but that does not work for smilies only for Emojis.
Also, observing every single image does not seem efficient.

 

[deslocotoco]

Unfortunately there are further, more serious performance issues:
All smilies do get loaded even if the Smiley Bar is closed, I do get ~ 100 HTTP requests for smilie images

While, depending on the amount of smilies, it might be workable to load them all upon initial page load if the Smiley Bar is opened, it is not acceptable to load them if the Smiley Bar is closed - especially not on mobile.

Idea

• Split the list into chunks of ~25 images
• Wrap each chunk in <noscript>
  Do not wrap the first chunk if cookie indicates Smiley Bare is open.
• On page load/Initial Bar opening: Find first wrapped chunk, add sentinel <li[> in front of it and start IntersectionObserver or unwrap all chunks if not supported by the browser (poor dumb Safari ...)
• On Intersection Observer Event: Unobserve & remove sentinel, unwrap chunk, find next chunk, add new sentinel, observe

You just talked like ancient Greek for me, but sounds bad this performance issue.

Should i disable the add-on and wait for the next update?

 

[Kirby]

This is not the kind of "this will kill your server" performance issue, but it negatively affects client performance/page loading time.

You might want to do a Lighthouse report with and without the Add-on enabled and compare if it does change significantly.

@xffutureuser
You should minimize your JS for production use, serving full JS ist not best practice.

Development tools | Developer Documentation | XenForo

Developer documentation for XenForo

xenforo.com

 

[xffutureuser]

I have some old schools emojis in my board and they doesn't show up in the categories menu:

Whenever a new custom smiley is created, it is automatically shown in the Smileys Bar, if it is turned on. So every custom smiley, whether it is in a category or without it, it would go inside the Smileys Bar.
That is how it is designed to work right now. I don't use any custom smileys, I thought that what XF offers in stock and maybe a handful of custom smileys would be more than enough. But apparently not for everybody. Will consider looking into possible other approach for this. Will let you know.

Edit: The "X" button (close the search bar) is not working.

The "X" button is not there for closing the search bar. The search bar can be removed trough the admin area. The x closes found smileys as mentioned in the add-on page and also shown in the demo video. It is similar functionality as WhatsApp web.

 

[xffutureuser]

Unfortunately there are further, more serious performance issues:
All smilies do get loaded even if the Smiley Bar is closed, I do get ~ 100 HTTP requests for smilie images

All the xenforo default smileys are inside a single sprite image so that would be just a single http request to get all the default smiles that are in the Smileys Bar.
If you have any custom smileys, the best approach is to have them as sprite image instead of separate image for all. As far as the emojis are concerned we are already using IntersectionObserver for them to avoid the above reported situation.

Also just to mention, if you notice xenforo doesn't use any sort of lazy load technique for attachments, for example if there is an image at the very bottom of the thread, xenforo would still load the image. (This can be improved but we can not call this serious performance issue ).

So there is always a room for improvement. Thanks for your suggestion. We might look for this in the future version.

 

[frm]

Does the user have to "turn on" smilies bar or can it be forced from the admin side to always remain, much like it is on Instagram, etc. (no option to turn it off by the user)?

Thanks

 

[xffutureuser]

A user has to turn it on. But once turned on, it will be remembered and it will stay turned on all the time, until the user turns it off.

 

[frm]

A user has to turn it on. But once turned on, it will be remembered and it will stay turned on all the time.

Are there any plans in the future to force the bar like in Instagram where it's more "comfortable" and up front? This seems like the new trend and user enable/disable may work, but forcing it might get more usage.

 

[xffutureuser]

Are there any plans in the future to force the bar like in Instagram where it's more "comfortable" and up front? This seems like the new trend and user enable/disable may work, but forcing it might get more usage.

Honestly, I newer thought of forcing this on the user. Basically for those who want to use the Smileys Bar, it will be "kind of" forced for them because they will have the bar all the time there. Only those who don't like using smileys will not see it.
I guess it could be considered for the future version if licence holders really want it. Please mention it in SB Suggestions.