It's definitely one of those little things that doesn't really bother me anymore because of how used to it I've become, but I do agree that looking into it would be a good idea.
So recently gmail started chucking all my message notifications from HH into the spam folder. Apparently it's something to do with authentication, is there anything we can do about that?
Mail should be going through again. I need to reboot the server to update the hostname (which is set to localhost for some reason x.x), and we should be down only a few minutes.
You are the end result of a “would you push the button” prompt where the prompt was “you have unlimited godlike powers but you appear to all and sundry to be an impetuous child” – Zero, 2022
Speedy Pony Farts, Donkey Kong International Music, Dave's Married Asexual Rail Conductor
You are the end result of a “would you push the button” prompt where the prompt was “you have unlimited godlike powers but you appear to all and sundry to be an impetuous child” – Zero, 2022
It works on my end.
You might have accidentally clicked through to the dekstop site from your phone. In which case, the only way to get back to the mobile site, unfortunately, is to clear your HH cookies.
I admit this is a poor design decision on Vanilla's part.
Quotes also act funny in Chrome if you use, like, any sort of formatting at all. For some reason, Chrome's WYSIWYG editor sees fit to force-reset all the styles at the top of the comment, which obliterates the quotes plugin's classes. :P
I was able to fix it before by dinking with the styles on the editor IFRAME, but I forget the details.
Okay, I refreshed my memory. The <body> tag in the IFRAME has a font style on it that Chrome thinks is part of what you types, and insists on resetting. The quick fix is to just remove the font style.
You are the end result of a “would you push the button” prompt where the prompt was “you have unlimited godlike powers but you appear to all and sundry to be an impetuous child” – Zero, 2022
Not a bug, per se, but I didn't feel like this warranted a new thread.
I'm going to ask Lee to change the link color to something that stands out against the text better when he gets some free time...but I need suggestions for just what color we should use.
You are the end result of a “would you push the button” prompt where the prompt was “you have unlimited godlike powers but you appear to all and sundry to be an impetuous child” – Zero, 2022
Now let's rejoin the Heapers and see how they're settling into their forum.
...
...a change has taken place. The forum's links appears to have taken on a different hue. Perhaps the scientist forgot to lock down access to the forum's source code.
You are the end result of a “would you push the button” prompt where the prompt was “you have unlimited godlike powers but you appear to all and sundry to be an impetuous child” – Zero, 2022
Or it's processing them, doesn't know what to do with a character above the BMP, and freaks out. I suspect someone may have written their own UTF-8 code (very bad), but I can't prove it just yet. I have to find out what gewgaw inside the JavaScript is handling the preview button.
(*) Did I say utf8 can store any Unicode characters? That’s not really true. MySQL’s utf8 and ucs2 only store unicode from the basic multilingual plane (BMP), which includes “only” the characters U+0000 through U+FFFF. If you have MySQL 5.5 or later you have additional encodings to choose from: utf16, utf32, utf8mb4. These encodings You can read the details, as usual, in the official MySQL documentation.
Nope, that doesn't work either, because MySQL is stupid and has a hard limit on how long an entry in a primary key can be. >.< And of course, Vanillla doesn't support anything but MySQL; if I wanted support for, say, Postgres, I would have to write it.
I'm going to have to use use a workaround. At this point, it's looking like "saving all comment bodies as Base64".
Like I said: MySQL is stupid. :P For some reason, they decided that 3 bytes would always be enough for a UTF-8 character, never mind that UTF-8 is variable-length by nature. MySQL 5.5 tries to fix this by adding that funny type I mentioned above, but of course it breaks other stuff and it's not a drop-in replacement.
And I hate to say it, but if we want emoji to work, it will require modifications to Vanilla, modifications that won't be present upstream. I may have to keep a private copy in Git someplace and apply patches to it from Vanilla upstream manually, which is a pain in the ass, but hey, we wanted certain things to work properly.
This will require data conversion if we go the Base64 route. Older comments would have to be Base64'd and put back. Doing it the less nasty way and just changing the character set may be less of a problem, but we will almost certainly have to shorten some of the name fields, in some cases by as much as a third, for MySQL not to complain about the field width.
In fact, this is enough of a project that I'd probably want U_E's opinion on t, and possibly even Vanilla's themselves. I get the feeling the MySQL limitations are why this still doesn't work upstream.
The other thing that would work is forcibly converting all Unicode characters to entities, which would be less obtrusive than Base64, and would not require any data conversion. I wonder if HtmLawed or one of the other libraries in Vanilla can already do it, actually.
Okay, so it looks like i can get the SMP (and thus emoji) working with just 3 lines of PHP (one each for discussion names, discussion bodies, and comment bodies). That means that emoji will work just about everywhere.
Comments
Godspeed, Lee.
I will have to check all the pages it appears on but it really seems to be working! Thank you, Based Lee.
this is gonna take some getting used to
...
...a change has taken place. The forum's links appears to have taken on a different hue. Perhaps the scientist forgot to lock down access to the forum's source code.
Color, color. What hast thou donst.
Bless you, heapers. Bleapers.
*crashing noise*
[Sun Nov 01 01:01:44.485857 2015] [:error] [pid 4358] [client 192.168.1.14:50962] CommentModel::Save: array(10) {\n ["TransientKey"]=>\n string(12) "BKK5USY6R46S"\n ["hpt"]=>\n string(0) ""\n ["DiscussionID"]=>\n string(1) "2"\n ["DraftID"]=>\n string(0) ""\n ["Body"]=>\n string(35) "Yet another comment: \xf0\x9f\x8c\x80 \xf0\x9f\x8c\x81 \xf0\x9f\x8c\x82"\n ["Format"]=>\n string(4) "Html"\n ["DeliveryType"]=>\n string(4) "VIEW"\n ["DeliveryMethod"]=>\n string(4) "JSON"\n ["Type"]=>\n string(4) "Post"\n ["LastCommentID"]=>\n string(1) "3"\n}\n, referer: http://debian32.home/index.php?p=/discussion/2/sandbox
[Sun Nov 01 01:01:44.487203 2015] [:error] [pid 4358] [client 192.168.1.14:50962] Fields before SQL calls: array(6) {\n ["Body"]=>\n string(35) "Yet another comment: \xf0\x9f\x8c\x80 \xf0\x9f\x8c\x81 \xf0\x9f\x8c\x82"\n ["DiscussionID"]=>\n string(1) "2"\n ["InsertUserID"]=>\n string(1) "1"\n ["Format"]=>\n string(4) "Html"\n ["DateInserted"]=>\n string(19) "2015-11-01 05:01:44"\n ["InsertIPAddress"]=>\n string(12) "192.168.1.14"\n}\n, referer: http://debian32.home/index.php?p=/discussion/2/sandbox
So that means it's either MySQL or Vanilla's MySQL code that's stripping the trans-BMP Unicode. God dammit. -_-
I'm going to have to use use a workaround. At this point, it's looking like "saving all comment bodies as Base64".
This will require data conversion if we go the Base64 route. Older comments would have to be Base64'd and put back. Doing it the less nasty way and just changing the character set may be less of a problem, but we will almost certainly have to shorten some of the name fields, in some cases by as much as a third, for MySQL not to complain about the field width.