I've audited again the plugins I've used on this site. I've removed the following, but not because they aren't useful (they are), but because I don't need them right at the moment:

Enhanced Media Library

Originally used to improve the functionally of the Media Library, but since outclassed by the Media Library Assistant plugin.

Custom Post Type UI

Used to prototype the custom taxonomy I use to identify and the photos and images to which I'm the sole copyright owner. Doesn't need to be installed since I copied the taxonomy into my child theme.

Updates API Inspector

Used to get a view on what wordpress does to identify and install updates to plugins and themes. Doesn't need to remain installed once the investigation is completed.

I've recently done another audit of the plugins used on this site. This was in response to the Media Library insisting that it couldn't update the metadata for media in the media library because it already existed in the library. To track this down I ended up doing a review of the media related plugins. The ones I've uninstalled are:

Bulk Change Media Author Plugin

Allowed me to fix up the author field on multiple media items. I'm now less concerned about this and hence no longer need this

Enable Media Replace

Having sorted out the correct directory structure for my plugins and themes I no longer need this plugin

Phoenix Media Rename

As with the previous plugin, sorting out the directory structure means I no longer need this plugin

I recently experimented with changing my themes and plugins to support self-hosted updates. For plugins this was relatively straight-forward once I'd found two articles, one by Misha Rudrastyh, which got me to adjust the contents of the zip files down one level (which allows WordPress to understand that the new zip file being uploaded is a replacement/update for a plugin that is already installed) and gave the basics of the self-hosted update process¹, including hosting a file that describes the update along side the zip file that is the actual update. The second article by Paul Biron showed what the current version of WordPress is expecting in the php code for plugins

However those articles don't talk about themes that much. To be fair the process for themes is very similar². However the expection of the WordPress code is different to that for plugins, so as a record here's my code:

function ningxia_check_for_update( $slug ) {
 $info = ningxia_get_remote_update_info( $slug );
 if ( false == $info ) {
  return false;
 }
 if ( version_compare( '@@@VERSION@@@', $info['version'], ' $slug,
    'new_version'   => $info['version'],
    'url'           => $info['homepage'],
    'package'       => $info['download_link'],
    'icons'         => array(),
    'banners'       => array(),
    'banners_rtl'   => array(),
    'tested'        => '',
    'requires_php'  => '',
    'compatability' => new StdClass()
  );
  return $update;
 } else {
  return false;
 }
}

function ningxia_pre_set_site_transient_update_themes( $transient ) {
 // Check for update
 $themeslug = 'Ningxia';
 $update = ningxia_check_for_update( $themeslug );
 if ( $update ) {
  $transient->response[$themeslug] = $update;
 }
 return $transient;
}
add_filter( 'pre_set_site_transient_update_themes', 'ningxia_pre_set_site_transient_update_themes' );

My build process modifies the @@@VERSION@@@ string into the current version number for the build being created (for example, 3.80.1) whereas the $info[['version']] comes from the json that been retrieved from the self-hosting site.