March 14
Hi all, hope you're doing well ^^ updates below!
I'm still having a rough time atm, but trying to get stuff done, nonetheless.
Gallery SQL fix: now includes reblogs from follows
I realised the current stored procedure for retrieving galleries (a huge beast of a stored procedure at that) didn't return correct results for the following feed, as artworks reblogged by people the user followed weren't in the results. That's fixed now.
With the new video transcoding stuff, I also changed it to exclude artworks where a video has not finished transcoding yet, so that galleries don't contain artworks that aren't ready to be viewed.
Custom gallery ordering interface implemented
Users can now reorder artworks in their gallery (it doesn't affect search results, just how their own profile appears to people who visit it). I figured it'd be helpful for when people want to set up their gallery. The default is to order by date submitted, and then users can reorder them as they see fit.
Display Artwork: resizable details width saved
In a previous update, I made the display artwork page's details area (showing the artist's info, comments, etc) resizable by the viewer. The resize information is now saved in the local session, so the user will be shown the same size when viewing other artworks during that session, rather than having to resize it every time.
Code Refactoring & Standards
Particularly in the JavaScript part of the codebase, there's a lot of boilerplate code that needs simplifying. It's not so much the inefficiency of writing it, but that there's a need for some operations to have standard methods so that they can be changed easily in future, rather than having to update them all over the place.
AJAX queries
I've created a wrapper around the jQuery ajax() method, that is used for AJAX queries where a user has clicked a button or submitted a form, that removes some of the more tedious aspects of creating user interaction. I'll be documenting it in the code standards part of the documentation server later.
Manager and Tools classes
As the Tools package in the JavaScript code has become rather large, I've started refactoring it into more classes to make it more clear what's where, and made the HelperMethods class mostly a convenience class for calling methods from other classes.
Standardised Modals
I've created standardised modal popups for when users need a form to display above other content on the screen, and standard methods for animating those modals in and out of view. This is useful for various user profile buttons, like editing gallery order and editing albums, where modals are useful for giving the user more input options without cluttering the main page.
Updated Financial Spreadsheet
After all the video transcoding stuff, I've updated the financial spreadsheets with estimates of the costs of that, and also updated a bunch of other areas such as reserved instance pricing for the DB and cache servers, the likely artist-user ratio and so on. You can see a copy of the updated spreadsheet here.
External Site Assets: organisation & polishing
As part of finishing up various parts of the site code that are "nearly done but just have bits and pieces left", I've organised all the external site assets in S3 properly. By 'external site assets' I mean the logos of other sites, that are used when displaying a user's profile links and so forth.
I also tested showing full logos in a user's Links page, I'm in the middle of that at the moment as there are a few styling issues left to deal with.
Video transcoding: moved to Bunny Stream
After getting AWS MediaConvert to work properly, I started doing some more estimates on how much the likely costs would be, looking at scenarios where more videos were uploaded than I'd expect and so on.
The result is that no matter which way I look at it, even transcoding to x264 would become a major cost, just due to the amount of transcoding involved. Instead of that, I've decided Bunny Stream is a much better alternative; it doesn't charge for transcoding, which removes a major cost of video hosting besides the CDN and storage costs.
I've updated the documentation server with details of how Bunny Stream is configured, the API calls to use it and so on. The default is to encode videos to x264 using HLS containers, which means Deserted Chateau needs an additional JavaScript library for users to be able to play them. I've added that to the main set of script declarations in the core code and changed some of the JavaScript parts of the codebase to properly display HLS videos.
Bunny Stream webhook testing
Unfortunately, after some back and forth with Bunny, the webhook that is used for sending video transcode events doesn't have any set list of IPs it can originate from. This makes it difficult to test the webhook without opening up the test environment for public viewing.
The webhook is necessary for properly displaying artworks that contain videos, as when a user has finished submitting an artwork that contains a video, the video itself has not been transcoded yet. I've implemented the necessary database fields and so forth to indicate when a video is ready to be viewed, and the webhook itself is ready, the main part left to implement is a status on the artwork details page showing that the video is still being transcoded (and is not publicly viewable yet), for the uploading user to see. I also need to change the notification system to not notify users of an uploaded artwork if that artwork contains videos, until the videos have finished being transcoded.
For testing purposes, I spun up a separate webserver to act as a webhook endpoint, which only has the webhook page publicly accessible. It's working as expected, so now it's the remaining bits above to sort out.
Video upload previews changed
Before, a full preview of the video was shown to the user (even if it was say, 3 mins long), which makes for a fairly long transcoding time on AWS Lambda for showing it in the artwork submission form, even using x264 and the ultrafast preset.
I've changed it to only transcode the first X seconds of the video (at the moment, 10) to act as a preview placeholder, so the user knows which artwork is which in their submission but without having a long wait time.
Profile Banners: gradient customisation
Since banner images can be very different, sometimes they interfere with the user info text. Normally, the site applies a linear gradient to the banner, leaving it at full brightness at the top and progressing to 30% brightness at the bottom, but this isn't necessarily what every user wants (and for e.g. dark images, it isn't necessary).
The user can now specify the gradient to use, so their banner image displays the way they want. This obviously comes with the potential for someone to make their own profile hard to read, so I may also need to make an option for adjusting the username text within the banner image, we'll see.
User Custom Themes: improvements
I figured out a way to improve the site's theme options, to make them work more "seamlessly". Until now, the way that site themes worked is that the normal CSS files would be loaded, and then the AppearanceManager JavaScript class would modify the CSS variables once the page was finished loading.
The problem with that approach is that when using a different theme to the initial default (dark), there would be a noticeable transition from that to the user's chosen theme, which made for a rather ugly page loading experience. I've changed this in two ways:
- On each page load, the user's theme is checked server-side, and the CSS variables are computed and then echoed onto the page so that it loads with the user's theme rather than being switched to it after loading.
- AppearanceManager now properly loads custom themes when a variable isn't set, defaulting to the dark theme value for that variable.
The result is that pages load with the user's chosen theme immediately, without any switch or transition.
IPv6 migration update
While I did complete the migration to IPv6, I realised that for the test environments, it won't be useful. I've re-migrated the servers back to dualstack IPv4 + IPv6 connectivity instead. The main reason is that the main webserver for the test environment acts as a webhook endpoint for Stripe and Bunny, which both use IPv4; in the live environment, the load balancer acts at the endpoint, so the live webservers can be IPv6 only but the test ones can't.
In addition, while it's theoretically possible for the documentation and articles servers to be IPv6 only, a lot of people (myself included) wouldn't be able to connect to them, so it's not worth having them be IPv6 only either.