kaberett: A sleeping koalasheep (Avatar: the Last Airbender), with the dreamwidth logo above. (dreamkoalasheep)
kaberett ([personal profile] kaberett) wrote in [site community profile] dw_dev2018-04-29 01:01 pm
Entry tags:

Code tour: 2018-02-27 to 2018-04-29

Cooooooooooooooooode tour! Tour all the fish! (Did you know that the Eurostar offers a virtual reality Under The Sea tour Thing these days to keep the kids amused while you're in the tunnel beneath the crushing depths etc? NOR DID I, and to my shame I failed to actually do anything with it on my most recent trip, but believe me I'm planning another one.)

These fixes will go live in the next code push, and several of them got written during the volunteer event I hosted a... little while back, now. Hurrah and thank you, and I am looking forward to the fruits of [personal profile] cesy's next event!

Issue 1180: Quick Update not reflecting security settings (pull request)
Patch by: [github.com profile] chrisboyle
Description: Quick Update is the handy update box you get on the Dreamwidth home page! It has a security drop-down, that... didn't reflect your chosen minimum security (but did post to it), and didn't update the security terms used when you switched to posting to a community rather than your own journal. Chris spent A Bunch of time very carefully tweaking this so that it will now give you actual informative options.

Issue 1665: "View all entries from the same date" displayed perplexingly on Create Entry success landing page (pull request)
Patch by: [github.com profile] kaberett
Description: Back in the day, LiveJournal let you backdate entries (i.e. post them on A Day In The Past as far as your journal was concerned). Once upon a time, if you wanted to post IN THE PAST, you needed to check "don't show on Reading Pages" -- at which point you'd get the "wanna view all the other entries you posted on this same day In The Past?" as a link when you got told you'd posted successfully. However! Some Time Ago (in, indeed, The Past) Dreamwidth decided that you could select "Don't show on Reading Pages" without also, simultaneously, having to post In The Past. These days, you don't necessarily want to be asked if you wanna view all the posts you've made today when you're posting today but Not Showing On Reading Pages, and because of the user interface changes it was sort of confusing to have the option show up at all. So, In The Future, it won't.

Issue 2014: Membership option won't save in Account Settings (pull request)
Patch by: [github.com profile] alierak
Description: Ohhh boy. This is pretty much the entire cause of the most frequent question that shows up on the Communities section in Dreamwidth Support, and it took A While to figure out. Because, you see, somewhere along the line something went wrong... such that two settings were always saved very rapidly -- the default post security for the community, and the membership security for the community -- and then propagated through multiple databases... but correctly setting membership security relies on setting the postlevel having propagated through all the databases, which it might not have yet, depending on which way the wind is blowing and whether the sky is blue today. Hilariously, it seems to be the case that when this was first all set up it was FINE and it worked JUST FINE for many years... because hardware and software and all that good stuff wasn't quite fast enough yet to ever run into this problem. And then computing power improved and, er, well, turns out there's been a bug there all along, just it was previously impossible to trigger. The temporary solution, which is Understandably Frustrating, is to keep on trying (and trying and trying) to save the wretched setting, and eventually you'll get lucky and things will go slow enough (or fast enough...) that it all just works. alierak has written a fix that... no longer relies on getting lucky with the speed of computing, and lo, It Will Go Live In The Next Code Push, and then Community Admins Can Stop Mind-Numbingly Hitting Refresh.

Issue 2164: Whitelist embeds from Wistia
Issue 2182: Google Maps has changed some embed codes to use www.google.com/maps instead of maps.google.com
Issue 2191: whitelist embeds from discordapp.com
Issue 2198: Add IMDb to embeds whitelist
Issue 2199: Add ReverbNation to embeds whitelist
Issue 2207: Whitelist embeds from giphy.com
Issue 2216: whitelist embeds from open.spotify.com
Issue 2235: Whitelist embeds from mail.ru
Issue 2238: whitelist embeds from vk.com
Issue 2239: whitelist embeds from livejournal
Issue 2240: whitelist embeds from music.yandex.ru
(pull request)
Patch by: [github.com profile] rshatch
Description: [github.com profile] rshatch is a minor miracle, and has zipped through all the outstanding embed requests and Fixed Them. The deal here is that, in order to be confident that embedded media is safe (that is, it won't hijack your browser or infect you with malware if you view it), Dreamwidth only allows embeds from whitelisted sites -- ones it knows it can clean up well enough to ensure nothing nasty gets through and then trodden into the carpet. Which means that if you want to embed from somewhere, and it's not on the whitelist yet, someone needs to check over the code and then... add it to the whitelist. This is a reasonably straightforward task but it's also kinda fiddly and can get a litle overwhelming, so Everyone Is Very Grateful that as of the next code push you'll be able to embed media from all of these places (again). Some of them are new; some of them just changed their URLs to a format that... wasn't on the whitelist.

Issue 2300: Remove HTTPS Everywhere beta feature (pull request)
Patch by: [github.com profile] rshatch
Description: It's been rolled out across the entire site! HTTPS Everywhere is here to stay! There is absolutely no need to keep the code around for presenting it as a beta feature, because it's a feature that's been generally released and isn't going anywhere until something better comes along. What it does, basically, is make sure that all of the traffic you send to Dreamwidth through the big bad internet is reasonably secure, and very difficult to snoop on. The bugs in the beta got ironed out thanks to all you lovely lot (psst, if you want to beta test for Dreamwidth, here's where to opt in!), it got let out into the wild, and it's doing very well.

Issue 2302: 2215/state sort (pull request)
Patch by: [github.com profile] rshatch
Description: US users had been complaining for a while that the list of state names in the drop-down choose-your-location boxes were really weirdly ordered. Like, not alphabetically, but subtly not alphabetically, such that it was kind of difficult to work out what on earth was going wrong and why. And then I had one of those horrible dawning lightbulb moments (to mix lighting-source metaphors) and double-checked and, yeah, the states' full names were being displayed in the drop-down... but they were being alphabetically sorted by the two-letter state code, which is almost but importantly not quite a match. Whoops.

Issue 2308: user names in markdown now fail to convert if they happen at the beginning of a line (pull request)
Patch by: [github.com profile] kareila
Description: Which is not something that should happen! Markdown is a sort of Web-2.0-y way of putting italics and bold and so on into web-based text without having to faff around with all the old-skool angle-brackets of HTML, and you can use it on Dreamwidth. One of the options is, rather than having to type out >user name="kaberett"< and what-have-you, you can just type @kaberett and get exactly the same thing for many fewer keystrokes... unless, whoops, the @kaberett happened as the very first thing in a line, at which point instead of [personal profile] kaberett you'd get straight-up @kaberett, which is rather less useful being as it's not a link. This fixes that. (I am a luddite and a reactionary and I still use HTML on Dreamwidth, but I do grudgingly admit that it's nice to have a unified cross-platform way of making text *italic* or **bold** in IM platforms and when replying-by-email to Dreamwidth comments and all that sort of suspiciously modern nonsense.)

Issue 2316: support notifications still use HTTP instead of HTTPS links (pull request)
Patch by: [github.com profile] kaberett
Description: We've switched to HTTPS Everywhere. The HTTP will redirect to HTTPS. There is absolutely 0 point sending out HTTP links, and it's Poor Form to do so anyway, so I Fixed That. If you're signed up to receive support notifications (maybe you're a support volunteer! maybe you just wanna know what happens! to which the answer is "less than I'd like, because dear gods below I am doing a postgrad degree and it is eating me") you will, going forward, see a nice reassuring https:// at the beginning of all the Action Links down at the bottom there. Dreamwidth had already done this a while back for all other e-mails sent by the site (... as far as we know, but if you come across any counterexamples please do let me know and I promise I'll only cry a little bit), so please do imagine my smug-cat paw-knead slow-blink of Satisfaction that everything is Neat and Consistent. At least in, er, this one small area. WE'RE WORKING ON THE REST I PROMISE.

18 total issues resolved
Contributors: [github.com profile] alierak, [github.com profile] chrisboyle, [github.com profile] kaberett, [github.com profile] kareila, [github.com profile] rshatch

Post a comment in response:

Identity URL: 
Account name:
If you don't have an account you can create one now.
HTML doesn't work in the subject.


If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org

Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.