-
So, this was raised ages ago in the private area, and I want to bring it back for discussion. It is, after all, something of a mess.
First question: do we really need the facility for multiple smiley sets?
Second question: do we really need to ensure the same smileys are present in every set?
Third question, and this is one for the programmers rather than anyone else: can we safely ditch the predefined smileys shtick? Spoiler because it's long, messy and of little importance to most people, other than the UI aspect which I'll deal with afterwards.
So, smileys have the predefined list hardcoded into the smiley code in a bunch of places, so that we don't have queries when we don't need them, except that anyone who uses customised smileys in any fashion - and that's probably most people who don't have a 'businessy' site - will be using customised smileys, and thus the performance aspect.
I seem to remember that it is cached, but that's not a hard thing to check and enforce. And even if we do have the whole multiple smiley sets (which I'm not entirely convinced needs to remain but I'm willing to go with the majority), it's not like we can't just cache everything and be done with it.
So there is a performance trade off for people who do use it, versus less hit for people who don't, but then we have the UI aspect...
I mentioned a UI problem. Adding a new smiley is incredibly unintuitive.
So, if we don't have customised smileys, because internally it's *all* that customised gig, we get to massively streamline the UI. Depending on how the above other questions turn out.
Also: as far as I'm concerned you will have to use FTP/SFTP credentials to upload files. I really hope that's not a problem for anyone because I'm not prepared to budge on that; the whole point is to NOT have to change file permissions and thus encourage people to make things insecure by design.
Thoughts welcome.
-
I've only ever used whatever the default smiley set is and never had the desire to change it nor has anyone ever asked about changing it. Not much i can really add I guess.
-
Seems to me the whole underlying code can be ditched and just store the smileys as a serialized array in the settings table, much like hooks.
-
This is why I want to know how people use it, whether that will be enough.
Do people, for example, break out a festive set of smileys? Do sites generally have multiple sets on offer? Is it worth the complexity of code for it?
-
I seem to recall a poll at sm.org asking which smiley sets they use there. The overwhelming majority left the default, then Aaron, then Akyhne, in that order. I think it was in 2010.
-
80% of the time I use default. The other 20% of the time I might have Custom smileys, I never have more then one set. I might replace default with a holiday themed set on sites but never have more then one set enabled/useable. I replace the images instead of adding another set because last thing I want to see out of a given holiday season is a smiley from Halloween or whatever during Christs Birthday or Zombie Day.
-
I think festive smilies are a nice touch.
Solosmilies are my default and change to a Xmas set next week.
Gives me something to do :hmm:
-
While I do see a potential for seasonal smileys on some sites, generally it just seems most sites just add a ton of smileys for their users. Some sites have hundreds to be used and seasonal smileys are just listed as additional smileys rather then a specific set.
I also have the same issues with badges, while some sites like to have theme specific ones, most just use their standard badges set on every theme so as an admin having to copy the badges to every theme is a pain. Most SMF sites I worked on I usually just installed the mods for all badges in one directory and and the one for multiple badges.
-
OK, time for crazy ass ideas.
The smileys are currently embedded into the main CSS file for the site, as data URLs. It strikes me that we can solve the problem of uploading smileys because of that.
What we could do is store the smileys' actual data in the database, push that to the stylesheet (rebuilding if necessary, don't really know how that would work), and that way we don't have to actually push FTP/SFTP information around and can safely handle everything that way.
What I'd be inclined to do is also set this stuff up when first installing, so everything's there, rather than having data in multiple places. It also means we can streamline this nonsense of 'enable customised smileys' and totally just rely on the DB to do it right the first time.
Thoughts?
-
I would have replied the day this was posted I like the idea ear aches suck btw
-
I'll throw in some ideas if I may..when you actually look upon smileys, what are they really? I mean, what do they represent? They are all shortcodes that means distinct things ("angry","sad", "lol"), the actual graphic representation can be very different, right? So why not only deal with the shortcodes, and let the graphic be up to the theme?
Whats needed then, is a easy way for admins to change themes, or part of them at least. A editor of sorts, one that can be as big as you like, would be able to jumble together different smileys to a "set", and save that as a sprite which is called from posts instead of single images, through CSS. You could make several sets, and set some criteria for when they are used, as easy as making a new BBC code [christmas][/christmas] where every emoticon inbetween those tags will use that reddish set instead of the normal yellow - or personal choice on which set to use. One could even make users make their own..though i would not advise it lol.
There's drawbacks to this of course..but I feel there's more benefits than drawbacks here. Currently trying to make this actually work, but not quite there yet lol.
-
Theme is not the be-all and end-all of everything ;) :P I know plenty of sites that have many smiley packs and only one theme, and I know sites that have only one smiley set and multiple themes. Very often people do not want them tied together, they just want the ability to add them - to me this intimates keeping it away from the actual theme.
The pushing of it to CSS is mostly a convenience, but not for spriting purposes - but for inlining purposes. The smileys in Wedge are not served as files, not even as a single sprited file (which makes no sense for animated smileys anyway, for multiple reasons), but are inlined in the main compressed CSS file for the theme; all the theme files are combined, compressed and served as such, with things like the menu icons and other sprites being converted to data URLs and pushed into the CSS itself, which makes it even more efficient, because not only will the CSS be cached, so will the smileys without even generating an extra HTTP request.
What I'm getting at here is really a methodology of expanding the current system in a way that avoids security issues of folders, and expands upon what's there.
I can see where you're going, and in some cases it would probably be near enough optimal, especially if you wanted to do theme specific variations, but the problem is people do not necessarily want that, and would rather have specific sets of smileys or other images. I have one site, for example, where I have very specific images added as smileys, that wouldn't fit in any theme, wouldn't be in any theme, but they're used to convey a specific feeling, so I wouldn't want to ditch them.
It is an interesting idea, but it's not one that I particularly think we can viably explore in Wedge, though I'd love to hear how it turns out.
-
Yes, the drawback is that the theme will set the rules here..that you would have to copy over the smilies to more themes, to have the same all over. I am not entirely sure how I will solve that, but I see its one of the restrictions of the theme engine, that a theme does *everything* , often when theres no need since its already in default theme.The theme has the freedom to change *everything* - but not change *anything* and get the rest from default theme. The templates work fine in this respect - but not the rest. I have lost track on exactly Wedge does it lol, but building on each other seem to be the answer.
-
Well, Wedge templates are fundamentally more modular than SMF ones, and there is a powerful (and complex) template nesting system, the advantage of which is that you can interject templates in between other templates.
But I never made any bones about the fact Wedge is more plugin rather than theme orientated, that's just the direction we wanted to take it. Given that, I was never comfortable giving the theme *too* much power, but it has *sufficient* power from our perspective for the most part.
-
Bump for Nao: what are your thoughts about storing the smileys in the DB and having them inserted in to the CSS from there? (I'm trying to avoid the need to push files to the file system unless necessary)
-
Bump for Nao: what are your thoughts about storing the smileys in the DB and having them inserted in to the CSS from there? (I'm trying to avoid the need to push files to the file system unless necessary)
-
Um, yes, yes it can. I mean it works currently, right? Yup, they're embedded as data URLs directly into the CSS file already ;)
The difference I'm proposing is to effectively change where this information is coming from - instead of getting them from the physical files as it does currently, get them from a database table.
-
Um, yes, yes it can. I mean it works currently, right? Yup, they're embedded as data URLs directly into the CSS file already ;)
The difference I'm proposing is to effectively change where this information is coming from - instead of getting them from the physical files as it does currently, get them from a database table.
EDIT: I know I'm arguing against an implemented feature, just wanted to share what I felt. Although in either case loading from DB seems like a better idea.
-
I'm still not making myself clear, I can see this.
Smileys are ALREADY loaded into the main CSS file, automatically. It's been that way for months. Seriously, check the code for any smiley on the site thus far. ;)
<i class="smiley wink_png">;)</i>
But it relies on having physical files coming into the system to read, encode and store in the CSS. I'm proposing changing *this* part of the process and only this part of the process, to be able to streamline smileys being added, ideally without having to have write access anywhere that is currently needing write access.
Posted: January 16th, 2013, 06:11 PM
Though it just occurred to me that it might cause IE to poop itself as it doesn't like overly long data URLs.
-
Sorry, missed that topic... You should nudge me by PM for any topic you haven't seen me comment on and you need feedback on ;)
I'm not against the idea, I'm against not having a UI for that later... (BBCode :P)
But yep, older versions of IE either don't support data-URIs at all (Wedge redirects IE6 and IE7 to the physical files), while IE8 (or was it IE7? Probably IE7) has support for them, but no more than X bytes, probably 4K I think. Most smileys are under that range. Wedge accounts for this anyway by, IIRC, automatically redirecting to the physical file is the smiley is very large -- because the advantages of having an overall single file for smileys are totally destroyed by having a LARGE file. ;)
So, yeah, it's unlikely that your suggestion would be good in the long run. I can live with knowing that IE6 won't see any smileys at all (what did they do to deserve them anyway? :P), but I can't live knowing that people will have to download a 2MB smiley file because the admin decided to post a lot of animated lulcatz as smileys.
:edit: I'm not sure Wedge also sorts out the smileys that are 'hidden' by default. It would be smart not to include them in the smiley file, I'm guessing, because most likely they won't be used a lot...
-
I'm still not making myself clear, I can see this.
Smileys are ALREADY loaded into the main CSS file, automatically. It's been that way for months. Seriously, check the code for any smiley on the site thus far. ;)
<i class="smiley wink_png">;)</i>
But it relies on having physical files coming into the system to read, encode and store in the CSS. I'm proposing changing *this* part of the process and only this part of the process, to be able to streamline smileys being added, ideally without having to have write access anywhere that is currently needing write access.
Posted: January 16th, 2013, 06:11 PM
Though it just occurred to me that it might cause IE to poop itself as it doesn't like overly long data URLs.
Posted: January 16th, 2013, 07:16 PM
Okay, reading the source it seems it won't embed smileys beyond 4KB, that'll probably help quite a bit. But perhaps it should limit the CSS file beyond a limit?
-
@Dragooon: Yeah, now I see where you're coming from. Right now there's nothing to cope with that. I don't even know if the customised smiley stuff even works properly any more or whether it's reliant on hardcoding.
Need to think about how that's going to work, too.
@Nao: Heh, I should remember that but I'm sort of conditioned not to PM people to bump topics. I find it rude when people do it to me, so I don't like doing it to others.
I wasn't sure what the behaviour was for IE, I just knew it pooped itself with bigger data URLs. But if redirection to physical files already occurs... then that's how it's got to be anyway, which takes this fancy stuff off the table (which is fine, keeps it simpler) and just enforces using S/FTP, fine by me.
Hidden only means not shown in the post form, but I know on my own sites I use hidden all the time. Also note that :edit: is a hidden smiley ;)
-
Hidden from the post page *and* the smiley popup as well. I usually use hidden smileys to represent elements that are either not interesting to my users (for instance I have both [nobbc]:mdr: and :lol:[/bbcode] smileys, which mean the same in French, so one is 'hidden' because it's only for me -- I don't use it much though), or to add smileys that are too big to fit in the popup, and thus I'd logically rather avoid having them in the CSS file as well.
I don't know, I think it makes sense...
It doesn't prevent you from using the smiley -- it just forces users to an extra HTTP request for them.
Perhaps we could add some UI to ask admins if they want to cache all smileys, or post+popup, or just post smileys...
-
In which case, let's just not cache them into the CSS and just leave them as regular HTTP requests - they're not that common (you have to know that they're there to use them)
I don't think users need to be given that detail to be honest; there is such a thing as too much choice.