As a freelance wordpress developer, one of the tools in available to me the wp-cli terminal commands used to manage wordpress sites.
Today I learned a new wp-cli command.
The latest version of WordPress intoduced a new widget editor, a block editor for widgets. I wanted to learn more about this editor and set myself to the task of upgrading one of my development sites to the latest version 5.8.
To my surprise the site didn’t update, would update, reporting that an update was already in progress. In all my years of working with WordPress, i’ve never had this happen that a site would not update.
I tried various tricks and even other management software to encourage the site to update, but no not happening.
Desperate to upgrade this site, I attempt to update the site using the wp-cli commands via SSH remote login to the server.
(NOTE: apparently there is a timeout on this lock – which should release automatically – Default: 1 hour from line 852 in the code below).
wp core version
(to confirm the current version)
wp core update
(to trigger the update), but again the report
Error: Another update is currently in progress.
I even tried:
wp core update –version=5.8 –force
Still not updating. So i ran the command
wp core update –help
This produces a listing of options and attributes that can effect the command. In the listing was a mention that if the update fails to happen, I should run this command:
wp option delete core_updater.lock
Which produced the results:
Success: Deleted ‘core_updater.lock’ option.
And now I could run my update command again
wp core update
and now I have a version 5.8 WordPress site with the widget editor to work with.
There is a plugin in the repository to deal with the issue, but it hasn’t been updated in the past year.
I took a look-see at the code in that plugin, but believe me using wp-cli commands was way easier and now I have a new command in my arsenal of commands.
The WordPress file that governs this lock is:
./wp-admin/includes/class-wp-upgrader.php
At line #845 of that file we find…
845 /**
846 * Creates a lock using WordPress options.
847 *
848 * @since 4.5.0
849 *
850 * @param string $lock_name The name of this unique lock.
851 * @param int $release_timeout Optional. The duration in seconds to respect an existing lock.
852 * Default: 1 hour.
853 * @return bool False if a lock couldn’t be created or if the lock is still valid. True otherwise.
854 */
855 public static function create_lock( $lock_name, $release_timeout = null ) {
856 global $wpdb;
857 if ( ! $release_timeout ) {
858 $release_timeout = HOUR_IN_SECONDS;
859 }
860 $lock_option = $lock_name . ‘.lock’;
861
862 // Try to lock.
863 $lock_result = $wpdb->query( $wpdb->prepare( “INSERT IGNORE INTO `$wpdb->options` ( `option_name`, `option_value`, `autoload` ) VALUES (%s, %s, ‘no’) /* LOCK */”, $lock_option, time() ) );
864
865 if ( ! $lock_result ) {
866 $lock_result = get_option( $lock_option );
867
868 // If a lock couldn’t be created, and there isn’t a lock, bail.
869 if ( ! $lock_result ) {
870 return false;
871 }
872
873 // Check to see if the lock is still valid. If it is, bail.
874 if ( $lock_result > ( time() – $release_timeout ) ) {
875 return false;
876 }
877
878 // There must exist an expired lock, clear it and re-gain it.
879 WP_Upgrader::release_lock( $lock_name );
880
881 return WP_Upgrader::create_lock( $lock_name, $release_timeout );
882 }
883
884 // Update the lock, as by this point we’ve definitely got a lock, just need to fire the actions.
885 update_option( $lock_option, time() );
886
887 return true;
888 }
889
890 /**
891 * Releases an upgrader lock.
892 *
893 * @since 4.5.0
894 *
895 * @see WP_Upgrader::create_lock()
896 *
897 * @param string $lock_name The name of this unique lock.
898 * @return bool True if the lock was successfully released. False on failure.
899 */
900 public static function release_lock( $lock_name ) {
901 return delete_option( $lock_name . ‘.lock’ );
902 }
903
904 }
905
