LMS:If you begin your reply with a quote of the entire comment above it, the system automatically removes the quote. It can usually be told from context whether a reply is to the one above or another/more general reply and we do not currently have a quotation-notification system that would give the quote a purpose.
Though we might get a system in the far off future, Kyo currently has higher priority site updates to work on, and reproducing the comment above only acts as superfluous organization. Removing automatically it helps keep pages from getting too cluttered or excessively long.
Try cutting and repasting the whole of the quoted text, as I've done here.
Nightshade the Merry Widow (NSFW, nudity/sex)Comic Fury
Created by Ed Kline and Kishma Danielle, co-writer Lee M, assistance Bob Partridge Storm Over Whoomera (NSFW, nudity)Comic Fury | Renderosity (first page)
Created by Ed Kline, co-writer Lee M
I come to you, again, bearing no new information. I just kind of felt like I needed to re-up on telling people that we are still currently on the VPS, load continues to be fine, but once the move completes there might be a short downtime, as I've been told.
Wow another post by Kyo, surely this time the server migration will be done right, think again buddy
It sounds like most of the data is over, but the server migration somehow "failed", which I'm assuming means whatever program they use to do it died part of the way through. Apparently most of the data has been transferred over now, but I'm guessing they have to do integrity checks and whatnot on everything as well. Like I said before, I'm not privy to a ton of information about how this works, so I'm kind of reading between the lines of their messages a bit here. Anyway, that whole process was started 7 hours ago and I got an email an hour ago that they're still going.
So I guess it's progress, just in sort of an intangible kind of way. So how was your day? I hope you're staying hydrated
actually today I almost passed out at work due to dehydration. First day back from medical leave, too. Fun.
Anyway, does this mean some files could be potentially lost, or nah? I think I'm gonna finally make backups for the comic sites I care about regardless... just in case Dreamhost decides to pull something even more villainous, somehow, if that's even possible at this point.
They said before there would be no loss of data. I also have all comic pages (and all other files) that were uploaded up until yesterday backed up, and there will be another backup made today, I'm a bit uneasy about dreamhosts ability to correctly move files from place a to place b without losing half of them as well, but worst case scenario they'd be down until I've re-uploaded them all, there shouldn't be any permanent losses (of pages uploaded before yesterday/today once that backup is done) - but again just so people don't get the wrong idea - unless I've been told incorrect information, and I've asked for clarification again just to be sure, there should be no loss of data whatsoever
If you just noticed the site go down for 2 minutes a couple times, sorry that was me rebooting the server. Can't blame dreamhost this time.
I'm still trying to fix all emoji submitted to the site before the server move. It looks like unfortunately it's not as easy as a configuration change, but I'll still reimport them, it'll just be a huge pain to do.
It's hard to choose, but I think the server move breaking emojis is one of the more surreal parts of this story for me.
What was the reason for that again? Their server migration tools couldn't handle text encoded in utf-8? Now, hopefully this doesn't make me sound too stupid, but just to confirm… that's, like, one of the most common ways of encoding text these days, and definitely something they should be able to handle, right? :p
…also, doesn't that qualify as loss of data in and of itself? I'm kind of grateful and amazed that threads like this didn't end up turning into a gigantic stream of "?"s :p
It's specifically 4-bit utf-8 codes, which is mostly (but not only) emoji. It is the de-facto standard for displaying text these days, although usually the number of bytes wouldn't really be something you focus on like this. The reason for that is that mysql databases allow you to specify a length for your text fields, as well as a collation, which is essentially the encoding as well as information about how to sort things alphabetically (which may depend on language) and how to transform upper and lowercase, I believe. Now MySQL has a utf8 collation (to be precise, it's called utf8_unicode_ci) - it only supports up to 3-byte UTF-8 unicode characters. Why? Because of the length of text fields I mentioned earlier. So when you say "I want to store a text that's up to 180" characters, mysql said, alright, so I need to reserve up to 180*3 = 540 bytes for this. Then 4-byte characters got introduced (at least I assume that's the way the timeline went, otherwise it would be really weird). What's the solution? They come out with this new collation, called utf8mb4_unicode_ci, which allows you to store emoji at long last.
That's incidentally also a reason why emoji got auto-filtered on the site for a long time, it was just mysql rejecting them as invalid characters. So that's the relevance of emoji specifically. How did they get broken? I honestly have no idea. They told me they used mysql to move the databases, so this really just flat out should not have happened, and no matter what the server is configured to, I specify the correct encoding when connecting to the database, and in my tables and columns as well. There is no reason it should have broken if they did what they say they did. I assume what happened is that they didn't really do what they say they did and use mysql, that the person who told me that was just giving me wrong information (like has happened so many other times recently). I assume they used some janky pieced together script to transfer it over, that somewhere in the process converts the backup into the wrong encoding, and back. I really have no idea what happened. I googled it a lot, but all the results are for obvious gotchas like having the wrong collation in your table, or not connecting right (maybe they transferred the database on a utf8 connection instead of a utf8mb4 connection?).
So yeah. I'm not sure what happened. Probably some extreme behind the surface jank you and I are not privy to, that dreamhost would never admit exists, at least not to a paying customer. At least the next server move, I'll be the one doing all this stuff.