Skip to main content

May 16

Hi all, hope you're doing well ^^

Dealing with ADHD medication problems here, so everything's a bit chaotic, but updates are below.

I've created a system for the gallery layout, in which users can choose between infinite scroll pages (scroll down to load new results) or page-by-page loading where buttons appear to go to the previous or next pages. Not everyone is a fan of infinite scroll, so it made sense to implement the option.

One of the main problems with the feed style for galleries was how to ensure images are not displayed at excessively large sizes, without clipping them. I've implemented a solution where images/videos in the feed style display are never shown larger than their base size, i.e. 640x480 or 480x640, and any additional width is unused in the container holding that image or video. All of the displays work smoothly now other than some minor styling issues as far as I can tell, though naturally I'll need to do thorough testing on them at some stage. 

Given that the feed style display allows for fairly large image sizes, I might create an option where subscribed users can view artworks in the feed style at 720p instead of the usual 480p, so that users wanting to browse the feed at large sizes don't get pixelated images from stretching a 480p thumbnail. Delivering thumbnails at 720p costs a lot more in bandwidth (and thus CDN costs) than 480p, hence the need for restricting it to subscribed users.

I improved the gallery SQL stored procedure, and the gallery layout and pages, so that it's shown to users when an artwork on their following feed was reblogged by someone they follow (rather than posted by someone they follow).

It's shown in the title area, so it's not immediately visible when using the standard or square layouts; might need to think of an alternative way for it to be displayed there, but there is limited space in those layouts to display it without having it constantly visible on top of the artworks themselves, so we'll see.

image.png

While thinking about the current state of the SQL stored procedure for getting galleries, I realised a problem: because it was returning information about whether the user has reblogged/liked/interacted with each artwork it returns, it wouldn't be cachable (as that information is specific to each user). That could turn into a problem later, so I had to change approach a little bit.

I've split the gallery SQL procedure into two procedures to deal with this. The first procedure gets the gallery information, without user-specific interaction info, and this result can be cached for future gallery searches. The second procedure takes a comma-separated list of artwork IDs, and returns the user interaction info for those artworks.

The PHP form used to get gallery information from the database connects these together; it first gets the gallery artwork information, then requests the user interaction information for the returned artwork IDs, and returns both of these to the client. 

Bookmark folder modals: progress and new modal types

While I finished making the modals for adding artworks to folders, I realised the normal modals - where it comes up onto the screen - are too slow and cumbersome when a user wants to add stuff to folders as they scroll through a gallery.

I figured out a neat solution using Tippy (the tooltip library), whereby the modal "contents" can be put into a tooltip, and the tooltip set to appear on clicking a button and disappear on clicking outside of the tooltip. This way the modal is a fast, inline screen that appears next to the button, so it's easy to navigate.

Normally it's more efficient to have a save button for settings or preferences, but here I decided that simply clicking the checkboxes will trigger an AJAX call to update the database, as it's much more practical when users are scrolling though a feed. I haven't formatted the tooltip content properly yet for this purpose, but a basic example is below; proper styling will probably be finished in the next update.

image.png

Cloudflare Turnstile debugging

I spent a while trying to figure out why Cloudflare Turnstile was inconsistently giving me errors, only to realise - like an absolute donkey - I was using a live key in testing, so it thought me testing the same page over and over naturally looked rather bot-like. In any event, I noticed some issues with the code when debugging that, so it's all nice and neat now.

Email Templates: standardised system implemented

I created a standard for Deserted Chateau's email templates, so that emails can have a standard template to build from. Since with AWS SES you need to upload each email template separately, it means a lot of duplicated HTML/CSS etc due to most emails having similar structure, but substituting a template variable with a giant bunch of HTML to make customisable emails seems very inefficient.

Instead I made some simple PHP code to create each template as needed, by creating a kind of "template-within-a-template": the base HTML for each email has its own placeholders, and when I run the PHP code, it will replace those placeholders with the specific HTML for a given email type. That then goes to AWS SES as an email template for use; this means maintaining the email formatting should be a lot less of a headache.

Video submissions: storage system improved, presentation improved

To make the video previews in the submission form more clear, I've made them include audio (previously they didn't have audio), but start muted. That way the user can check the audio is still there by hovering over the video to see the controls.

I've also improved the storage system for videos; since Bunny Stream has a Collections feature, where you can organise videos into groups, each user who uploads a video has a Collection made for them that stores all of their videos. This makes it a lot easier when deactivating a user account, as deleting the collection deletes all the videos inside it.

CSS organisation improvements

To make Deserted Chateau's CSS more maintainable, I looked into using Gulp to merge most of the site CSS into one file for production. The aim of this is to reduce the request overhead when someone visits the site for the first time, and the various CSS files are loaded (and it means I don't need to worry about having lots of individual CSS files in the development area if they're merged for production).

Some of the older CSS files are not as well written as the newer ones, and there are a few that cause conflicts when merging the CSS files together due to having rules on the same class names. It's a good opportunity to clean up the CSS code and remove unused styling, so I'm in the process of doing that. Even if the final production CSS is a handful of files instead of one file, it'll serve as a good process for minifying the stylesheets, and still reduce request overhead significantly. I also improved how CSS files are loaded for each page, so that the site can easily switch between using the uncombined CSS files in a test environment and the merged, minified CSS file/s in a production environment. I'll have more to write about this in the next update, I imagine it'll be a fair bit of work.

It's probably also plausible to do something similar with the JavaScript files, albeit with a bit more care. The specific files for each page have on-load functions that would conflict if merged together, but it'd be useful to merge various helper classes together which don't have any on-load code to execute, again reducing overhead and file size in production. I need to do some organisation of the JavaScript files in any case, to make imports/exports easier to manage.

Notification grouping

I improved the SQL stored procedure that gets user notifications, so that now it can (optionally) group notifications for a user, such as follow notifications or comments on a specific artwork. Now that the grouping feature is decided, I can finalise the notifications dropdown in the navigation bar and implement the notifications details page, something I'd been leaving for later as it was hard to really visualise it in my head without having the notifications themselves finalised.

Notifications for artwork comments also work now, as I hadn't implemented those yet.

Misc

Bug Fixes & Improvements
  • Fixed video loop settings not being properly recorded and displayed when submitting an artwork.
  • Delete buttons now work in the browse page when using the Feed style gallery display (when used on an artwork the user is the owner of).
  • Progress and success/failure icons on buttons now display at a size relative to the button, so they're easier to see and read. The base size is smaller, so that buttons never increase in size to show a progress icon, which can mess with layouts.
  • User dropdown menu in the navbar now has icons for each menu option for easier navigation. Styling is a little off, will be fixed later.
  • Videos now work correctly when tabbed in and out of a multi-artwork submission being browsed in a gallery context.
  • Improved the site's error pages; there's now one error page PHP file instead of one per status code, which simplifies maintaining it.
  • Fixed a bug with profile picture uploads, where it wouldn't submit until the user moved the crop area at least once.
  • Video controls now do not display over placeholders until the placeholder has been clicked on to show the artwork under it.
  • Fixed an issue with NSFW placeholders not positioning correctly over videos due to not having their correct dimensions on initial load.
Back to top