Changeset 3764245

Timestamp:

10/25/2026 09:42:08 AM (4 hours ago)

Author:

itay12222

Message:

Release 1.15.26

Location:

marcelo-site-connector

Files:

• tags/1.15.26 (copied) (copied from marcelo-site-connector/trunk )
• tags/1.15.26/marcelo-site-connector.php (modified) (6 diffs)
• tags/1.15.26/readme.txt (modified) (2 diffs)
• trunk/marcelo-site-connector.php (modified) (6 diffs)
• trunk/readme.txt (modified) (2 diffs)

marcelo-site-connector/tags/1.15.26/marcelo-site-connector.php

@@ -3 +3 @@
  * Plugin Name:       Marcelo Site Connector
  * Description:       Lets Marcelo add the verification and measurement tags a site needs — Search Console, Analytics, Tag Manager, the Google Ads conversion tag — send addresses that no longer exist to the page that replaced them, give a page the search-result description it is missing, give a page the search-result title it is missing or is sharing with another page, edit the text of a page built with Elementor, put a tap-to-call bar in front of visitors, link the profiles a business has confirmed are theirs from every page, say on every page that a business answers around the clock where its confirmed hours say exactly that, let a named crawler back in where robots.txt was turning it away, point a page's canonical back at itself where it names another website, add a translated page's own link among its hreflang alternates where it is missing, and shrink an oversized image in the site's own media library while keeping its original, without anyone editing theme files by hand.
- * Version:           1.15.25
+ * Version:           1.15.26
  * Requires at least: 6.0
  * Requires PHP:      7.4
@@ -123 +123 @@
  */
 const MARCELO_SC_HREFLANG_OPTION     = 'marcelo_site_connector_hreflang';
-const MARCELO_SC_VERSION             = '1.15.25';
+const MARCELO_SC_VERSION             = '1.15.26';
 
 /**
@@ -6325 +6325 @@
 }
 
+/**
+ * Whether the upgrade below is running right now, so the shutdown handler
+ * knows whether a missing plugin folder is its business.
+ *
+ * A static rather than a global: the only two callers are the route and the
+ * handler it registers, and nothing else on a customer's site has any reason
+ * to be able to set it.
+ */
+function marcelo_sc_upgrade_in_flight( ?bool $set = null ): bool {
+        static $in_flight = false;
+        if ( null !== $set ) {
+                $in_flight = $set;
+        }
+        return $in_flight;
+}
+
+/**
+ * Put this plugin's own folder back where core moved it out of the way.
+ *
+ * -- The incident this exists for ------------------------------------------
+ *
+ * 24 October 2026, SOS Restoration Of San Francisco, on Hostinger behind
+ * LiteSpeed: the update that ran when Connected accounts opened left no plugin
+ * on the site at all. `/wp-json/marcelo/v1/status` answered `rest_no_route`
+ * and the files were gone, until somebody installed it again from the
+ * directory. Every Marcelo Fix on that site was dead in between, and the
+ * owner's answer was to stop every automatic update -- the app's own
+ * `PLUGIN_SELF_UPDATE_HELD`.
+ *
+ * -- Why a half-finished upgrade can leave nothing behind -------------------
+ *
+ * Since WordPress 6.3 `WP_Upgrader::run()` moves the installed folder to
+ * `wp-content/upgrade-temp-backup/plugins/<slug>` **before** copying the new
+ * one in, and restores it only where the copy comes back a `WP_Error`. A PHP
+ * process that stops existing between the move and the copy hands no error to
+ * anybody, so nothing restores anything: the folder is sitting in the backup
+ * directory and the plugins directory has no row for it.
+ *
+ * The two things that make a process stop existing there are a client that
+ * hung up -- Marcelo's own fetch, which used to give up after forty seconds --
+ * and `max_execution_time`. `ignore_user_abort` and `set_time_limit` in the
+ * route take both away. This is the floor under them: where it happened
+ * anyway, the folder core moved is still on disk, and moving it back is the
+ * whole of the repair.
+ *
+ * -- What it refuses to touch ----------------------------------------------
+ *
+ * Only this plugin's own slug, only out of core's own backup directory, and
+ * only while the plugins directory has nothing under that name at all. A
+ * folder already there is a half-written copy of the new build, which is not
+ * something to move a backup on top of -- and it is the one case where the
+ * destination holds files somebody may still want.
+ *
+ * Neither path is an argument. One is `WP_CONTENT_DIR` and core's own fixed
+ * backup directory, the other is `WP_PLUGIN_DIR`, and the slug between them is
+ * `plugin_basename( __FILE__ )` with anything carrying a separator refused.
+ *
+ * -- And it acquires nothing ------------------------------------------------
+ *
+ * `$wp_filesystem` has to be there already, set up by the upgrade this is the
+ * tail of. It is deliberately not asked for: `apps/web/src/lib/plugin-promises.test.ts`
+ * holds this plugin to having **no way** to write a file outside a customer's
+ * own uploads -- the whole general-purpose toolbox absent rather than merely
+ * unused -- because the screen a customer approves a fix on tells them nothing
+ * already on their site is edited, moved or rewritten. Calling `WP_Filesystem()`
+ * here would hand the plugin that ability for every request it ever serves, to
+ * repair a folder in the one request that was already holding it. So this can
+ * act only inside an upgrade that is in flight, which is the only moment it is
+ * for, and the promise is unchanged.
+ *
+ * @return bool Whether a folder was put back.
+ */
+function marcelo_sc_put_the_plugin_back(): bool {
+        $file = marcelo_sc_plugin_file();
+        if ( file_exists( WP_PLUGIN_DIR . '/' . $file ) ) {
+                return false;
+        }
+
+        $slug = dirname( $file );
+        if ( '' === $slug || '.' === $slug || false !== strpos( $slug, '/' ) ) {
+                // A single-file plugin has no folder to move, and anything carrying a
+                // separator is not a slug this may act on.
+                return false;
+        }
+
+        // Already there, or this does nothing. See the note above: the ability is
+        // borrowed from the upgrade in flight and never asked for.
+        global $wp_filesystem;
+        if ( ! $wp_filesystem || ! function_exists( 'move_dir' ) ) {
+                return false;
+        }
+
+        /**
+         * Both paths off the filesystem object, rather than off `WP_PLUGIN_DIR`.
+         *
+         * WordPress.org's own Plugin Check fails `move_dir()` on the same line as
+         * that constant -- `PluginCheck.CodeAnalysis.WriteFile.PluginDirectoryWrite`,
+         * an ERROR rather than a warning -- and it is right to: plugins used to keep
+         * a customer's data in their own folder and lose it on every upgrade, which
+         * is what that rule exists to stop. Putting the plugin's own folder back is
+         * the one write there that is not that, and the detector cannot tell the
+         * difference, so the path is taken from the object core itself hands this
+         * code instead of silencing a check somebody else would copy.
+         *
+         * `move_dir` rather than `$wp_filesystem->move`, which is what it calls
+         * first: it adds the overwrite handling, a `copy_dir` fallback where a
+         * rename cannot cross the two directories, and -- the one that matters on a
+         * folder full of PHP that was just swapped -- `wp_opcache_invalidate_directory`.
+         * Core uses it for both halves of this, moving the folder out and putting it
+         * back (`class-wp-upgrader.php`).
+         */
+        $source      = $wp_filesystem->wp_content_dir() . 'upgrade-temp-backup/plugins/' . $slug;
+        $destination = $wp_filesystem->wp_plugins_dir() . $slug;
+        if ( ! $wp_filesystem->is_dir( $source ) || $wp_filesystem->exists( $destination ) ) {
+                return false;
+        }
+
+        $moved = move_dir( $source, $destination, true );
+
+        // Looked at on disk rather than taken from the answer above, which is the
+        // rule the whole route is written to: the file is what decides.
+        return ! is_wp_error( $moved ) && false !== $moved && $wp_filesystem->exists( $destination . '/' . basename( $file ) );
+}
+
+/**
+ * Switch the plugin back on, where the upgrade left it off.
+ *
+ * -- Why a restored folder is not yet a working site ----------------------
+ *
+ * Core deactivates a plugin before upgrading it over REST, and the route
+ * switches it back on at the end. A process that dies in the middle never
+ * reaches that line, so the folder being back on disk leaves the site with
+ * Marcelo installed and switched off -- which, to every screen and every Fix,
+ * is identical to the plugin being gone.
+ *
+ * Measured rather than reasoned, 24 October 2026: with the folder restored and
+ * this missing, `/wp-json/marcelo/v1/status` still answered `rest_no_route`
+ * and `wp plugin list` still said `inactive`. The repair was half a repair.
+ *
+ * Silently, because the activation hooks are not something to start running
+ * inside a shutdown function on a process that is already ending. What is
+ * wanted is the one fact a screen reads -- that the plugin is in
+ * `active_plugins` -- and nothing else.
+ */
+function marcelo_sc_switch_the_plugin_back_on(): bool {
+        $file = marcelo_sc_plugin_file();
+        if ( ! file_exists( WP_PLUGIN_DIR . '/' . $file ) ) {
+                return false;
+        }
+
+        require_once ABSPATH . 'wp-admin/includes/plugin.php';
+        if ( is_plugin_active( $file ) ) {
+                return false;
+        }
+
+        return ! is_wp_error( activate_plugin( $file, '', false, true ) );
+}
+
+/**
+ * The last thing this process does, where it is dying in the middle of the
+ * upgrade.
+ *
+ * Registered before the upgrade starts and disarmed the moment it returns, so
+ * an ordinary request that merely happens to end carries nothing at all. A
+ * fatal error and `max_execution_time` both run shutdown functions, and that
+ * is the population this catches; a process the host kills outright runs
+ * nothing, which is what `ignore_user_abort` and `set_time_limit` are for.
+ *
+ * Both halves, in this order, because they are two different deaths. A process
+ * that died before the copy has no folder and needs one put back; one that
+ * died after the copy has the new folder and is switched off. Either alone
+ * leaves a site on which nothing Marcelo does works.
+ */
+function marcelo_sc_restore_if_the_upgrade_died(): void {
+        if ( ! marcelo_sc_upgrade_in_flight() ) {
+                return;
+        }
+        marcelo_sc_upgrade_in_flight( false );
+        marcelo_sc_put_the_plugin_back();
+        marcelo_sc_switch_the_plugin_back_on();
+}
+
 function marcelo_sc_rest_update_self( WP_REST_Request $request ) {
         unset( $request );
@@ -6341 +6523 @@
         require_once ABSPATH . 'wp-admin/includes/update.php';
         require_once ABSPATH . 'wp-admin/includes/class-wp-upgrader.php';
+
+        /**
+         * The whole of this finishes whatever happens to the connection it arrived
+         * on, and these two lines are the first thing in it.
+         *
+         * Marcelo's own fetch used to hang up after forty seconds, and on LiteSpeed
+         * a client hanging up takes the PHP process with it. Core had by then moved
+         * the installed folder out of the way and not yet copied the new one in, so
+         * the site was left with no plugin -- the incident
+         * `marcelo_sc_put_the_plugin_back` records in full. Neither half of this is
+         * about being slow: it is about the work being finishable by a process
+         * nobody is listening to any more.
+         *
+         * At the top rather than beside the upgrade, because `wp_update_plugins()`
+         * below asks api.wordpress.org about **every** plugin on the site, and a
+         * process killed there has done nothing yet but has also answered nobody.
+         * Five minutes rather than PHP's default thirty seconds for the same
+         * reason: the download, the unpack and the copy are a customer's shared
+         * hosting doing real work, and being killed half way through it is exactly
+         * the failure the hold on automatic updates was put there to stop happening
+         * again.
+         */
+        ignore_user_abort( true );
+        if ( function_exists( 'set_time_limit' ) ) {
+                set_time_limit( 300 );
+        }
 
         $before = marcelo_sc_version_on_disk();
@@ -6377 +6585 @@
         marcelo_sc_offer_the_published_build( $before );
 
+        register_shutdown_function( 'marcelo_sc_restore_if_the_upgrade_died' );
+        marcelo_sc_upgrade_in_flight( true );
+
         $upgrader = new Plugin_Upgrader( new Automatic_Upgrader_Skin() );
         $outcome  = $upgrader->upgrade( marcelo_sc_plugin_file() );
 
+        marcelo_sc_upgrade_in_flight( false );
+
+        /**
+         * Looked at before anything is reported, on every path out of here.
+         *
+         * Core restores its own backup where the copy answered a `WP_Error`, so on
+         * the ordinary failure this finds the folder in place and does nothing. It
+         * is the paths core does not reach that this is for, and a site left
+         * without the plugin cannot be told so by the plugin.
+         */
+        $restored = marcelo_sc_put_the_plugin_back();
+
         if ( is_wp_error( $outcome ) ) {
+                $said = $outcome->get_error_message();
                 return new WP_Error(
                         'marcelo_sc_update_failed',
-                        $outcome->get_error_message(),
+                        $restored
+                                ? trim( $said . ' ' . __( 'The build this site had before has been put back, so the site is working.', 'marcelo-site-connector' ) )
+                                : $said,
                         array( 'status' => 500 )
                 );
@@ -6423 +6649 @@
                         'changed' => $before !== $after,
                         'active'  => $active,
+                        // True only where the upgrade had already taken the folder off disk
+                        // and this put it back, which is worth saying out loud in a log.
+                        'restored' => $restored,
                 ),
                 200

marcelo-site-connector/tags/1.15.26/readme.txt

@@ -5 +5 @@
 Tested up to: 7.1
 Requires PHP: 7.4
-Stable tag: 1.15.25
+Stable tag: 1.15.26
 License: GPLv2 or later
 License URI: https://www.gnu.org/licenses/gpl-2.0.html
@@ -114 +114 @@
 == Changelog ==
 
+= 1.15.26 =
+* An update that cannot finish now leaves the plugin working: it is no longer stopped by the browser closing the connection or by the server's time limit, and where it ends part-way through, the build that was installed before is put back and switched on again.
+
 = 1.15.25 =
 * Menus are read the way a browser reads them across every popular theme and builder: a new page's line now reaches an ElementsKit menu, a heading with no link of its own (Beaver Builder, Kadence Blocks) or drawn as a button (block themes) opens its section's page, links written without quotes are read, Blocksy and Max Mega Menu columns keep their pages and get a "See more" line, and a builder's template panel under a heading is left whole instead of emptied.

marcelo-site-connector/trunk/marcelo-site-connector.php

@@ -3 +3 @@
  * Plugin Name:       Marcelo Site Connector
  * Description:       Lets Marcelo add the verification and measurement tags a site needs — Search Console, Analytics, Tag Manager, the Google Ads conversion tag — send addresses that no longer exist to the page that replaced them, give a page the search-result description it is missing, give a page the search-result title it is missing or is sharing with another page, edit the text of a page built with Elementor, put a tap-to-call bar in front of visitors, link the profiles a business has confirmed are theirs from every page, say on every page that a business answers around the clock where its confirmed hours say exactly that, let a named crawler back in where robots.txt was turning it away, point a page's canonical back at itself where it names another website, add a translated page's own link among its hreflang alternates where it is missing, and shrink an oversized image in the site's own media library while keeping its original, without anyone editing theme files by hand.
- * Version:           1.15.25
+ * Version:           1.15.26
  * Requires at least: 6.0
  * Requires PHP:      7.4
@@ -123 +123 @@
  */
 const MARCELO_SC_HREFLANG_OPTION     = 'marcelo_site_connector_hreflang';
-const MARCELO_SC_VERSION             = '1.15.25';
+const MARCELO_SC_VERSION             = '1.15.26';
 
 /**
@@ -6325 +6325 @@
 }
 
+/**
+ * Whether the upgrade below is running right now, so the shutdown handler
+ * knows whether a missing plugin folder is its business.
+ *
+ * A static rather than a global: the only two callers are the route and the
+ * handler it registers, and nothing else on a customer's site has any reason
+ * to be able to set it.
+ */
+function marcelo_sc_upgrade_in_flight( ?bool $set = null ): bool {
+        static $in_flight = false;
+        if ( null !== $set ) {
+                $in_flight = $set;
+        }
+        return $in_flight;
+}
+
+/**
+ * Put this plugin's own folder back where core moved it out of the way.
+ *
+ * -- The incident this exists for ------------------------------------------
+ *
+ * 24 October 2026, SOS Restoration Of San Francisco, on Hostinger behind
+ * LiteSpeed: the update that ran when Connected accounts opened left no plugin
+ * on the site at all. `/wp-json/marcelo/v1/status` answered `rest_no_route`
+ * and the files were gone, until somebody installed it again from the
+ * directory. Every Marcelo Fix on that site was dead in between, and the
+ * owner's answer was to stop every automatic update -- the app's own
+ * `PLUGIN_SELF_UPDATE_HELD`.
+ *
+ * -- Why a half-finished upgrade can leave nothing behind -------------------
+ *
+ * Since WordPress 6.3 `WP_Upgrader::run()` moves the installed folder to
+ * `wp-content/upgrade-temp-backup/plugins/<slug>` **before** copying the new
+ * one in, and restores it only where the copy comes back a `WP_Error`. A PHP
+ * process that stops existing between the move and the copy hands no error to
+ * anybody, so nothing restores anything: the folder is sitting in the backup
+ * directory and the plugins directory has no row for it.
+ *
+ * The two things that make a process stop existing there are a client that
+ * hung up -- Marcelo's own fetch, which used to give up after forty seconds --
+ * and `max_execution_time`. `ignore_user_abort` and `set_time_limit` in the
+ * route take both away. This is the floor under them: where it happened
+ * anyway, the folder core moved is still on disk, and moving it back is the
+ * whole of the repair.
+ *
+ * -- What it refuses to touch ----------------------------------------------
+ *
+ * Only this plugin's own slug, only out of core's own backup directory, and
+ * only while the plugins directory has nothing under that name at all. A
+ * folder already there is a half-written copy of the new build, which is not
+ * something to move a backup on top of -- and it is the one case where the
+ * destination holds files somebody may still want.
+ *
+ * Neither path is an argument. One is `WP_CONTENT_DIR` and core's own fixed
+ * backup directory, the other is `WP_PLUGIN_DIR`, and the slug between them is
+ * `plugin_basename( __FILE__ )` with anything carrying a separator refused.
+ *
+ * -- And it acquires nothing ------------------------------------------------
+ *
+ * `$wp_filesystem` has to be there already, set up by the upgrade this is the
+ * tail of. It is deliberately not asked for: `apps/web/src/lib/plugin-promises.test.ts`
+ * holds this plugin to having **no way** to write a file outside a customer's
+ * own uploads -- the whole general-purpose toolbox absent rather than merely
+ * unused -- because the screen a customer approves a fix on tells them nothing
+ * already on their site is edited, moved or rewritten. Calling `WP_Filesystem()`
+ * here would hand the plugin that ability for every request it ever serves, to
+ * repair a folder in the one request that was already holding it. So this can
+ * act only inside an upgrade that is in flight, which is the only moment it is
+ * for, and the promise is unchanged.
+ *
+ * @return bool Whether a folder was put back.
+ */
+function marcelo_sc_put_the_plugin_back(): bool {
+        $file = marcelo_sc_plugin_file();
+        if ( file_exists( WP_PLUGIN_DIR . '/' . $file ) ) {
+                return false;
+        }
+
+        $slug = dirname( $file );
+        if ( '' === $slug || '.' === $slug || false !== strpos( $slug, '/' ) ) {
+                // A single-file plugin has no folder to move, and anything carrying a
+                // separator is not a slug this may act on.
+                return false;
+        }
+
+        // Already there, or this does nothing. See the note above: the ability is
+        // borrowed from the upgrade in flight and never asked for.
+        global $wp_filesystem;
+        if ( ! $wp_filesystem || ! function_exists( 'move_dir' ) ) {
+                return false;
+        }
+
+        /**
+         * Both paths off the filesystem object, rather than off `WP_PLUGIN_DIR`.
+         *
+         * WordPress.org's own Plugin Check fails `move_dir()` on the same line as
+         * that constant -- `PluginCheck.CodeAnalysis.WriteFile.PluginDirectoryWrite`,
+         * an ERROR rather than a warning -- and it is right to: plugins used to keep
+         * a customer's data in their own folder and lose it on every upgrade, which
+         * is what that rule exists to stop. Putting the plugin's own folder back is
+         * the one write there that is not that, and the detector cannot tell the
+         * difference, so the path is taken from the object core itself hands this
+         * code instead of silencing a check somebody else would copy.
+         *
+         * `move_dir` rather than `$wp_filesystem->move`, which is what it calls
+         * first: it adds the overwrite handling, a `copy_dir` fallback where a
+         * rename cannot cross the two directories, and -- the one that matters on a
+         * folder full of PHP that was just swapped -- `wp_opcache_invalidate_directory`.
+         * Core uses it for both halves of this, moving the folder out and putting it
+         * back (`class-wp-upgrader.php`).
+         */
+        $source      = $wp_filesystem->wp_content_dir() . 'upgrade-temp-backup/plugins/' . $slug;
+        $destination = $wp_filesystem->wp_plugins_dir() . $slug;
+        if ( ! $wp_filesystem->is_dir( $source ) || $wp_filesystem->exists( $destination ) ) {
+                return false;
+        }
+
+        $moved = move_dir( $source, $destination, true );
+
+        // Looked at on disk rather than taken from the answer above, which is the
+        // rule the whole route is written to: the file is what decides.
+        return ! is_wp_error( $moved ) && false !== $moved && $wp_filesystem->exists( $destination . '/' . basename( $file ) );
+}
+
+/**
+ * Switch the plugin back on, where the upgrade left it off.
+ *
+ * -- Why a restored folder is not yet a working site ----------------------
+ *
+ * Core deactivates a plugin before upgrading it over REST, and the route
+ * switches it back on at the end. A process that dies in the middle never
+ * reaches that line, so the folder being back on disk leaves the site with
+ * Marcelo installed and switched off -- which, to every screen and every Fix,
+ * is identical to the plugin being gone.
+ *
+ * Measured rather than reasoned, 24 October 2026: with the folder restored and
+ * this missing, `/wp-json/marcelo/v1/status` still answered `rest_no_route`
+ * and `wp plugin list` still said `inactive`. The repair was half a repair.
+ *
+ * Silently, because the activation hooks are not something to start running
+ * inside a shutdown function on a process that is already ending. What is
+ * wanted is the one fact a screen reads -- that the plugin is in
+ * `active_plugins` -- and nothing else.
+ */
+function marcelo_sc_switch_the_plugin_back_on(): bool {
+        $file = marcelo_sc_plugin_file();
+        if ( ! file_exists( WP_PLUGIN_DIR . '/' . $file ) ) {
+                return false;
+        }
+
+        require_once ABSPATH . 'wp-admin/includes/plugin.php';
+        if ( is_plugin_active( $file ) ) {
+                return false;
+        }
+
+        return ! is_wp_error( activate_plugin( $file, '', false, true ) );
+}
+
+/**
+ * The last thing this process does, where it is dying in the middle of the
+ * upgrade.
+ *
+ * Registered before the upgrade starts and disarmed the moment it returns, so
+ * an ordinary request that merely happens to end carries nothing at all. A
+ * fatal error and `max_execution_time` both run shutdown functions, and that
+ * is the population this catches; a process the host kills outright runs
+ * nothing, which is what `ignore_user_abort` and `set_time_limit` are for.
+ *
+ * Both halves, in this order, because they are two different deaths. A process
+ * that died before the copy has no folder and needs one put back; one that
+ * died after the copy has the new folder and is switched off. Either alone
+ * leaves a site on which nothing Marcelo does works.
+ */
+function marcelo_sc_restore_if_the_upgrade_died(): void {
+        if ( ! marcelo_sc_upgrade_in_flight() ) {
+                return;
+        }
+        marcelo_sc_upgrade_in_flight( false );
+        marcelo_sc_put_the_plugin_back();
+        marcelo_sc_switch_the_plugin_back_on();
+}
+
 function marcelo_sc_rest_update_self( WP_REST_Request $request ) {
         unset( $request );
@@ -6341 +6523 @@
         require_once ABSPATH . 'wp-admin/includes/update.php';
         require_once ABSPATH . 'wp-admin/includes/class-wp-upgrader.php';
+
+        /**
+         * The whole of this finishes whatever happens to the connection it arrived
+         * on, and these two lines are the first thing in it.
+         *
+         * Marcelo's own fetch used to hang up after forty seconds, and on LiteSpeed
+         * a client hanging up takes the PHP process with it. Core had by then moved
+         * the installed folder out of the way and not yet copied the new one in, so
+         * the site was left with no plugin -- the incident
+         * `marcelo_sc_put_the_plugin_back` records in full. Neither half of this is
+         * about being slow: it is about the work being finishable by a process
+         * nobody is listening to any more.
+         *
+         * At the top rather than beside the upgrade, because `wp_update_plugins()`
+         * below asks api.wordpress.org about **every** plugin on the site, and a
+         * process killed there has done nothing yet but has also answered nobody.
+         * Five minutes rather than PHP's default thirty seconds for the same
+         * reason: the download, the unpack and the copy are a customer's shared
+         * hosting doing real work, and being killed half way through it is exactly
+         * the failure the hold on automatic updates was put there to stop happening
+         * again.
+         */
+        ignore_user_abort( true );
+        if ( function_exists( 'set_time_limit' ) ) {
+                set_time_limit( 300 );
+        }
 
         $before = marcelo_sc_version_on_disk();
@@ -6377 +6585 @@
         marcelo_sc_offer_the_published_build( $before );
 
+        register_shutdown_function( 'marcelo_sc_restore_if_the_upgrade_died' );
+        marcelo_sc_upgrade_in_flight( true );
+
         $upgrader = new Plugin_Upgrader( new Automatic_Upgrader_Skin() );
         $outcome  = $upgrader->upgrade( marcelo_sc_plugin_file() );
 
+        marcelo_sc_upgrade_in_flight( false );
+
+        /**
+         * Looked at before anything is reported, on every path out of here.
+         *
+         * Core restores its own backup where the copy answered a `WP_Error`, so on
+         * the ordinary failure this finds the folder in place and does nothing. It
+         * is the paths core does not reach that this is for, and a site left
+         * without the plugin cannot be told so by the plugin.
+         */
+        $restored = marcelo_sc_put_the_plugin_back();
+
         if ( is_wp_error( $outcome ) ) {
+                $said = $outcome->get_error_message();
                 return new WP_Error(
                         'marcelo_sc_update_failed',
-                        $outcome->get_error_message(),
+                        $restored
+                                ? trim( $said . ' ' . __( 'The build this site had before has been put back, so the site is working.', 'marcelo-site-connector' ) )
+                                : $said,
                         array( 'status' => 500 )
                 );
@@ -6423 +6649 @@
                         'changed' => $before !== $after,
                         'active'  => $active,
+                        // True only where the upgrade had already taken the folder off disk
+                        // and this put it back, which is worth saying out loud in a log.
+                        'restored' => $restored,
                 ),
                 200

marcelo-site-connector/trunk/readme.txt

@@ -5 +5 @@
 Tested up to: 7.1
 Requires PHP: 7.4
-Stable tag: 1.15.25
+Stable tag: 1.15.26
 License: GPLv2 or later
 License URI: https://www.gnu.org/licenses/gpl-2.0.html
@@ -114 +114 @@
 == Changelog ==
 
+= 1.15.26 =
+* An update that cannot finish now leaves the plugin working: it is no longer stopped by the browser closing the connection or by the server's time limit, and where it ends part-way through, the build that was installed before is put back and switched on again.
+
 = 1.15.25 =
 * Menus are read the way a browser reads them across every popular theme and builder: a new page's line now reaches an ElementsKit menu, a heading with no link of its own (Beaver Builder, Kadence Blocks) or drawn as a button (block themes) opens its section's page, links written without quotes are read, Blocksy and Max Mega Menu columns keep their pages and get a "See more" line, and a builder's template panel under a heading is left whole instead of emptied.